このセクションでは、すでにオンラインで匿名トランザクションを使用しているサーバー上で GTID トランザクションを有効にし、オプションで自動配置を有効にする方法について説明します。 この手順では、サーバーをオフラインにする必要はなく、本番での使用に適しています。 ただし、GTID トランザクションを有効にするときにサーバーをオフラインにできる可能性がある場合は、プロセスが容易です。
MySQL 8.0.23 から、GTID がまだないレプリケートされたトランザクションに GTID を割り当てるようにレプリケーションチャネルを設定できます。 この機能により、GTID ベースのレプリケーションを使用しないソースサーバーから使用するレプリカへのレプリケーションが可能になります。 この手順で説明されているように、レプリケーションソースサーバーで GTID を有効にできる場合は、代わりにこの方法を使用します。 GTID の割当ては、GTID を有効にできないレプリケーションソースサーバー用に設計されています。 このオプションの詳細は、セクション17.1.3.6「GTID のないソースから GTID のあるレプリカへのレプリケーション」 を参照してください。
起動する前に、サーバーが次の事前条件を満たしていることを確認します:
トポロジ内の All サーバーは、MySQL 5.7.6 以上を使用する必要があります。 トポロジ内の all サーバーがこのバージョンを使用していないかぎり、GTID トランザクションを単一のサーバーでオンラインで有効にすることはできません。
すべてのサーバーで、
gtid_modeがデフォルト値のOFFに設定されています。
次の手順は、GTID を無効にするオンライン手順である セクション17.1.4.3「GTID トランザクションのオンラインでの無効化」 の対応する手順にジャンプすることで、いつでも一時停止してあとで再開できます。 これにより、プロシージャの途中で発生する関連のない問題は通常どおりに処理でき、その後、プロシージャは停止した場所で続行されるため、プロシージャはフォルトトレラントになります。
次のステップに進む前に、すべてのステップを完了することが重要です。
GTID トランザクションを使用可能にする手順は、次のとおりです:
-
各サーバーで、次のコマンドを実行します:
SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN;通常のワークロードでサーバーをしばらく実行し、ログを監視します。 このステップでログに警告が発生した場合は、GTID 互換機能のみを使用し、警告を生成しないようにアプリケーションを調整します。
重要これは最初の重要なステップです。 次のステップに進む前に、エラーログに警告が生成されていないことを確認する必要があります。
-
各サーバーで、次のコマンドを実行します:
SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON; -
各サーバーで、次のコマンドを実行します:
SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;どのサーバーがこのステートメントを最初に実行するかは関係ありませんが、すべてのサーバーが次のステップを開始する前にこのステップを完了することが重要です。
-
各サーバーで、次のコマンドを実行します:
SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;どのサーバーがこのステートメントを最初に実行するかは関係ありません。
-
各サーバーで、ステータス変数
ONGOING_ANONYMOUS_TRANSACTION_COUNTがゼロになるまで待機します。 これは、次を使用してチェックできます:SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';注記レプリカでは、理論的にはゼロを表示してから再度ゼロ以外を表示することが可能です。 これは問題ではなく、一度はゼロと表示されます。
-
ステップ 5 までに生成されたすべてのトランザクションがすべてのサーバーにレプリケートされるまで待機します。 これは、更新を停止せずに実行できます: 唯一重要なのは、すべての匿名トランザクションがレプリケートされることです。
すべての匿名トランザクションがすべてのサーバーにレプリケートされたことを確認する方法については、セクション17.1.4.4「匿名トランザクションのレプリケーションの検証」 を参照してください。
-
ポイントインタイムバックアップやリストアなど、レプリケーション以外にバイナリログを使用する場合は、GTID のないトランザクションを含む古いバイナリログが不要になるまで待機します。
たとえば、ステップ 6 の完了後、バックアップを作成しているサーバーで
FLUSH LOGSを実行できます。 次に、明示的にバックアップを取るか、設定した定期バックアップルーチンの次の反復を待機します。理想的には、ステップ 6 の完了時に存在していたすべてのバイナリログがサーバーによってパージされるまで待機します。 また、ステップ 6 より前に作成したバックアップが期限切れになるまで待機します。
重要これは 2 番目の重要な点です。 GTID のない匿名トランザクションを含むバイナリログは、次の手順のあとに使用できないことを理解することが不可欠です。 このステップの後、GTID のないトランザクションがトポロジ内のどこにも存在しないことを確認する必要があります。
-
各サーバーで、次のコマンドを実行します:
SET @@GLOBAL.GTID_MODE = ON; -
各サーバーで、
gtid_mode=ONおよびenforce_gtid_consistency=ONをmy.cnfに追加します。すべてのトランザクションに GTID があることが保証されるようになりました (ステップ 5 以前で生成され、すでに処理されたトランザクションを除く)。 GTID プロトコルの使用を開始して後で自動フェイルオーバーを実行できるようにするには、各レプリカで次を実行します。 オプションで、マルチソースレプリケーションを使用する場合は、チャネルごとにこれを行い、
FOR CHANNEL句を含めます:channelSTOP SLAVE [FOR CHANNEL 'channel']; CHANGE MASTER TO MASTER_AUTO_POSITION = 1 [FOR CHANNEL 'channel']; START SLAVE [FOR CHANNEL 'channel']; Or from MySQL 8.0.22 / 8.0.23: STOP REPLICA [FOR CHANNEL 'channel']; CHANGE REPLICATION SOURCE TO SOURCE_AUTO_POSITION = 1 [FOR CHANNEL 'channel']; START REPLICA [FOR CHANNEL 'channel'];