【Database Replication】３つのStandby Modeをちゃんと理解する。

Database Replicationとは

文字通り「DBを複製する」こと。
複製する方法としてLogical ReplicationとPhysical Replicationが存在する。

Logicalな複製
👉論理的な更新情報(更新用SQL)の転送と適用。
👉異なる構成のDB間でデータ連携/複製する用途に向いている。

Physicalな複製
👉物理的な変更情報(ログ)の転送と適用。
👉同一構成のDBを複製する用途に向いている。

本稿では主に「ReplicationしたやつをどうStandbyさせておくか」について記すので、LogicalとPhysicalの違いについては一旦割愛する。

DB Replicationの何がいいの？

✅参照性能の向上　※読み取り専用(ReadReplica)を作成する場合に限る
✅高可用性の実現
✅Primaryを止めずにCold Backup可能。

Replicationなし

複製しない場合、どのようにDBサーバを運用することになるかまとめてみる。
✅DBサーバは１つのみ。
✅Backupを毎日取得する。Backup保管場所はDBサーバ以外のところに。
✅DBサーバが死んだら、人間が手動で新しいDBサーバを作成＆Backupを元にRestoreする。

Replicationあり

複製するDBサーバをどのように待機/Standbyさせておくかで、だいぶ運用方法が変わってくる

Hot Standby

✅Standbyは読み取り専用(Read Replica)として常時起動。
✅Primaryに対する更新を逐一Standbyに反映する。
✅Primaryが死んだら、StandbyをPrimaryに昇格する。

Warm Standby

✅Primaryが生きている限り、StandbyはClientから参照されない。
✅Primaryが生きている間も、Standbyは起動しながらPrimaryからの更新を反映する。
✅Primaryが死んだら、StandbyはPrimaryに昇格する。

Cold Standby

✅Primaryが生きている間は、Standbyは起動されない状態。
✅PrimaryはStandbyがRestoreするためのLogを逐一連携しておく。
✅Primaryが死んだ後でStandbyを起動＆Primaryが連携しておいてくれたLogを
　 利用してRestoreを実施＆最終的にPrimaryに昇格する。

Replicationの仕組み = ログを連携する。

PostgreSQL

PostgreSQLでは、WAL(ログ先行書き込み/Write Ahead Log)の仕組みでトランザクションログが生成されるので、これをReplicationに利用する。

MySQL

MySQLでは、トランザクションの記録がバイナリログに出力されるため、これをReplicationに利用する。