章: 第6章: セキュリティと本番運用
DBサーバーが1台だけ、もし障害が起きたらどうなりますか？
単一のMySQLサーバーにすべての読み書きが集中している構成では、サーバー障害時にサービスが完全停止します。また、アクセスが増えるにつれて読み取りクエリの負荷が書き込みを圧迫し、全体のパフォーマンスが低下する問題も起きます。
レプリケーションを導入すると、PrimaryがReplicaにデータを非同期で同期し、読み取りをReplica側に分散させることができます。 可用性の向上とパフォーマンス改善を同時に実現する基礎技術です。
レプリケーションの構成パターンと特徴
| 構成 | 読み取り分散 | 書き込み冗長化 | 複雑さ | 向いているケース |
| 単一インスタンス | 不可 | なし | 低 | 開発・小規模サービス |
| Primary-Replica（1対1） | 可（Replicaで読む） | 手動フェイルオーバー | 中 | 中規模サービス・読み取り負荷が高い場合 |
| Primary-Replica（1対多） | 可（複数Replicaに分散） | 手動フェイルオーバー | 中〜高 | 大規模な読み取り負荷分散 |
| Group Replication / InnoDB Cluster | 可 | 自動フェイルオーバー | 高 | 高可用性が必須の本番環境 |
チェックポイント: レプリケーション遅延（Replica Lag）に注意してください。書き込み直後のデータをReplicaから読み取ると古いデータが返ることがあります。書き込み後すぐに読み取りが必要なフローは、Primaryから読む設計にしてください。
SHOW REPLICA STATUS\GのSeconds_Behind_Sourceで遅延を監視します。
実際のコードサンプル
-- レプリカ状態確認（例）
SHOW REPLICA STATUS\G
-- 遅延やエラーの監視項目を定義して運用する
まとめ & 次のステップ
- レプリケーションの基本はPrimary（書き込み）とReplica（読み取り）の役割分担
- まずはPrimary-Replica構成の読み取り分離から理解し、段階的に拡張を検討する
SHOW REPLICA STATUS\Gでレプリカ遅延（Seconds_Behind_Source）を定期的に監視する- 書き込み直後の読み取りはPrimaryから行い、Replica遅延によるデータ不整合を防ぐ
- フェイルオーバー手順は事前に文書化し、障害時に慌てず対応できる状態にしておく
次回は 本番運用チェックリスト（MySQL版） を学びます。MySQL本番環境で確認すべき設定・監視・バックアップの観点をまとめて整理します。
