レプリケーション
データベースの複製と高可用性
レプリケーションの目的
高可用性
障害時にレプリカに切り替えてサービス継続
負荷分散
読み取りクエリをレプリカに分散
災害対策
地理的に離れた場所にデータを保持
同期 vs 非同期
| 項目 | 同期レプリケーション | 非同期レプリケーション |
|---|---|---|
| データ整合性 | 強い（データロスなし） | 弱い（遅延あり） |
| パフォーマンス | 遅い（レプリカ待ち） | 速い |
| ネットワーク障害時 | 書き込み停止 | 継続可能 |
| ユースケース | 金融、重要データ | 読み取り分散、分析 |
準同期レプリケーション
少なくとも1つのレプリカに同期、残りは非同期。 データ損失リスクと性能のバランス。MySQL Semi-Sync等。
レプリケーション構成
マスター・スレーブ（Primary-Replica）
1つのマスターが書き込みを受け付け、スレーブに複製。読み取りはスレーブに分散可能。
Primary
Write/Read
Replica 1
Read
Replica 2
Read
マルチマスター
複数のノードが書き込みを受け付け。コンフリクト解決が必要。 Galera Cluster、CockroachDB等。
カスケードレプリケーション
レプリカから別のレプリカに複製。マスターの負荷を軽減。 地理的に分散した構成に有効。
フェイルオーバー
自動フェイルオーバー
監視システムが障害を検知し、自動的にレプリカを昇格。 ダウンタイム短縮。スプリットブレインに注意。
例: PostgreSQL + Patroni, MySQL + Orchestrator
手動フェイルオーバー
運用者が判断して切り替え。確実だが時間がかかる。 計画的メンテナンス向き。
レプリケーションラグ
非同期レプリケーションでは、マスターとレプリカ間でデータの遅延が発生する。
- • 問題: 書き込み直後の読み取りで古いデータが返る
- • 対策: Read-your-writes一貫性、クリティカルリードはPrimaryから
- • 監視: レプリケーションラグのメトリクスを常時監視
1 -- PostgreSQL: レプリカラグ確認 2 SELECT 3 client_addr, 4 state, 5 pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn) AS sent_lag, 6 pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag 7 FROM pg_stat_replication; 8 9 -- MySQL: レプリカラグ確認 10 SHOW SLAVE STATUS\G 11 -- Seconds_Behind_Master を確認
SRE/インフラ観点
構成の推奨
- • 最低3ノード（Primary + 2 Replica）で冗長性確保
- • 同期レプリカを1つは維持（データ保護）
- • 異なるAZ/リージョンに配置（災害対策）
監視項目
- • レプリケーションラグ（秒、バイト）
- • レプリカの接続状態
- • WAL/Binlog の生成・送信量
- • フェイルオーバー履歴