- PostgreSQL の Streaming Replication は、プライマリ DB のほぼリアルタイムなレプリカを 1 台以上のスタンバイサーバーで維持する効率的な方法
- プライマリサーバーは Write-Ahead Log(WAL)レコードを生成され次第、スタンバイサーバーへ継続的に送信し、レプリケーション過程の遅延を最小化
- 高可用性とスケーラビリティ向上のために設計されており、読み取りクエリをスタンバイサーバーへオフロードしてプライマリサーバーの負荷を減らせる
- 同期式と非同期式の両モードをサポートし、データ整合性と性能のバランスを柔軟に調整可能
- スタンバイサーバーがプライマリに接続して WAL ストリーミングを要求し、受信したレコードを自身の DB コピーに適用する過程を含む
- ファイルベースのログ転送と比べて、より高速なフェイルオーバーとデータ損失リスクの低減を実現し、地理的に分散した環境に最適
Streaming Replication はどのように動作するのか?
- プライマリサーバーからスタンバイサーバーへ WAL データをリアルタイムで継続的に転送し、スタンバイの DB をプライマリとほぼ同一の状態に維持
- これにより、マスターのフェイルオーバーや読み取り処理のためにレプリカを利用でき、システムを数倍規模に拡張可能
PostgreSQL 設定ファイルと配置場所
- PostgreSQL の構成ファイルは、データベースサーバーの設定と動作を管理するうえで重要な役割を果たす。
postgresql.conf: 大半のサーバー設定を含む主要な設定ファイル。OS に応じて /etc/postgresql/<version>/main/postgresql.conf(Debian/Ubuntu)または /var/lib/pgsql/<version>/data/postgresql.conf(Red Hat/CentOS)など、さまざまな場所にある
pg_hba.conf: クライアント認証を制御し、クライアントがサーバーへどのように接続するかを定義。通常は postgresql.conf と同じディレクトリにある
pg_ident.conf: ユーザー名マッピングに使われるが、利用頻度は低い
recovery.conf: PostgreSQL 12 より前のバージョンではスタンバイサーバー構成に使われていたが、それ以降のバージョンでは内容が postgresql.conf と postgresql.auto.conf に移された
- 正確な場所は OS、インストール方法、PostgreSQL のバージョンによって異なる場合がある
SHOW config_file; SQL コマンドを使うと、PostgreSQL インスタンス内でこれらのファイルの場所を確認できる
WAL(Write Ahead Logs)の例と構造
pg_waldump コマンドで WAL を確認できる
- 各行は、DB 操作に関する情報を含む WAL レコードを表す
- 各レコードの構成要素:
- rmgr: リソースマネージャー(例: Heap、Btree、Transaction)
- len: レコード長
- tx: トランザクション ID
- lsn: ログシーケンス番号
- prev: 直前の LSN
- desc: 操作説明
- 確認できる操作の種類:
- INSERT 操作(Heap および Btree)
- MULTI_INSERT 操作(Heap2)
- COMMIT トランザクション
- ファイル操作(CREATE)
- Full Page Writes(FPW)
- WAL 出力は、トランザクションの流れ、データ変更、システム活動を詳細に示し、DB の動作分析、トラブルシューティング、ポイントインタイムリカバリに役立つ
Docker で作業する方法
postgresql.conf における Streaming Replication 関連の重要設定:
- wal_level、max_wal_senders、max_replication_slots、hot_standby など
- Docker Compose の例に必要なもの:
init-master.sh: PostgreSQL マスターをレプリケーション用に設定。レプリケーションユーザーとスロットを作成し、WAL 関連設定を更新
init-replica.sh: マスターへ接続し、レプリケーションを開始できるよう PostgreSQL レプリカを準備。マスターの準備完了まで待機した後、ベースバックアップを実行してレプリカを構成
start-replica.sh: Docker コンテナで PostgreSQL レプリカを起動。init-replica.sh スクリプト実行後に PostgreSQL を起動
docker-compose.yml: マスターとレプリカのサービスを定義し、必要な環境変数、ボリューム、コマンドなどを設定
- スクリプトに実行権限を付与した後、
docker-compose up -d を実行するとマスターとレプリカが起動する
- マスターに接続し、
pg_stat_replication でレプリケーション状態を確認可能
- レプリカに接続し、
pg_is_in_recovery() でリカバリモードかどうかを確認可能
GN⁺ の見解
- Streaming Replication は、データベースインフラの性能と回復力を大きく向上させうる。フェイルオーバーシナリオへの備えや、レプリカへ読み取り負荷を分散する場合、DB の拡張性と安定した性能の確保に役立つ
- 構成プロセス全体と出力を示すことは重要。これは多くの可動部分について総合的な視点を提供し、何が起きているのかをよりよく理解する助けになる
- Streaming Replication がどのように動作するかを理解し、正しく構成することは非常に重要。この文章がその過程を明確にし、レプリケーションの動作に関する洞察を与えてくれることを願う
- 類似機能を持つ他の製品やプロジェクトとしては、MySQL の Replication や Oracle の Data Guard がある。これらのソリューションも、マスターから変更をレプリカへ転送する仕組みで動作するが、実装の詳細は異なる場合がある
- Streaming Replication を利用する際は、ネットワーク帯域幅とレイテンシを考慮する必要がある。マスターとレプリカ間のデータ転送は、ネットワークリソースをかなり消費する可能性がある。レプリカのスケーラビリティも重要な検討事項
- データ整合性要件も評価すべき。同期レプリケーションは書き込み性能に影響する可能性があるが、より強い整合性を提供する。非同期レプリケーションはより良い性能を提供する一方、わずかながらデータ損失の可能性がある
1件のコメント
Hacker Newsの意見
この記事は素晴らしいが、フルスタック開発者としてデータベースを管理しようとする観点では、実際の適用事例が不足していると感じる意見がある
PostgreSQL レプリケーションに対する最も簡単なソリューションは Kubernetes オペレーターだと主張している
Kubernetes と Helm を使う理由の1つとして、この問題を解決できると見ている
Kubernetes ユーザーには StackGres を勧めている
最後に、この記事は AI によって書かれたように見えるという懐疑的な意見がある