MAMP mysqlサーバーは起動しません。 mysqlプロセスは実行されていません
MAMP mysqlサーバーが起動しません。私がウェブで見た提案はすべて、実行中の他のmysqldプロセスをチェックし、存在する場合はそれらを強制終了し、問題を修正する必要があると言っていますが、私にはそうではありません。
エラーログは次のとおりです。
130415 13:42:12 mysqld_safe Starting mysqld daemon with databases from /Library/Application Support/appsolute/MAMP PRO/db/mysql
130415 13:42:12 [Warning] Setting lower_case_table_names=2 because file system for /Library/Application Support/appsolute/MAMP PRO/db/mysql/ is case insensitive
130415 13:42:12 [Note] Plugin 'FEDERATED' is disabled.
130415 13:42:12 InnoDB: The InnoDB memory heap is disabled
130415 13:42:12 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130415 13:42:12 InnoDB: Compressed tables use zlib 1.2.3
130415 13:42:12 InnoDB: Initializing buffer pool, size = 128.0M
130415 13:42:12 InnoDB: Completed initialization of buffer pool
130415 13:42:12 InnoDB: highest supported file format is Barracuda.
130415 13:42:13 InnoDB: Waiting for the background threads to start
130415 13:42:14 InnoDB: 1.1.8 started; log sequence number 1707549
130415 13:42:14 [Note] Event Scheduler: Loaded 0 events
130415 13:42:14 [Note] /Applications/MAMP/Library/bin/mysqld: ready for connections.
Version: '5.5.25' socket: '/Applications/MAMP/tmp/mysql/mysql.sock' port: 0 Source distribution
接続は開いているように見えますが、MAMPが次のメッセージでエラーを出力します。「MySQLを起動できませんでした。詳細についてはログを確認してください。」
助言がありますか？
私のために働いたのは、mysqlディレクトリ内のすべてのファイル（ディレクトリではない）を削除することでした。
編集＃2以下の回答に従って、ログファイルを削除するだけです：[ib_logfile0、ib_logfile1]
MAMPを終了し、ターミナルで：
rm /Applications/MAMP/db/mysql/ib_logfile* #(or wherever your MAMP is installed)
編集！：何人かは、何か問題が発生した場合に最初にこれらのファイルをバックアップしたいかもしれないと言っているので、代わりにmvを使用するだけです。
mv /Applications/MAMP/db/mysql/* /tmp/.
これが機能しない場合は、戻ってすべてのプロセスを強制終了します：Sudo killall -9 mysqld
これもここで複製されます： mysqlサーバーはMAMPを起動しません
最も簡単な解決策：MAMPを終了し、MAMP/db/mysqlディレクトリ[ib_logfile0、ib_logfile1]からログファイルを削除して、MAMPを再起動します。詳細については http://juanfra.me/2013/01/mysql-not-starting-mamp-fix/
rm /Applications/MAMP/db/mysql56/*
正常に動作しますが、データベースがあるにもかかわらずphpmyadminに「データベースが見つかりません」と表示されるため、drupalが原因でエラーが発生しました。
私がする必要があるのは、2つのファイルib_logfile0とib_logfile1を/Applications/MAMP/db/mysql56/から単に削除するだけです。
MAMPサイトを見ました。 MAMP/db/mysql56に移動し、両方のログファイルの名前を変更します（最後に番号を変更しました）。出来上がり、MAMPを再起動し、すべてが順調でした。
ログファイル名：
- ib_logfile0
- ib_logfile1
- MAMPサーバーを停止します。
- 次に、次のフォルダーに移動します。
Applications/MAMP/db/mysql56 /
このフォルダーで、フォルダーを除くすべての直接ファイルを削除してください。これは、auto.cnf, ibdata, ib_logfile,のみを削除する必要があり、フォルダーを削除する必要がないことを意味します。
- MAMPサーバーを再起動します。
動作するはずです。
ありがとうございました。
ここでの回答のほとんどは、ランダムファイルを削除することを提案しています。
ほとんどの場合、これは最も悪いことです開発環境の整合性を保つことが重要である場合は特にです。
ログファイルで説明したように、この問題が読み取りアクセス許可にもmysqlで削除したファイルにも関連しない場合、唯一の解決策は次のとおりです。
MAMPの[ファイル]メニューからmy.confファイルを開きます（[ファイル]> [テンプレートの編集]> [MySQL]）
次の行を見つけて編集します：
innodb_force_recovery = 1Ctrl + Sで保存
MAMPはサーバーの再起動を提案します
次のユニコーンの構築に戻ります:)
ターミナルで次のコマンドを入力するだけです：
rm /Applications/MAMP/db/mysql56/ib_logfile*
その後、MAMPを再起動します。
完全に機能します。
私は物事の組み合わせを行わなければなりませんでした。最初に、mysqlディレクトリの権限を変更する必要がありました。 applications/MAMP/db/mysql56/mysql ここでStackoverflowを参照
それでも解決しない場合は、my.cnfファイルを次のようにapplications/MAMP/confフォルダーに追加します。
[mysqld]
innodb_force_recovery = 1
adel 'Sean' Helalを参照してください。回答
これが私のために働いた結果です。
これをポテンシャルアンサーとして投稿しています！
これを解決するために私がしたことは次のとおりです：
- コンピューターを再起動します（クラッシュして自身を再起動しようとしても、mysqldプロセスが実行されていないことを確認します）
- 次のコマンドを実行して、コンピューター上でmysqlと関係のあるすべてのものを削除します。
Sudo rm /usr/local/mysql Sudo rm -rf /usr/local/mysql* Sudo rm -rf /Library/StartupItems/MySQLCOM Sudo rm -rf /Library/PreferencePanes/MySQL* vim /etc/hostconfig and removed the line MYSQLCOM=-YES- rm -rf ~/Library/PreferencePanes/MySQL* Sudo rm -rf /Library/Receipts/mysql* Sudo rm -rf /Library/Receipts/MySQL* Sudo rm -rf /var/db/receipts/com.mysql.* - MAMP PROアンインストーラーを実行してMAMPを削除してから、applications/MAMPフォルダーを削除します
Library/Application Support/appsoluteフォルダー（MAMPアプリケーションサポートフォルダー）を削除します。- MAMP PROを再インストールする
うまくいけば、これが役立ちます:)
ib_logfile0のib_logfile1とApplications/MAMP/db/mysql56/を削除する必要があることをさまざまな回答で見ました
MAMP PRO 4を使用する場合、これらのファイルは/Library/Application Support/appsolute/MAMP PRO/db/mysql56/にあります
これらのファイルを削除するとうまくいきます（システムがクラッシュした後、サーバーが起動しません）。
この問題が発生しました。これらは私のために働いたステップです。
MAMPで
Preferencesを開き、現在のApacheおよびMySQLポート番号を書き留めます。![enter image description here]()
Set to default Apache and MySQL portsボタンとReset MAMPボタンの両方をクリックして、[OK]をクリックします。MAMPを終了
/Applications/MAMP/db/mysqlディレクトリからすべてのファイル（フォルダーではない）を削除します。MAMPを再起動し、
Start Serversをクリックします。注：MySQLが正常に起動してもApacheが起動しない場合は、
Preferencesに戻り、Apacheポートを以前の状態に戻します。 [OK]をクリックすると、MAMPが更新され、ApacheとMySQLの両方が起動します。http://localhost/MAMP/index.phpのロードに失敗した場合、開発者ツール（Chrome）を開き、更新ボタンを右クリックしてEmpty Cache and Hard Reloadを選択します。 phpAdminページがロードされます。開発者ツールのApplicationパネルに移動しない場合は、メニューからClear Storageを選択し、Clear Site Dataをクリックします。
これらの手順が、データベーステーブルを破壊する必要のない誰かに迅速な修正を提供することを願っています。
MAMP/db/mysql56フォルダーからファイルib_logfileN（Nは数字）を削除します。
次に、MAMPを再起動します。
動作するはずです！
上記のすべてのソリューションをMAMPバージョン4.2で試してみましたが、El Capitan OSでは動作しませんでした。そのため、MAMPをClean My Macでアンインストールしてから、古い3.5.2バージョンをインストールするだけでした。すぐに働きました。
わかりましたので、ここで見つけたすべての提案をSOや他のフォーラムで試しました。私のために働いた唯一の解決策は、MAMP 3バージョンをインストールすることでした。なぜなら、wordpressプロジェクトにMAMPを使用しているためです。
本当の原因を見つける最良の方法は、MAMP> logs> mysql_error_log.errでMAMPエラーログを確認することです
「3306ポートで別のmysqlサーバーが既に実行されていますか？」というエラーが見つかりました。 -これが実際にMAMP MYSQLが起動しない原因でした。
ポート3306はすでに「ビジー」であったため、8306に変更し、問題を解決しました。
私のために働いたのは：
MAMPが終了した場合でも、「mysqld」というプロセスが実行されていました。プロセスを強制終了し、MAMPを再起動しましたが、再び機能しました。
ここに私のために働いたものがあります：
- Brewなどを使用してmysqlを誤ってインストールしたかどうかを確認してください。
brew list mysql - アンインストール
brew uninstall mysql - MAMPを起動してみてください。再インストールが必要な場合があります。
- 最終的にVagrantにアップグレードし、MAMPとの戦闘を停止します。
私はWindowsとMYSQL 5.7でMAMP 4.1を実行していましたが、この問題が何度もあり、これに対する修正を見つけました：ログファイルの削除が機能していなかったので、単にdelete
- mysql-bin.index
- YOUR_PC_NAME.pid
ブームが再び機能し始めます。これでもうまくいかない場合は、各ファイルを1つずつ削除し、うまくいくかどうかを確認し続けてください。必ず backup にしてください。
MAMP PROの場合、ここでib_logfilesを削除する必要があります。
rm -rf /Library/Application\ Support/appsolute/MAMP\ PRO/db/mysql56/ib_logfile*
ここでの答えはどれも私の特定の問題を解決しなかったので、おそらくリストに独自の解決策を追加する必要があります。
MAMPの実行中にコンピューターをハードリセットする必要がありました。これにより、MAMPはApache Serverを開始できるが、何らかの理由でMySQL serverを開始できないという問題が発生する場合があります。
この問題の解決策は次のとおりです。
- MAMPを閉じる
Applications/MAMP/tmp/mysqlに移動します- ファイルを削除します
mysql.sock.lock - MAMPを再起動します
私にとっては、my.cnfのinnodb_additional_mem_pool_sizeの行が原因でした。