レプリケーションセットアップに関与するサーバーをアップグレードするときに、アップグレードの手順は現在のサーバーバージョンとアップグレード後のバージョンによって異なります。 このセクションでは、アップグレードがレプリケーションに与える影響について説明します。 MySQL のアップグレードの一般情報は、セクション2.11「MySQL のアップグレード」 を参照してください
以前の MySQL リリースシリーズから 8.0 にソースをアップグレードする場合は、まず、このソースのすべてのレプリカが同じ 8.0.x リリースを使用していることを確認する必要があります。 そうでない場合は、まずレプリカをアップグレードする必要があります。 各レプリカをアップグレードするには、レプリカを停止し、適切な 8.0.x バージョンにアップグレードして再起動し、レプリケーションを再開します。 アップグレード後にレプリカによって作成されるリレーログは、8.0 形式です。
厳密な SQL モード (STRICT_TRANS_TABLES または STRICT_ALL_TABLES) で操作に影響を与える変更により、アップグレードされたレプリカでレプリケーションが失敗する可能性があります。 ステートメントベースのロギング (binlog_format=STATEMENT) を使用する場合、ソースの前にレプリカがアップグレードされると、ソースはソースで成功したがレプリカで失敗する可能性があるステートメントを実行するため、レプリケーションが停止します。 これに対処するには、ソース上のすべての新しいステートメントを停止し、レプリカがキャッチアップされるまで待機してから、レプリカをアップグレードします。 または、新しいステートメントを停止できない場合は、ソース (binlog_format=ROW) で一時的に行ベースのロギングに変更し、この変更時点までに生成されたすべてのバイナリログがすべてのレプリカによって処理されるまで待機してから、レプリカをアップグレードします。
MySQL 8.0 で、デフォルトの文字セットが latin1 から utf8mb4 に変更されました。 レプリケートされた設定では、MySQL 5.7 から 8.0 にアップグレードする場合、アップグレードする前にデフォルトの文字セットを MySQL 5.7 で使用されている文字セットに戻すことをお薦めします。 アップグレードの完了後、デフォルトの文字セットを utf8mb4 に変更できます。 以前のデフォルトが使用されていたと仮定すると、これらを保持する方法の 1 つは、my.cnf ファイル内の次の行を使用してサーバーを起動することです:
[mysqld]
character_set_server=latin1
collation_server=latin1_swedish_ciレプリカがアップグレードされたら、ソースを停止し、レプリカと同じ 8.0.x リリースにアップグレードして再起動します。 ソースを一時的に行ベースのロギングに変更した場合は、ステートメントベースのロギングに戻します。 8.0 ソースは、アップグレード前に書き込まれた古いバイナリログを読み取り、それらを 8.0 レプリカに送信できます。 レプリカは古い形式を認識し、適切に処理します。 アップグレード後にソースによって作成されるバイナリログは、8.0 形式です。 これらも 8.0 レプリカによって認識されます。
つまり、MySQL 8.0 にアップグレードする場合、ソースを 8.0 にアップグレードする前にレプリカが MySQL 8.0 である必要があります。 8.0 から古いバージョンへのダウングレードは、それほど簡単には機能しません。ダウングレードに進む前に 8.0 バイナリログまたはリレーログを削除できるように、それらが完全に処理されたことを確認する必要があります。
アップグレードによっては、ある MySQL シリーズから次のものに移行するときに、データベースオブジェクトの削除と再作成が必要になる場合があります。 たとえば、照合順序の変更には、テーブルインデックスの再構築が必要な場合があります。 このような操作の詳細は、必要に応じて セクション2.11.4「MySQL 8.0 での変更」 を参照してください。 レプリカとソースでこれらの操作を個別に実行し、ソースからレプリカへのこれらの操作のレプリケーションを無効にすることが最も安全です。 これを実現するには、次の手順を使用してください。
すべてのレプリカを停止し、アップグレードします。 ソースに接続しないように、
--skip-slave-startオプションを使用して再起動します。 データベースオブジェクトの再作成に必要なテーブル修復または再構築操作 (REPAIR TABLE、ALTER TABLEの使用など)、またはテーブルまたはトリガーのダンプおよびリロードを実行します。ソースのバイナリログを無効にします。 ソースを再起動せずにこれを行うには、
SET sql_log_bin = OFFステートメントを実行します。 または、ソースを停止し、--skip-log-binオプションを使用して再起動します。 ソースを再起動する場合は、クライアント接続を禁止することもできます。 たとえば、すべてのクライアントが TCP/IP を使用して接続する場合は、ソースの再起動時にskip_networkingシステム変数を有効にします。バイナリログが無効の状態で、データベースオブジェクトの再作成に必要なテーブル修復または再構築操作を実行します。 これらの操作がログに記録され、あとでレプリカに送信されないようにするには、この手順でバイナリログを無効にする必要があります。
ソースでバイナリログを再度有効にします。 以前に
sql_log_binをOFFに設定した場合は、SET sql_log_bin = ONステートメントを実行します。 バイナリログを無効にするためにソースを再起動した場合は、クライアントとレプリカが接続できるように、--skip-log-binなしでskip_networkingシステム変数を有効にせずに再起動します。今回は、
--skip-slave-startオプションを指定せずにレプリカを再起動します。
グローバルトランザクション識別子をサポートしていない MySQL のバージョンからアップグレードする場合は、GTID ベースのレプリケーションのすべての要件を設定が満たしていることを確認する前に、ソースまたはレプリカで GTID を有効にしないでください。 セクション17.1.3.4「GTID を使用したレプリケーションのセットアップ」を参照してください。GTID ベースレプリケーションを使用するために既存のレプリケーションセットアップを変換することに関する情報が含まれています。
MySQL 8.0.16 より前では、グローバルトランザクション識別子 (GTID) を有効にして (gtid_mode=ON) サーバーを実行している場合、mysql_upgrade (--write-binlog オプション) によるバイナリロギングを有効にしないでください。 MySQL 8.0.16 の時点では、サーバーは MySQL アップグレード手順全体を実行しますが、アップグレード中はバイナリロギングを無効にするため、問題はありません。
ダンプファイルにシステムテーブルが含まれている場合、GTID がサーバー (gtid_mode=ON) で有効になっているときにダンプファイルをロードすることはお薦めしません。mysqldump は、非トランザクション MyISAM ストレージエンジンを使用するシステムテーブルに対して DML 命令を発行します。GTID が有効になっている場合、この組み合わせは許可されません。 GTID が有効になっているサーバーから GTID が有効になっている別のサーバーにダンプファイルをロードすると、異なるトランザクション識別子が生成されることにも注意してください。