PostgreSQLの物理レプリケーションは、データベースの物理的なデータ（つまり、ディスク上のバイナリファイル）を基にデータベース全体を複製し、データベースの可用性やデータの冗長性を確保する方法です。これは、マスターサーバー（プライマリ）からスレーブサーバー（スタンバイ）にWAL（Write-Ahead Log）を送信し、それをリプレイしてスタンバイサーバーをプライマリと同じ状態に保つ仕組みです。
物理レプリケーションの概要
WAL (Write-Ahead Log) の利用: PostgreSQLは、すべてのデータ変更をWALに記録します。物理レプリケーションでは、プライマリサーバー上のWALがスタンバイサーバーにストリームされ、スタンバイ側でリプレイされます。これにより、スタンバイサーバーがプライマリサーバーの状態と同期されます。
同期レプリケーションと非同期レプリケーション: 物理レプリケーションには、同期と非同期の2種類のモードがあります。
非同期レプリケーション: WALの変更がプライマリサーバーからスタンバイサーバーに送られますが、プライマリはスタンバイがその変更を受け取るのを待たずに次の処理を続行します。この方式は高いパフォーマンスが得られますが、スタンバイがプライマリに追いつく前に障害が発生するとデータが失われる可能性があります。
同期レプリケーション: プライマリサーバーがトランザクションをコミットする前に、スタンバイサーバーがその変更を確実に受け取ったことを確認します。これにより、データの一貫性が高まりますが、遅延が増加する可能性があります。
スタンバイサーバーの役割: スタンバイサーバーは通常、プライマリサーバーのフェイルオーバー目的で使用されます。プライマリが障害を起こした場合、スタンバイサーバーをプライマリサーバーに昇格させることができます。この操作は手動または自動で行うことができます。
- レプリケーションの手順:
スタンバイサーバーを作成する際、プライマリサーバーのデータ全体を物理的にコピーします（ベースバックアップ）。 スタンバイサーバーはその後、プライマリサーバーからWALを受け取り、リプレイしてデータを最新の状態に保ちます。 ホットスタンバイ: 物理レプリケーションを使用する場合、スタンバイサーバーはリードオンリークエリを受け付けることが可能です。この設定を「ホットスタンバイ」と呼び、スタンバイサーバーをバックアップ目的だけでなく、リードクエリを分散させるためにも使用できます。
- 物理レプリケーションの利点
高可用性: プライマリサーバーがダウンした場合、スタンバイサーバーにフェイルオーバーすることで、ダウンタイムを最小限に抑えられます。
データの整合性: 同期レプリケーションを使うことで、データの整合性が確保され、スタンバイサーバーがプライマリサーバーと完全に同期された状態で維持されます。
負荷分散: ホットスタンバイを使用することで、リードオンリークエリをスタンバイサーバーで処理し、プライマリサーバーの負荷を軽減できます。
- 物理レプリケーションの欠点 データ転送量の増加: WALのストリーミングにより、ネットワーク帯域が消費されます。トランザクションの量が多い場合、WALが頻繁に転送されるため、ネットワーク負荷が高くなる可能性があります。
スタンバイサーバーのディスク消費: スタンバイサーバーもプライマリサーバーと同じ量のディスクスペースを消費します。WALの履歴も保存されるため、ディスク容量の管理が重要です。
まとめ
PostgreSQLの物理レプリケーションは、WALを使ってプライマリサーバーとスタンバイサーバーのデータを同期し、フェイルオーバーや負荷分散、高可用性を実現するための重要な仕組みです。データの一貫性と冗長性を確保しつつ、運用の効率を向上させるために、多くの企業で利用されています。
