4 ポイント 投稿者 GN⁺ 2024-10-14 | 1件のコメント | WhatsAppで共有
  • 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.confpostgresql.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件のコメント

 
GN⁺ 2024-10-14
Hacker Newsの意見
  • この記事は素晴らしいが、フルスタック開発者としてデータベースを管理しようとする観点では、実際の適用事例が不足していると感じる意見がある

    • レプリカがマスターよりどの程度遅延しているかを確認する方法についての質問がある
    • レプリカを監視する方法として、簡単な cron ジョブで状態を確認する方法を提案している
    • 複雑な問題として、主サーバーがダウンした場合にレプリカへ切り替える方法についての質問がある
    • 自動で切り替えるべきか、手動で切り替えるべきかについて悩んでいる
    • スプリットブレインのシナリオを避けるために、2つのレプリカが必要なのかという疑問がある
    • 切り替え後に元の状態へ復旧する方法についての質問がある
  • PostgreSQL レプリケーションに対する最も簡単なソリューションは Kubernetes オペレーターだと主張している

    • 例として CloudNativePG に言及している
    • レプリケーションだけでなく、フェイルオーバー、復旧、監視、自動回復、バックアップなども必要だと説明している
    • Kubernetes 以外に、ほかの無料 / オープンソース実装があるかどうかを尋ねている
  • Kubernetes と Helm を使う理由の1つとして、この問題を解決できると見ている

    • Bitnami PostgreSQL パッケージを通じて、ほとんど追加設定なしですべてを構成できると説明している
    • Postgres-ha はプロキシを生成し、障害を専門的に処理することで、無停止フェイルオーバーを可能にすると説明している
  • Kubernetes ユーザーには StackGres を勧めている

  • 最後に、この記事は AI によって書かれたように見えるという懐疑的な意見がある