MySQLのmaster–replica replicationはどのように機能し、読み取りのスケーリングにどう役立ちますか。

Question

IT Interview Practice · Accepted Answer

replicationは、**source（master）**から1つ以上の**replica**へ変更をストリーミングします。sourceはコミットされたすべての変更を**binary log（binlog）**に記録します。各replicaのI/Oスレッドがそのログをコピーし、SQL/applierスレッドがそれを再適用するため、replicaは同じデータへ収束します。 ## 流れ ``` writes app ---------> [ SOURCE ] --- binlog ---> [ replica 1 ] <-- reads | [ replica 2 ] <-- reads +---------- binlog ---> [ replica 3 ] <-- reads ``` - **フォーマット** — `ROW`（実際の行イメージを記録、安全な既定値）、`STATEMENT`、`MIXED`。 - **Async（既定）** — sourceはreplicaを待たずにコミットします。高速ですが、replicaが遅延しうる。 - **Semi-sync** — sourceは少なくとも1つのreplicaの確認応答を待ち、わずかなレイテンシと引き換えに耐久性を得ます。 ## 読み取りのスケーリング書き込みはsourceへ向け、`SELECT`はreplicaに分散します。読み取り中心のアプリ（ほとんどのWebアプリ）は、replicaを追加することで読み取りをほぼ線形にスケールでき、一方で単一のsourceが依然としてすべての書き込みを処理します。 ```sql -- On a replica, watch how far behind it is: SHOW REPLICA STATUS\G -- Seconds_Behind_Source: 2 <- replication lag -- Replica_IO_Running: Yes -- Replica_SQL_Running: Yes ``` ## 落とし穴: レプリケーション遅延非同期のreplicaはsourceに遅れて追随するため、書き込んだ直後にreplicaから読むユーザーは自分の変更を見られないことがあります（「read-your-writes」違反）。レイテンシに敏感な読み取りや書き込んだ直後の読み取りはsourceへルーティングするか、semi-syncを使ってください。 ## なぜ重要なのか replicationは、読み取りをスケールし、フェイルオーバー/バックアップ用のウォームスタンバイを得るための標準的な最初の一歩です。その決定的な制約、すなわち遅延と単一書き込みのボトルネックは、実際の設計を形作ります。ときに古いデータを読む理由や、書き込みのスケーリングが最終的にはreplicaを増やすだけでなくshardingを必要とする理由を説明します。

流れ

読み取りのスケーリング

落とし穴: レプリケーション遅延

なぜ重要なのか

関連する質問