「詳解MySQL 5.7 止まらぬ進化に乗り遅れないためのテクニカルガイド」という本から、古いバージョンだがMySQL5.7のレプリケーションの仕組みについて学んだので整理する。

レプリケーションの構造

レプリケーションとは、マスターとスレーブという関係のある異なるデータベースにおいて、マスターの変更がスレーブにも適用されることで、それぞれのデータベースで同じデータを持つようにするための機能のことである。
レプリケーションによって、レプリカ側でデータをバックアップするなどが可能であり、データが破損しても復旧できる可能性が高まる。
レプリケーションを実現するための重要な機能は以下の通り。

接続スレッド、バイナリログ、マスタースレッド、スレーブIOスレッド、リレーログ、スレーブSQLスレッド

それぞれ解説します。

接続スレッド(サーバスレッド)

マスターに接続したクライアントからやってくるSQL文を処理する。
クライアントから新しく接続されるたびにスレッドは新しく生成される。

バイナリログ

MySQLサーバーで発生したすべての変更を記録する。
このバイナリログをスレーブ側に送ることでレプリケーションを行う。

バイナリログの形式にはstatement-based replication (SBR), row-based replication (RBR), Row baseとStatement baseを組み合わせたmixed-format replication (MIXED)の3種類がある。
SBRではバイナリログにSQLステートメントがそのまま記録され、スレーブ側でそのステートメントを実行されるのだが、SQLの内容によってはスレーブで実行された結果が必ずしもマスター側の結果と一致しないという問題があった。
そこで、ステートメントを実行した結果をバイナリログに記録し、それをスレーブ側に適用することで、SBRが持っていた問題を解消するRBRができたという背景がある。

マスタースレッド

バイナリログを読み取ってスレーブに送る役割を持つ。
レプリケーション時にスレーブがマスターに接続し、スレーブがマスターにバイナリログを送信するよう指示を出すのだが、そのときマスタースレッドがスレーブにバイナリログを送る。

スレーブIOスレッド

マスターから受け取った更新データをリレーログに保存する。

リレーログ

バイナリログと同じフォーマットを持つログファイルで、リレーという名前から分かるように、受け取ったデータを横に流す役割を持つ。
つまりスレーブIOスレッド＞リレーログ＞スレーブSQLスレッドという流れでデータが送られる。

スレーブSQLスレッド

リレーログから受け取ったデータの更新の差分を受け取ってスレーブ上で再生することで、スレーブ側のデータベースにマスターと同じ更新が適用される。

上記をまとめると、レプリケーションの基本的な流れは以下のようになる。

1. マスターとクライアントが接続

2. 接続スレッドがクライアントからSQL文を受け取る

3. ストレージエンジンにコミット（2相コミットのPREPARE）する

4. バイナリログを更新する

5. ストレージエンジンにコミット（2相コミットのCOMMIT）する

6. マスタースレッドがバイナリログを読み込んでスレーブのIOスレッドに送信

7. リレーログに記録

8. リレーログからスレーブSQLスレッドにバイナリログが送られる

9. バイナリログの内容がスレーブのストレージエンジンに適用される