`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でシャットダウンし、経由でmysqlを再起動した後service mysql start、エラーログはこのエラーセットを繰り返しループします。

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

起動中のMySQLログ mysqld_safe --skip-grant-tables

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。

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

mysql_upgrade -u root -p

それらを渡さない場合、エラーが発生します

編集：コメントのおかげで、他の理由があることはわかっています

そのため、次の場合にエラーが発生します。

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

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

cli MySQLクライアントは、-uと-pのみを使用してローカルDBインスタンスに接続できますが、ソケットファイル接続を試行し、試行中に惨めに失敗したため、mysql_upgradeに-h 127.0.0.1を指定する必要もありました。

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

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

これらを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

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

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

簡単に言うと、エラーは誤解を招くものです！mysql_upgrade -u root -pDBをオンラインで実行し、rootパスワードを提供します。

この質問は非常に一般的なものであり、そのことをおthatびします。

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

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

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

chown -R mysql /var/lib/mysql

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しmy.cnf.rpmsaveて、新しいものmy.cnfと比較し、InnoDB設定など、MySQL構成に対して行われた調整を元に戻します。

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

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

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

そして今、mysql_upgradeうまく動作するmysql_upgrade -uroot -pので、rootパスワードの入力を求められました。

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

お役に立てれば！

また、mysql_upgrade -uroot -pMySQLを実行する必要があるため、失敗しました！

学んだ教訓：

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

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

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

これは私のために働いた： sudo mysql_upgrade -S <path-to-socket> -u <myuser> -p<mypass>

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

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

mysqldを使用して起動し/usr/sbin/mysqld &、mysql_upgrade正常に実行しました。

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

私の特定のケースでは、mysql_upgradeの出力は次のとおりでした。
「mysql」を検索：mysql
「mysqlcheck」を検索：mysqlcheck
FATAL ERROR：Upgrade failed

それはかなり役に立たないです。--verboseは違いはありません。

接続すると、次のコマンドで解決し、それは魅力のように機能しました：
mysql_upgrade -S /var/lib/mysql/mysql.sock -uUSERNAME -p

それが役に立てば幸い。

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

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

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

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

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

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

slackware armでこの問題が発生しましたが、この場合は問題ではないと仮定します。

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

試してみる

mysql_upgrade --verbose 

または多分（または両方）

--debug-check --debug-info

MySQLのrootユーザーの名前は、rootではなく「admin」です。正しいコマンドは

mysql_upgrade -uadmin -p