MySQL データベースのアップグレードにおけるいくつかの「落とし穴」

商用データベースの場合、データベースのアップグレードは優先度が高く、バージョンアップのロードマップ、対応するパッチ、計画のための一連の訓練などがあり、厳しい戦いであることは明らかです。 MySQL の方向では、アップグレードの問題は、まるでそれがその存在を証明するだけであるかのように、かなり軽視されてきました。もちろん、まさにこの注目の欠如のせいで、私は今日多くの回り道をしてきました。

一般的に言えば、MySQL をアップグレードするための実行可能なソリューションは 2 つあります。1 つはデータ ディクショナリを直接アップグレードすることです。これはローカル マシンで完了します。プロセス全体にはオフライン操作が含まれ、業務が中断されます。2 つ目は、高可用性によってスムーズな切り替えを実現することです。原則は、低いバージョンから高いバージョンへのデータ レプリケーション関係を確立することです。このソリューションには明らかな利点があり、ビジネスへの影響が最も少なく、事前に検証でき、スムーズなロールバックを実現することもできます。もちろん、2 番目のソリューションには多くの事前準備が必要です。

現在私たちが扱っている環境では、ストレージや期間などの要素に基づいて最初の方法を採用しています。全体のプロセスは次のようになります。

1) mysqldump を使用してデータベースをバックアップします。バックアップ ファイルは約 120G です。

2) MySQL 5.5データベースを停止する

3) データベース ポートを変更してデータベースを再起動します。たとえば、移行プロセス中に他のビジネス接続の影響を回避するために、4308 から 4318 に変更します。検証後、データベースを停止します。

4) mysql_baseパスをバージョン5.7に変更し、/usr/bin/mysqlなどの環境変数設定を変更します。

5) 設定ファイルをバージョン5.7に置き換え、データベースを5.7モードで起動します。

6) アップグレード モードを使用してデータ ディクショナリをアップグレードします。コマンドは次のとおりです。

mysql_upgrade --socket=/data/mysql_4306/tmp/mysql.sock --port=4308 -uroot -pxxxx

7) 検査とレビュー

プロセス全体は問題ないように見えますが、実際の運用では抜け穴がたくさんあります。

1) mysqldump を使用してデータベースをバックアップします。バックアップ ファイルは約 120G です。高速オンライン バックアップには、mysqldump が使用されます。ただし、異常な状況ではリカバリ効率が低下します。したがって、バックアップに mysqldump を使用することはお勧めしません。代わりに、物理バックアップを使用することをお勧めします。条件が許せば、コールド バックアップ モードを直接使用してください。

2) MySQL 5.5データベースを停止する

3) データベース ポートを変更してデータベースを再起動します。たとえば、移行プロセス中に他のビジネス接続の影響を回避するために、4308 から 4318 に変更します。検証後、データベースを停止します。

4) mysql_baseパスをバージョン5.7に変更し、/usr/bin/mysqlなどの環境変数設定を変更します。

5) 設定ファイルをバージョン 5.7 に置き換え、データベースを 5.7 モードで起動します。ibdata の設定には注意を払っていませんでした。残念ながら、次のような奇妙な設定に遭遇しました。

innodb_data_file_path = ibdata1:1000M;ibdata2:100M:自動拡張

元の標準構成は、次の ibdata ファイルです。

innodb_data_file_path = ibdata1:1G:autoextend、

これにより、データベースの起動時に、ibdata ファイルが破損していることを示すエラー メッセージが表示されます。

6) アップグレード モードを使用してデータ ディクショナリをアップグレードします。コマンドは次のとおりです。

mysql_upgrade --socket=/data/mysql_4306/tmp/mysql.sock --port=4308 -uroot -pxxxx

アップグレード コマンドの実装プロンプトはあまり親切ではなく、多くのエラーが表示されましたが、最終的にはアップグレードが成功したという安心できるメッセージが表示されました。問題がこの段階に達すると、実際には解決が困難になりました。データ ディクショナリ ファイルが破損していたため、データ ディクショナリをアップグレードすることは不可能でした。これでは、データベースは、その中のテーブルを記述することさえできませんでした。

7) 検査と検証。当初は簡単に完了していた検証作業が、緊急の修復作業になってしまった。

その後に行われた最初の一連の是正措置は次のとおりでした。

8) 早朝に取得した既存の物理バックアップを使用してデータを復元するのに約 1 時間かかりました。mysqldump による復元をあきらめましたが、少なくとも 6 時間かかったと記憶しています。

9) 物理バックアップモードを使用して現在のデータベースをバックアップする

10) ibdata の構成に特に注意しながら、データベースを再アップグレードします。アップグレードが失敗した場合は、物理バックアップを使用してすぐにロールバックします。

11) アップグレード プロセスが再度ブロックされましたが、今回は sql_mode が原因でした。システム データ ディクショナリは正常にアップグレードされましたが、データベース テーブルの検出中に、主に sql_mode のデータ形式の検証が原因で、多くのデータ テーブルの形式検証が失敗しました。alter table test.xxxxx force などの再構築操作が必要でした。

12) リカバリプロセス中に原因不明の理由で、InnoDB の redo ログも影響を受け、ログにエラーが発生し始めました。そのため、現在復元されているデータベースの辞書が正常にアップグレードされたとしても、まだいくつかの欠陥が残っています。

その後の第2波の是正措置は次のとおりです。

13) mysqldump を使用して現在のデータベースをバックアップし、指定されたデータベースのみをバックアップし、all-databases オプションを使用せず、権限を個別にエクスポートします。

14) ポート4390などの別のポートを使用してMySQL 5.7のインスタンスをデプロイする

15) sql_mode はバージョン 5.5 でワイルドカード化され、他のパラメータが変更されます。

16) mysqldumpデータを4390 5.7インスタンスにインポートする

17) マスタースレーブレプリケーション関係を確立する

18) データベースポートを切り替えて、新しいバージョン5.7サービスを有効にします。

プロセス全体は紆余曲折に満ちていました。私はそれぞれの課題に自分なりの戦略で対処しようとし、近道を試みましたが、結局、罠にはまらなかったことがわかりました。このことから、決して軽視せず、運試しの姿勢で問題に対処してはいけないという、深い教訓も学びました。

上記は、MySQL データベースのアップグレードにおけるいくつかの「罠」の詳細です。MySQL データベースのアップグレードの詳細については、123WORDPRESS.COM の他の関連記事に注目してください。