web-dev-qa-db-ja.com

`mysql_upgrade`は、実際の理由なしに失敗します

MySQL 5.1から5.5にアップグレードし、mysql_upgradeを実行して次の出力を取得しています。

# mysql_upgrade
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

何が起こっているのか（または、何が起こっていないのか）をどこで探すかについてのアイデアがあるので、問題を修正して実際にmysql_upgrade？

ありがとう！

その他の出力：

# mysql_upgrade --verbose
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

# mysql_upgrade --debug-check --debug-info
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

# mysql_upgrade --debug-info
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

User time 0.00, System time 0.00
Maximum resident set size 1260, Integral resident set size 0
Non-physical pagefaults 447, Physical pagefaults 0, Swaps 0
Blocks in 0 out 16, Messages in 0 out 0, Signals 0
Voluntary context switches 9, Involuntary context switches 5

# mysql_upgrade --debug-check
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

mysqld --skip-grant-tablesを介してmysqladmin shutdownをシャットダウンし、service mysql startを介してmysqlを再起動した後、エラーログは次の一連のエラーを繰り返しループします。

130730 21:03:27 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Table 'mysql.plugin' doesn't exist
130730 21:03:27 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
130730 21:03:27 InnoDB: The InnoDB memory heap is disabled
130730 21:03:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130730 21:03:27 InnoDB: Compressed tables use zlib 1.2.3.4
130730 21:03:27 InnoDB: Initializing buffer pool, size = 20.0G
130730 21:03:29 InnoDB: Completed initialization of buffer pool
130730 21:03:30 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 588190222435
130730 21:03:30  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 588192055067
130730 21:03:30  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 81298895, file name /var/log/mysql/mysql-bin.006008
130730 21:03:33  InnoDB: Waiting for the background threads to start
130730 21:03:34 InnoDB: 5.5.32 started; log sequence number 588192055067
130730 21:03:34 [Note] Recovering after a crash using /var/log/mysql/mysql-bin
130730 21:03:34 [Note] Starting crash recovery...
130730 21:03:34 [Note] Crash recovery finished.
130730 21:03:34 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
130730 21:03:34 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
130730 21:03:34 [Note] Server socket created on IP: '0.0.0.0'.
130730 21:03:34 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.Host' doesn't exist

mysqld_safe --skip-grant-tablesを介した起動時のMySQLログ

130730 21:19:36 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130730 21:19:36 [Note] Plugin 'FEDERATED' is disabled.
130730 21:19:36 InnoDB: The InnoDB memory heap is disabled
130730 21:19:36 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130730 21:19:36 InnoDB: Compressed tables use zlib 1.2.3.4
130730 21:19:37 InnoDB: Initializing buffer pool, size = 20.0G
130730 21:19:39 InnoDB: Completed initialization of buffer pool
130730 21:19:39 InnoDB: highest supported file format is Barracuda.
130730 21:19:42  InnoDB: Warning: allocated tablespace 566, old maximum was 0
130730 21:19:42  InnoDB: Waiting for the background threads to start
130730 21:19:43 InnoDB: 5.5.32 started; log sequence number 588192055067
130730 21:19:43 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
130730 21:19:43 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
130730 21:19:43 [Note] Server socket created on IP: '0.0.0.0'.
130730 21:19:43 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them
130730 21:19:43 [ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_current' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_history' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_history_long' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'setup_consumers' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'setup_instruments' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'setup_timers' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'performance_timers' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'threads' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_summary_by_thread_by_event_name' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_summary_by_instance' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_summary_global_by_event_name' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'file_summary_by_event_name' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'file_summary_by_instance' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'mutex_instances' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'rwlock_instances' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'cond_instances' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'file_instances' has the wrong structure
130730 21:19:43 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.32-0ubuntu0.12.04.1-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)

私が理解しているように、すべてのテーブル構造/存在の問題（mysqlシステムテーブルに関連するため）はmysql_upgradeを実行して修正する必要があります。

mysqlmysql5.5
70
Jim Rubenstein

この質問は信じられないほど一般的であり、申し訳ありません。

問題の直接的な原因と解決策を見つけることができなかったため、MySQLを再インストールして、それが機能するかどうかを確認しました。結局、再インストールでうまくいった。それはそれを修正するための不十分な方法でしたが、それは私が残した唯一のオプションでした。

この質問に対する他の多くの回答は、最初にmysql_upgradeを実行するために実行しなければならなかった問題ですが、何らかの理由で-自動クエリを実行しようとして失敗し、そのドキュメントを見つけることができませんでした実行していたクエリを修正したので修正しました。

3
Jim Rubenstein

ユーザー名とパスワードが必要だと思います

mysql_upgrade -u root -p

私がそれらを渡さない場合、私はあなたのエラーを受け取ります

編集：コメントのおかげで、他の理由があることがわかりました。頻度は少ないかもしれませんが、それらにも注意することをお勧めします

だからあなたはそのエラーを受け取ります

  • ユーザー名とパスワードを渡さなかった
  • あなたはあなたの資格情報を渡しましたが、それらは間違っていました
  • mySQLサーバーが実行されていません
  • 権限のテーブルが台無しになっている（その後、MySQLをmysqld --skip-grant-tableで再起動する必要がある）
  • テーブルmysql.pluginがありません（MySQLの起動時に、実行を提案するエラーが表示されます... mysql_upgrade、および失敗します。おそらくmy.cnfに古い構成がいくつかあります）。
95
Riccardo Galli

これはPleskサーバーのようです。Pleskを使用している場合、Mysqlのルートはありませんが、Mysqlの管理者はadminと呼ばれるため、このコマンドは以前試したようにPleskで機能するはずです。

mysql_upgrade -uadmin -p`cat /etc/psa/.psa.shadow`
9
linuxman1

5.5から5.6にアップグレードしたときに、これらの正確な症状が発生しましたが、サービスの到達可能性の問題であることが判明しました。

Cli MySQLクライアントは-uと-pを指定するだけでローカルDBインスタンスに接続できましたが、mysql_upgradeに-h 127.0.0.1を指定する必要もありました。

9
Aubrey Falconer

同じ問題！私の解決策は http://www.freebsd.org/cgi/query-pr.cgi?pr=180624 から来ました

簡単に言うと、エラーは誤解を招くものです！実行mysql_upgrade -u root -pオンラインでDBを使用して、ルートパスワードを入力します。

5
Dr. Gianluigi Zane Zanettini

これらを1つずつ実行して、どこで失敗するかを確認できます。

mysql_upgradeは次のコマンドを実行して、テーブルをチェックおよび修復し、システムテーブルをアップグレードします。

mysqlcheck --all-databases --check-upgrade --auto-repair  
mysql < fix_priv_tables  
mysqlcheck --all-databases --check-upgrade --fix-db-names --fix-table-names

from http://dev.mysql.com/doc/refman/5.5/en/mysql-upgrade.html

5
user16081-JoeT

Mysqlデータの下のすべてのファイルの権限を確認する必要があります。 mysql PID（mysqlまたは_mysql）の所有者と同じである必要があります。これは、適切な許可なしにファイルからデータを復元するために発生することがあります。たとえば、mysqlデータが/ var/lib/mysqlにある場合

chown -R mysql /var/lib/mysql
2
asofyan

DBAは、5.5.39にアップグレードするだけでなく、mysqlバージョン5.0.95をアンインストールしました。アンインストールによって/etc/my.cnfが/etc/my.cnf.rpmsaveにバックアップされてから削除されたため、MySQLが正しく起動しませんでした。

140902 15:00:57 [ERROR] Plugin 'InnoDB' init function returned error.
140902 15:00:57 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
140902 15:00:57 [ERROR] Unknown/unsupported storage engine: InnoDB
140902 15:00:57 [ERROR] Aborting

次のいずれかを実行できます。

  • My.cnfファイルを手動で比較し、InnoDBの適切な構成設定を引き継ぎます

  • my.cnf.rpmsaveを元の状態に戻します（最初に、追加する必要がある新しいデフォルト設定がないか確認してください！）

  • vimdiffなどのdiffツールを使用して、my.cnf.rpmsaveを新しいmy.cnfと比較し、MySQL構成に加えられた調整（InnoDB設定を含む）を元に戻します。

    [root]# vimdiff /etc/my.cnf /etc/my.cnf.rpmsave

最後のオプションを実行すると、MySQLを起動できました。

root]# service mysqld start
Starting mysqld:                                           [  OK  ]

そしてmysql_upgradeはmysql_upgrade -uroot -pを使用して正常に機能するため、ルートパスワードの入力を求められました。

[root]# mysql_upgrade -uroot -p
Enter password:
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
Running 'mysqlcheck with default connection arguments
....

お役に立てれば！

mySQLを実行する必要があるため、mysql_upgrade -uroot -pの使用も失敗しました！

学んだ教訓：

  • アップグレードの前にmy.cnfをバックアップします...そして実際には、アンインストールしてから新しいバージョンをインストールする代わりに、インプレースアップグレードを実行します。
  • MySQLを実行して、mysql_upgradeを使用できるようにします。
  • 利益。
2
Ronnie

5.1から5.5へのアップグレードで同じ問題がありました。

これは私のために働きました：Sudo mysql_upgrade -S <path-to-socket> -u <myuser> -p<mypass>

私のエラーはおそらくソケットパスへのアクセス許可が原因でしたが、それが原因であるかどうかを確認する時間がありません。

1
Capt

私にとっても同じ問題ですが、私の問題の原因は古いパスワード形式でした。 mysqlは「skip-secure-auth」で古い形式を使用して強制的に接続できますが、mysql_upgradeにはこのオプションがありません。最初に新しい形式でルートパスワードを更新する必要があり、次にmysqlをアップグレードできます。

1
Leandro Dardini

私の場合、ローカルでmysqldのいくつかのバージョンが実行されていたため、mysql_upgradeがエラー：サーバーバージョンの取得中に失敗しました！不正アクセスが原因である可能性があります。ps aux | grep mysqlとmysqldがすべてシャットダウンされていることを確認します。次に、すべてのバージョンを抽出してアンインストールし、正しいバージョンを再インストールします。その後、mysql_upgradeが機能し始めました。

0
Laurens Bronwasser

私は同じ問題に出くわしました。
-S /path/to/mysql.sockを含めることで解決しました

私の特定のケースでは、mysql_upgradeの出力は次のとおりです。
「mysql」を次のように探します：mysql
次のように「mysqlcheck」を探します：mysqlcheck
致命的なエラー：アップグレードに失敗しました

それはかなり役に立たない。 --verboseは違いを生じませんでした。

差し込むと次のコマンドに落ち着き、それは魅力のように機能しました：
mysql_upgrade -S /var/lib/mysql/mysql.sock -uUSERNAME -p

それが役に立てば幸い。

0
bfieber

この問題に直面しましたが、

  1. mySQLサービスを実行する必要がありました

  2. ユーザー名とパスワードが必要です

0
Sruit A.Suk

同じ問題が発生しました。

/ etcのmysql_install_db --user=mysqlファイルのコメントに記載されているように、rc.mysqlで新しいデータベースをインストールすることで、これを解決しました。

その後、mysqlデーモンを起動して、「mysql」またはmysqlパッケージに接続したいものを使用できました。

Slackwareアームでこの問題が発生しましたが、この場合は問題にならないとします。

0
user323106

システムをMint 12からMint 15にアップグレードした後、これに遭遇しました。/var/lib/mysqlをアーカイブし、アップグレード後に元の場所に戻しました。私はuser16081のコメントから最初のmysqlcheckを実行しましたが、mysql.sockについて不満がありました。

/usr/sbin/mysqld &を使用してmysqldを起動したところ、mysql_upgradeは問題なく動作しました。

0
Marty Vance