マルチスレッドレプリカにおける運用時の注意点について

MySQL 8.0
この記事は最終更新から2年以上経過しています。内容が古くなっている可能性があります。

はじめに

2021 年 10 月 19 日に MySQL 8.0.27 がリリース されました。非同期レプリケーションにおける変更点の 1 つとして、デフォルトでマルチスレッドレプリカが有効になり、レプリカの遅延を軽減しやすくなることが期待できるようになりました。

Replication: Multithreading is now enabled by default for replica servers. A multithreaded applier has a number of applier threads that execute transactions in parallel. This behavior can avoid many cases of unwanted replication lag that can cause temporary divergence between the source and replicas.

参照 : Changes in MySQL 8.0.27

具体的には、以下のシステム変数のデフォルト値がそれぞれ変更されています。

今回は、今後デフォルトで有効になるこのマルチスレッドレプリカについて、運用時にどのような点に気を付ければ良いのか、代表的なものをいくつか紹介させていただこうかと思います。

目次

マルチスレッドレプリカについて

まず、マルチスレッドレプリカとは MySQL 5.6 から実装された機能であり、レプリカにおけるレプリケーション SQL スレッドを増やして、レプリカで実行できるトランザクション数の並列化を有効にする機能です。有効にした状態でレプリケーションをおこなうと、以下のように複数のレプリケーション SQL スレッドが作成されるようになります。

この機能は、replica_parallel_workers を 0 よりも大きい値に設定することで有効になります。
これによって、レプリケーション SQL スレッドは指定された数のワーカースレッドとそれらを管理するためのコーディネータースレッドが作成されるようになり、リレーログの内容を並列に実行することが可能になっています。

また、MySQL 8.0.27 ではこの他にも replica_preserve_commit_order = 1 が設定されているため、レプリカにデータが反映される際にはソースと同じ順序でトランザクションが実行されるようになっており、並列実行してもデータの整合性を維持することができます。

トランザクションのリトライとタイムアウト

マルチスレッドレプリカでは複数のレプリケーション SQL スレッドが存在するため、これまでのシングルスレッドのレプリケーションとは異なり、レプリカサーバーで更新処理を実行していなくても、ソースサーバーのように行ロックやデッドロックが発生する可能性があります。
そのため、トランザクションの実行に失敗した際、自動的に replica_transaction_retries(デフォルト値 : 10) 回のリトライをおこなうようになっています。

ただし、たとえば非常に長いトランザクションが実行されていたり、あるいは以前のバージョンではバグの影響などにより、replica_transaction_retries を超えてリトライが失敗すると、以下のようにエラーとなってしまうので注意してください。

このようなエラーが発生した場合は、手動でレプリケーション SQL スレッドを再開する必要があるため、エラーの内容に問題がないことを確認してから再開するようにしてください。
また、このリトライは行ロックやデッドロックのように一時的なエラーに対しては適用されますが、更新対象の行データが存在しない場合などには適用されません。

replica_pending_jobs_size_max による処理待ち

以前の記事「MTS(マルチスレッドスレーブ)を使う場合の注意点」 でも紹介させていただきましたが、マルチスレッドレプリカを使用する際には、replica_pending_jobs_size_max(デフォルト値 : 128M) の値に気を付ける必要があります。

マルチスレッドレプリカでは、ワーカースレッドに replica_pending_jobs_size_max を超える未処理のイベント(トランザクション)がきた場合、全てのワーカースレッドのキューが空になるまでイベントが待機状態になります。イベントの待機が発生すると、以下のようなメッセージが出力されます。

ここで、レプリケーションにおける更新情報は、通常ソースサーバーおよびレプリカサーバーの max_allowed_packet(デフォルト値 : 64M) の値を上限としてやり取りされています。より正確には、レプリケーションスレッドに関しては replica_max_allowed_packet(デフォルト値 : 1G) が上限になっています。
もし replica_pending_jobs_size_max がこれらの値より小さかった場合、大きなトランザクションを実行するたびに待機が発生してしまい、レプリケーション遅延が頻繁に起きる可能性があります。そのため、各値は以下のように調整するようにしてください。

max_allowed_packet <= replica_pending_jobs_size_max <= replica_max_allowed_packet

ソースサーバーのバイナリログのポジションラグ(MTS ギャップ)

GTID を使用したレプリケーション の場合は影響ありませんが、マルチスレッドレプリカでは SHOW REPLICA における Exec_source_log_pos の情報は最低水準点、すなわち表示されている値まではコミットされていることが保証されていますが、それより後のトランザクションについてもコミットされている可能性があり、コミットされているかどうかについては保証されていません。
そのため、もしレプリカサーバーの SQL スレッドや mysqld プロセスが強制終了してから再起動すると、以下のようなエラーが発生してレプリケーションが再開できなくなる可能性があります。

このようなケースでは、START REPLICA UNTIL SQL_AFTER_MTS_GAPS を実行することによりバイナリログのポジションラグを解消することが可能です。実行後は、再度 START REPLICA を実行してレプリケーションを復帰させるようにしてください。
なお、relay_log_recovery が有効な場合は以下のように、再起動時に自動で START REPLICA UNTIL SQL_AFTER_MTS_GAPS が実行されるため、ポジションを確認した上で START REPLICA を実行すればレプリケーションを復旧できます。

また、ソースサーバーのバイナリログの正確なポジション情報は mysql.slave_worker_info にバイナリ形式で格納されており、STOP REPLICA や mysqld プロセスの正常終了時、START REPLICA UNTIL SQL_AFTER_MTS_GAPS 実行時などの際はこの情報をもとにポジションラグを解消しているので、特に気を付ける必要はありません。

ただし、mysqldump–dump-slave オプションを利用してソースサーバーのバイナリログのポジション情報を取得しようとした場合、ポジションラグによって正確な情報が取得できない可能性があります。
そのため、上記のオプションを利用する場合は、以下のように一度マルチスレッドレプリカを停止してからバックアップを取得する必要があるので注意してください。

まとめ

ここまで、マルチスレッドレプリカにおける運用時の注意事項について代表的なものをいくつか紹介してきました。
マルチスレッドレプリカは MySQL 5.6 から実行されましたが当時はあまり有用ではなく、それ以降徐々に機能が拡充してきて利用しやすくなり、ようやく MySQL8.0.27 でデフォルトになったことで感慨深くもあります。ただし、マルチスレッドレプリカ特有の注意事項なども存在しているので、新しく導入される際には最低限今回の内容に注意して利用してもらえればと思います。

参照リファレンス

Changes in MySQL 8.0.27 (2021-10-19, General Availability)
17.2.3.2 レプリケーションアプライアンスワーカースレッドの監視
17.5.1.32 レプリケーション再試行とタイムアウト
17.5.1.34 レプリケーションとトランザクションの非一貫性

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃MySQLのサポート業務に従事している有資格者で構成された技術サポートチームがMySQLに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

よかったらシェアしてね!
  • URLをコピーしました!
目次