MySQLの半同期の詳細な説明

序文

新年になってから Tencent との 2 回目の面接を受けたとき、アルゴリズムを書いた後に最初に尋ねられた質問は、「MySQL の半同期とは何ですか?」でした。その時は完全に混乱しました。MySQL の 2 フェーズ コミットの問題についてだと思ったのですが?確認してみると、2段階の提出ではなかったことがわかりました。すると、面接官は私が質問の内容すら分かっていないことに気づき、この質問を飛ばして次の質問に進みました。そこで今回はこの部分の知識内容をまとめてみます。テキスト内容が多く、少し退屈かもしれませんが、それでもこの分野に興味がある人にとっては興味深い内容です。

MySQL マスタースレーブレプリケーション

大規模プロジェクトでは、通常、MySQL レプリケーションを使用して MySQL マスター/スレーブ クラスターを作成します。データの同期は、主にサーバーに 1 つ以上のバックアップ データベースを構成することによって実行できます。レプリケーション機能は、高性能アプリケーションの構築に役立つだけでなく、高可用性、スケーラビリティ、災害復旧、バックアップ、データ ウェアハウスの基盤にもなります。

簡単に言えば、MySQL のマスター スレーブ レプリケーションを使用して、読み取りと書き込みの分離を実現します。読み取りと書き込みが可能なシングル ポイント データベースと比較して、ビジネス システムのパフォーマンスが向上し、ユーザー エクスペリエンスが最適化されます。さらに、マスター スレーブ レプリケーションによってデータベースの高可用性が実現されます。マスター ノードの MySQL がハングアップした場合、スレーブ データベースを使用して引き継ぐことができます。

MySQL でサポートされているレプリケーション方法

MySQL は次の 3 つのレプリケーション モードをサポートしています。

• ステートメントベースのレプリケーション (論理レプリケーションとも呼ばれる) は、主に、マスター データベースで実行された SQL ステートメントがスレーブ データベースで繰り返されることを意味します。これは、MySQL がデフォルトで使用するレプリケーションの種類であり、より効率的です。ただし、問題もあります。SQL で uuid() や rand() などの関数を使用すると、スレーブ データベースにコピーされるデータに偏りが生じます。
• 行ベースのレプリケーションとは、サイドステートメントを実行する代わりに、更新されたデータをスレーブデータベースにコピーすることを指します。 MySQL 5.1 以降でのみサポートされます。
• ハイブリッド レプリケーションでは、デフォルトでステートメント レプリケーションが使用されます。ステートメントがデータを正確にレプリケートできないことが判明した場合 (たとえば、ステートメントに uuid() や rand() などの関数が含まれている場合)、行ベースのレプリケーションが使用されます。
  

マスタースレーブ複製原理

MySQL レプリケーションの原理は、おおまかに 3 つのステップに分けられます。

1. マスター データベースのデータの変更をバイナリ ログに記録します。
2. スレーブ データベースは、マスター データベース上のログを独自のリレー ログにコピーします。
3. スレーブ データベースはリレー ログ内のイベントを読み取り、スレーブ データベース データの上に再生します。
   

主なプロセスは次のとおりです。

コピーの 3 つのステップを詳しく見てみましょう。

最初のステップは、マスター データベースにバイナリ ログを記録することです。まず、マスター データベースで binlog ログ機能を有効にし、スレーブ データベースがアクセスできるように許可する必要があります。ここで注意すべき点は、binlog ログ内の順序は、各ステートメントが実行された順序ではなく、トランザクションが送信された順序で記録されることです。

ステップ 2: ライブラリから binLog をローカルの RelayLog にコピーします。まず、スレーブ データベースは I/O スレッドと呼ばれる作業スレッドを開始します。I/O スレッドは、マスター データベースとの通常のクライアント接続を確立します。次に、マスター データベースで特別なバイナリ ダンプ (binlog ダンプ) スレッドが開始されます。このダンプ スレッドは、binlog 内のイベントを読み取ります。メイン データベースに追いついた後、メイン データベースから新しい更新ステートメントが通知されるまで休止状態になります。 このようにして、バイナリログ データは、スレーブ ライブラリの I/O スレッドとマスター ライブラリのバイナリログ ダンプ スレッドを介して、スレーブ ライブラリのリレーログに転送されます。

ステップ 3: スレーブ データベースで SQL スレッドを開始し、リレーログからイベントを読み取り、スレーブ データベースで実行してスレーブ データベースのデータを更新します。

==このレプリケーション アーキテクチャにより、イベントの取得とイベントの再生が分離され、実行中の I/O スレッドは SQL スレッドから独立して動作できるようになります。ただし、このアーキテクチャではレプリケーション プロセスも制限されます。最も重要な点は、リレー ログ内のイベントを再生する SQL スレッドが 1 つしかないため、プライマリ データベースで同時に実行されているクエリはスタンバイ データベースではシリアルにしか実行できないことです。 ==

マスタースレーブレプリケーションのシリアル実行の問題に関しては、以前仕事で遭遇した問題を思い出しました。データのバッチを初期化する操作を行うビジネスシナリオがありました。データは外部システムのインターフェースから取得されました。次に、スレッドプール内の複数のスレッドを使用して、外部システムのインターフェースからデータを並列に取得しました。各スレッドがデータを取得すると、そのデータは直接データベースに挿入されました。次に、すべてのデータがデータベースに入力された後、バッチ クエリが実行され、データベースに挿入されたばかりのデータがクエリされ、ElasticSearch に格納されます。その結果、ES に入力されたデータは常に不完全でした。長い間研究した後も、まだ機能しませんでした。最終的に、クエリをメイン データベースに送信することで問題は解決しました。当時は、この問題が MySQL マスタースレーブレプリケーションのシリアル化によって発生していることを知りませんでした。

MySQL マスタースレーブレプリケーションモード

MySQL のマスター/スレーブ レプリケーションは、非同期レプリケーション、半同期レプリケーション、GTID レプリケーションなど、複数のレプリケーション モードをサポートしています。

非同期モード

MySQL のデフォルトのレプリケーション モードは非同期モードです。これは主に MySQL マスター サーバー上の I/O スレッドを指します。binlong にデータを書き込んだ後、データがスレーブ サーバーに送信されてリレーログに書き込まれるかどうかに関係なく、成功したデータ更新をクライアントに直接返します。このモードでは、データのコピーは実際にはリスクを伴います。データがマスター データベースの binlog にのみ書き込まれ、スレーブ データベースに時間内に同期されない場合、データ損失が発生します。

ただし、データの変更機能はメイン データベース内でのみ完了する必要があり、データベースからデータをコピーしてもメイン データベースのデータ書き込み操作には影響しないため、このモードは確かに最も効率的です。

上で述べたように、この非同期レプリケーション モードは非常に効率的ですが、データ損失のリスクが非常に高いため、後で導入される半同期レプリケーション モードがあります。

半同期モード

MySQL はバージョン 5.5 以降、プラグインの形式で半同期マスター スレーブ レプリケーション モードをサポートしています。半同期マスタースレーブレプリケーションモードとは何ですか? 比較しながら説明します。

• 非同期レプリケーション モード: 上で紹介したように、非同期レプリケーション モードでは、マスター データベースがクライアントから送信されたトランザクションを実行した後、実行ロジックが binlog に書き込まれている限り、すぐにクライアントに戻り、スレーブ データベースが正常に実行されたかどうかを気にしません。これには隠れた危険があります。つまり、マスター データベースによって実行された binlog がスレーブ データベースに同期されていない場合、マスター データベースがハングアップします。このとき、スレーブ データベースは強制的にマスター データベースに昇格され、データ損失が発生する可能性があります。
• 同期レプリケーション モード: マスター データベースは、クライアントから送信されたトランザクションを実行した後、すべてのスレーブ データベースもトランザクションを実行するまで待機してから、クライアントに正常な実行を返す必要があります。すべてのスレーブライブラリが実行されるまで待機する必要があるため、実行プロセスがブロックされ、結果が返されるのを待つことになり、パフォーマンスに重大な影響が出ます。
• 半同期レプリケーション モード: 半同期レプリケーション モードは、非同期と同期の中間のレプリケーション モードと言えます。マスター データベースは、クライアントから送信されたトランザクションを実行した後、少なくとも 1 つのスレーブ データベースがバイナリ ログを受信し、リレー ログにデータを書き込むまで待機してから、クライアントに成功した結果を返す必要があります。半同期レプリケーション モードでは、非同期モードに比べてデータの可用性が向上しますが、少なくとも TCP/IP 接続の往復時間に相当する一定のパフォーマンス遅延も発生します。
  

半同期レプリケーション モードでは、トランザクションが正常にコミットされた後、トランザクションが少なくとも 2 つの場所 (マスター データベースとスレーブ データベースの 1 つ) に存在することは明らかです。主な原理は、マスターのダンプ スレッドがスレーブに通知するときに、スレーブがトランザクション フラグ コードを受信したかどうかを確認する ACK メカニズムが追加されることです。マスターのダンプ スレッドは、binlog をスレーブに送信するだけでなく、スレーブの ACK を受信する役割も担います。例外が発生し、スレーブがトランザクションを ACK しない場合、例外が修正されるまで自動的に非同期レプリケーションにダウングレードされ、その後自動的に半同期レプリケーションに変更されます。

MySQL の半同期レプリケーションのプロセスは次のとおりです。

半同期レプリケーションの隠れた危険性 半同期レプリケーション モードにも、特定のデータ リスクがあります。トランザクションがマスター データベースに送信され、スレーブ データベースの ACK を待機しているときに、マスターがダウンすると、この時点で 2 つの問題が発生します。

• トランザクションがスレーブに送信されていない場合: トランザクションがスレーブに送信されていない場合、クライアントは失敗結果を受け取った後、トランザクションを再送信します。再送信されたトランザクションは新しいマスターで実行されるため、正常に実行されます。その後、以前のマスターが復元されると、スレーブとしてクラスターに参加します。このとき、以前のトランザクションは 2 回実行されます。1 回目はこのマシンが以前マスターだったときで、2 回目はスレーブになった後にメイン データベースから同期されます。
• トランザクションはスレーブに同期されました: トランザクションはスレーブに同期されているため、クライアントが失敗結果を受信して​​トランザクションを再度送信すると、トランザクションは現在のスレーブ マシンで 2 回実行されます。
  

上記の隠れた危険性を解決するために、MySQL はバージョン 5.7 以降で新しい半同期モードを追加しました。新しい半同期方式の実行プロセスは、「ストレージ コミット」ステップを「スレーブ ダンプの書き込み」の後に移動します。これにより、スレーブ トランザクションが ACK された後にのみ、マスター データベース トランザクションがコミットされるようになります。 MySQL 5.7.2 では、設定用の新しいパラメータ rpl_semi_sync_master_wait_point が追加されました。このパラメータには、設定可能な値が 2 つあります。

• AFTER_SYNC: パラメータ値が AFTER_SYNC の場合、新しい半同期レプリケーション方式が使用されることを意味します。
• AFTER_COMMIT: 古い半同期レプリケーション モードが使用されていることを示します。

MySQL バージョン 5.7.2 以降、デフォルトの半同期レプリケーション モードは AFTER_SYNC モードですが、このソリューションは万能薬ではありません。AFTER_SYNC モードでは、トランザクションがスレーブに同期された後にのみ、マスター データベースのトランザクションがコミットされるためです。マスター データベースがスレーブ データベースの正常な同期を待機している間にマスターがハングアップすると、マスター トランザクションの送信は失敗し、クライアントもトランザクション実行失敗の結果を受け取ります。ただし、binLog の内容はスレーブの Relay Log に書き込まれています。このとき、スレーブ データは多くなりますが、データが多いことによる問題は一般に深刻ではありません。データが多いほど、少ないよりも優れています。 MySQL は、分散データの一貫性の問題を解決できない場合でも、データが失われないことを保証できます。データを失うよりも、データが多いほうが常に良いです。

半同期レプリケーション モードのパラメータは次のとおりです。

mysql> '%Rpl%' のような変数を表示します。
+------------------------------------------+------------+
| 変数名 | 値 |
+------------------------------------------+------------+
| rpl_semi_sync_master_enabled | オン |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_for_slave_count | 1 |
| rpl_semi_sync_master_wait_no_slave | オン |
| rpl_semi_sync_master_wait_point | AFTER_SYNC |
| rpl_stop_slave_timeout | 31536000 |
+------------------------------------------+------------+

-- 準同期レプリケーションモードスイッチ rpl_semi_sync_master_enabled
-- 半同期レプリケーション、タイムアウト（ミリ秒単位）。この時間を超えると、自動的に非同期レプリケーション モードに切り替わります rpl_semi_sync_master_timeout
-- MySQL 5.7.3 で導入されたこの変数は、マスターがクライアントに戻る前に待機する必要があるスレーブ応答の数を設定します。デフォルト値は 1 です。
rpl_semi_sync_master_wait_for_slave_count
-- この値は、現在のクラスタ内のスレーブの数が、現在設定されている半同期レプリケーション モードを満たすことができるかどうかを示します。デフォルト値は ON です。半同期レプリケーション モードが満たされない場合、すべてのスレーブは非同期レプリケーションに切り替わり、この値も OFF になります。
rpl_semi_sync_master_wait_no_slave
-- 準同期レプリケーションがトランザクションをコミットする方法を表します。5.7.2 以降では、デフォルトは AFTER_SYNC です。
rpl_semi_sync_master_wait_point 

GTID モード

MySQL はバージョン 5.6 以降、GTID レプリケーション モードを導入しました。GTID はグローバル トランザクション識別子の略語です。GTID は UUID+TransactionId で構成されます。UUID は単一の MySQL インスタンスの一意の識別子です。MySQL インスタンスが初めて起動されると、server_uuid が自動的に生成され、デフォルトでデータ ディレクトリの auto.cnf (mysql/data/auto.cnf) ファイルに書き込まれます。 TransactionId は、MySQL サーバー上で実行されたトランザクションの数であり、トランザクションの数が増えるにつれて増加します。これにより、GTID がレプリカのセット内でグローバルに一意であることが保証されます。

このように、GTID を通じて、現在のトランザクションがどのインスタンスから送信されたか、および送信されたトランザクションの数を明確に確認できます。

GTID の具体的な形式を見てみましょう。

mysql> マスターステータスを表示します。
+-----------+----------+--------------+------------------+--------------------------------------------------------+
| ファイル | 位置 | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-----------+----------+--------------+------------------+--------------------------------------------------------+
| on.000003 | 187 | | | 76147e28-8086-4f8c-9f98-1cf33d92978d:1-322|
+-----------+----------+--------------+------------------+--------------------------------------------------------+
セット内の 1 行 (0.00 秒)

GTIDの仕組み

マスター/スレーブ レプリケーション クラスターのセットにおける GTID の一意性により、各 GTID トランザクションは 1 つの MySQL で 1 回だけ実行されることが保証されます。 では、このメカニズムはどのように実装されるのでしょうか? GTID の原理とは何ですか?

スレーブサーバーがマスターサーバーに接続すると、実行した GTID (Executed_Gtid_Set: 実行されたトランザクションコード) と取得した GTID (Retrieved_Gtid_Set: スレーブがマスターから受信したトランザクション番号) をマスターサーバーに渡します。マスター サーバーは、不足している GTID と対応するトランザクション ID をスレーブ サーバーからスレーブ サーバーに送信し、スレーブ サーバーがデータを補完できるようにします。プライマリ サーバーがダウンすると、データを最も正常に同期する conf サーバーが検出され、プライマリ サーバーに直接昇格されます。最も成功したスレーブ サーバー以外のスレーブ サーバーが強制的にマスターになる場合、最も成功したサーバーに変更コマンドが送信され、GTID が完成し、強制されたサーバーがマスターに昇格されます。

主なデータ同期メカニズムは、次の手順に分けられます。

• ==マスターがデータを更新すると、トランザクションの前に GTID を生成し、それを binlog に記録します。 ==
• ==スレーブ I/O スレッドは変更されたバイナリログをリレー ログに書き込みます。 ==
• ==SQL スレッドはリレー ログから GTID を取得し、スレーブ側の binlog にレコードがあるかどうかを比較します。 ==
• ==レコードがある場合は、この GTID のトランザクションが実行されたことを意味し、スレーブはこの GTID を無視します。 ==
• ==レコードがない場合、スレーブはリレーログから GTID トランザクションを実行し、それをバイナリログに記録します。 ==
• ==解析プロセス中に、主キーがあるかどうかを判断します。主キーがない場合は、セカンダリ インデックスを使用します。セカンダリ インデックスがない場合は、テーブル全体をスキャンします。 ==

初期構造は次の通りです

上図から、マスターがハングアップしたときに、スレーブ 1 はマスターのトランザクションを完了していますが、スレーブ 2 は少し遅れているため、マスターのトランザクションを完了していないことがわかります。このとき、スレーブ 1 はマスターに昇格します。スレーブ 2 は新しいマスター (スレーブ 1) に接続した後、最新の GTID を新しいマスターに送信し、次にスレーブ 1 はこの GTID の次の GTID からスレーブ 2 にトランザクションを送信し始めます。この自己検出レプリケーション モデルにより、トランザクション損失の可能性と障害からの回復時間が削減されます。

GTIDの利点と欠点

上記の分析から、GTID の利点は次のようになると結論付けることができます。

• ==各トランザクションは実行 ID に対応しており、GTID はサーバー上で 1 回だけ実行されます。==
• ==GTID は従来のレプリケーション方法に代わるものです。GTID レプリケーションと通常のレプリケーション モードの最大の違いは、バイナリ ファイル名と場所の指定が不要なことです。==
• ==手動介入とサービスのダウンタイムを削減します。メインマシンに障害が発生した場合、ソフトウェアを使用して、多数のバックアップマシンの中からバックアップマシンをメインマシンに昇格させることができます。==

GTID の欠点も明らかです。

• ==まず、非トランザクションストレージエンジンはサポートされていません。==
• ==create table ... select ステートメントのレプリケーションはサポートされていません (マスター データベースは直接エラーを報告します); (原則: 2 つの SQL ステートメントが生成されます。1 つはテーブルを作成するための DDL SQL ステートメントで、もう 1 つはデータを挿入するための SQL ステートメントです。DDL は自動コミットを引き起こすため、この SQL ステートメントには少なくとも 2 つの GTID が必要ですが、GTID モードでは、この SQL ステートメントに対して 1 つの GTID しか生成できません)==
• ==SQL ステートメントでは、トランザクション エンジン テーブルと非トランザクション エンジン テーブルを同時に更新することはできません。==
• ==MySQL レプリケーション グループでは、すべての GTID を有効または無効にする必要があります。 ==
• ==GTID を有効にするには再起動が必要です (mysql5.7 を除く);==
• ==GTID を有効にすると、元の従来のレプリケーション方法は使用されなくなります (障害発生後に非同期レプリケーションにダウングレードできる半同期レプリケーションとは異なります)。==
• ==一時テーブルの作成および一時テーブルの削除ステートメントはサポートされていません。==
• ==sql_slave_skip_counter はサポートされていません;==
  

実際、GTID に関するコンテンツはたくさんあります。詳しく学びたい場合は、この記事を読んでみてください。 最後に、GTID を有効にするために必要な条件について説明します。

• MySQL 5.6 バージョンの場合、my.cnf ファイルに以下を追加します。

gtid_mode=on (必須) # gtid 関数を有効にする log_bin=log-bin=mysql-bin (必須) # binlog バイナリログ関数を有効にする log-slave-updates=1 (必須) # 1 を on として記述することもできます
強制gtid-consistency=1 (必須) #1と書くこともできます

• MySQL 5.7 以降の場合は、my.cnf ファイルに以下を追加します。

gtid_mode=on (必須)
強制gtid一貫性=1 (必須)
log_bin=mysql-bin (オプション) #高可用性スイッチング、この機能を有効にするのがベストです log-slave-updates=1 (オプション) #高可用性スイッチング、この機能を有効にするのがベストです

以上がMySQLの半同期の詳しい説明です。MySQLの半同期についてさらに詳しく知りたい方は、123WORDPRESS.COMの関連記事もぜひご覧ください！