PostgreSQL BDRの概要
PostgreSQLは、安定した信頼性の高いDBMSであるだけでなく、すべてにプラスであり、リリースごとにさまざまなブレークスルーが現れる動的に開発される製品です。 かつて、これらのテクノロジーの1つはストリーミングレプリケーションでした。 これは、読み取りデータベースのスケーリングを非常に簡単かつ安価にする高性能レプリケーションです。 これを使用して、読み取りの負荷をノード間で分散することにより、信頼できる構成を作成できます。 ただし、上で書いたように、この製品は開発中であり、本日は新しいBDR（Bi-Directional Replication）テクノロジーに焦点を当てます。
件名に含まれていない人のためのいくつかの用語：
WAL（Write Ahead Log）はトランザクションログであり、postgresの組み込みストリームレプリケーションはそれに基づいており、DBMSはデータベース内のデータに発生するすべてをそこに書き込みます。
SR（ストリーミングレプリケーション） -WALに基づく組み込みストリーミングレプリケーションの一般名。WALに書き込まれ、スレーブに送信されて再生されるすべてのもの。 物理的および論理的なストリーミング複製があります。
PLSR（物理ログストリーミングレプリケーション） -物理ストリーミングレプリケーション（既に実装され動作しているもの）、WALに入るすべてのものは、さらに分析することなくサーバースレーブにレプリケートされます。これは、データ/回路の変更および下位レベルのもの（全ページ書き込み、バキューム、ヒントビット設定）。
LLSR（論理ログストリーミングレプリケーション） -論理ストリーミングレプリケーション（9.4に表示）もWALログに基づいていますが、すでによりインテリジェントであり、ログの特定の部分のみがレプリケーションのために抽出され、データベーススキーマとデータの変更を記述します（つまり、いくつかの低レベルのものは削除されます） 。
BDRという用語の下に隠されているものは何ですか？
BDR（双方向レプリケーション）は、高度なレプリケーションツールを提供するPostgreSQLカーネルに追加された新機能です。 現時点では、これは小さなパッチとモジュールとして実装されています。 PostgreSQL 9.5（現在9.3-stableおよび9.4-beta1）でのみ完全にサポートされると述べられています。
要するに、BDRでは、LLSRの組み込み論理ストリームレプリケーションを使用して、地理的に分散した非同期マルチマスター構成（ああ、はい、ベイビー）を作成できます。
ただし、BDRはクラスタリング用のツールではありません。 グローバルロックマネージャーまたはトランザクションコーディネーター（hello Postgres-XC / XL）はありません。 各ノードは他のノードから独立しており、ブロッキングマネージャーが使用されている場合は不可能です。 各ノードには、他のノードのデータと同一のデータのローカルコピーが含まれています。 リクエストもローカルでのみ実行されます（説明を明確にするために、すべてのサーバーが1つのチームのように動作し、トランザクションがグローバルトランザクションマネージャーによってルールされ、アプリケーションからのリクエストがコーディネーターに送信されるPostgres-XC / Postgres-XLと比較します（s ）これは、受信したリクエストを実行する作業ノードに送信します、ここ）。 同時に、各ノードはいつでも内部的に一貫していますが、サーバーのグループ全体は最終的に一貫しています。
BDRの独自性は、組み込みのストリーミングレプリケーションや既存のトリガーベースのソリューション（Londiste、Slony、Bucardo）のようなものではないという事実にあります。
ストリーミングレプリケーションとの最も顕著な違いは、BDR（LLSR）がデータベースごとのレプリケーションで動作するのに対し、従来のPLSRはインスタンス全体（クラスターごとのレプリケーション）をレプリケートすることです。 インスタンス内のすべてのデータベース。
既存の制限と機能：
1. INSERT / DELETE / UPDATEによって引き起こされるすべてのデータ変更が複製されます（書き込み時のTRUNCATEはまだ実装されていません）
2.ほとんどのスキーマ変更（DDL）操作は正常に複製されます。 サポートされていないDDLはレプリケーションモジュールによってコミットされ、エラーで拒否されます（CREATE TABLE ... ASは執筆時点では機能しませんでした）
3.テーブル、タイプ、拡張などの定義 アップストリームマスターとダウンストリームマスター間で同一である必要があります。
4. WALに反映されるが、論理的な変更として表示されないアクションは、別のノードにレプリケートされません（ページ全体の記録、テーブルの退避など）。 したがって、論理ストリーミングレプリケーション（LLSR）は、PLSRの物理ストリーミングレプリケーションに存在するオーバーヘッドの一部を排除します（ただし、これは、LLSRがPLSRよりも少ないネットワーク帯域幅を必要とすることを意味するものではありません）。
おそらく十分な理論、少し練習。 すでに双方向レプリケーションをテストする機会があります。
インストールは、CentOS 6.5最小の2つの仮想マシンで実行されます。 アセンブリに必要なパッケージをインストールします。
# yum install readline-devel zlib-devel yum-utils -y # yum groupinstall "Development Tools" -y
postgresアカウントに移動し、BDRサポート付きのpostgresqlをインストールします。 2ndQuadrantのメンバーがインストーラーを書いたので、試してみたい人がインストールと設定にあまり労力をかけないように注意してください。
# su - postgres $ curl -s "http://git.postgresql.org/gitweb/?p=2ndquadrant_bdr.git;a=blob_plain;f=contrib/bdr/scripts/bdr_quickstart.sh;hb=refs/heads/bdr-next" | bash
postgres実行可能ファイルを含むディレクトリをPATH環境変数に追加し、すぐにpsqlを確認します。 誰も知らないので、 exportコマンドは1回限りです。したがって、BDRを長期間使用するかプレイする予定がある場合は、このコマンドを追加してください。 ユーザーのbashrc （もちろんbashがある場合）。
$ export PATH=$HOME/2ndquadrant_bdr/bdr/bin:$PATH $ psql --version psql (PostgreSQL) 9.4beta1_bdr0601
両方のノードでデータベースディレクトリを初期化し、すぐに開始します。 Postgresql.confを事前に編集する必要はありません;最初の起動時に、将来複製されるテストデータベースを作成します。
$ initdb -D data/ -A trust -U postgres $ pg_ctl -l logfile -D data/ -w start $ psql -c 'create database staging_db'
データベースを作成した後、postgresql.confのセットアップに進みます。 最初に、アップストリームウィザードを構成します。 以下の構成では、bdrライブラリ（ shared_preload_libraries ）をロードし、WALログの冗長レベルを論理レベル（ wal_level ）に決定し、複製のスロット数、WALログの送信に関与するプロセスの最大可能数（ wal_senders ）を決定し、操作の時間追跡を有効にする必要性を示します競合を解決するために必要なものをコミットします（最後のUPDATE-wins）。 次に、ファイルの最後で、BDRの構成を決定します。接続の名前と、リモートホストに接続するための設定を指定します。 bdr.connectionsで示される名前は任意です（この仮想マシンの名前があります）。主なことは、指定された名前が基礎となるパラメーターの名前に参加することです。
$ vi data/postgresql.conf listen_address = '*' shared_preload_libraries = 'bdr' wal_level = logical wal_senders = 4 max_replication_slots = 4 track_commit_timestamp = on bdr.connections = 'vm13' bdr.vm13_dsn = 'host=192.168.122.13 port=5432 user=postgres dbname=staging_db'
構成ダウンストリームウィザード。 まず、構成の説明を行い、次にその分析を説明します。
$ vi data/postgresql.conf listen_address = '*' shared_preload_libraries = 'bdr' wal_level = logical wal_senders = 4 max_replication_slots = 4 track_commit_timestamp = on bdr.connections = 'vm12' bdr.vm12_dsn = 'host=192.168.122.12 port=5432 user=postgres dbname=staging_db' bdr.vm12_init_replica = on bdr.vm12_replica_local_dsn = 'host=127.0.0.1 port=5432 user=postgres dbname=staging_db'
2番目のノードのセットアップにはほとんど違いがありません。特に、BDR構成では、 bdr.vm12_dsnで指定されたノードからbdr.vm12_replica_local_dsnで指定されたローカルデータベースへのレプリカ（ bdr.vm12_init_replica ）を初期化する必要があることを示しています。 最後のパラメーターは、データベースクラスターがinitdbを使用して初期化される場合（この場合）に必要であり、この場合、クラスターに後でレプリケーションに参加する空のデータベースが必要です。
pg_basebackupによる初期化の場合、bdr.vm12_replica_local_dsnオプションは不要です。
ここで、両方のノードの認証設定を決定します。私の場合、すべてが許可されています。 もちろん、実稼働インストールの場合、これは実行できません。
$ vi data/pg_hba.conf host all all 192.168.122.0/24 trust host replication postgres 192.168.122.0/24 trust
両方のノードを再起動し、ログを確認します
$ pg_ctl -l logfile -D data/ -w restart
アップストリームマスター：
vm12〜$ tail -fログファイル
ログ：スタンバイ接続での予期しないEOF
ログ：スロットbdr_16384_6029905891437956874_1_16384__の論理デコードの開始
詳細：0 / 1898F90の後にコミットするストリーミングトランザクション、0 / 1898C30からWALを読み取る
LOG：論理デコードにより、0 / 1898C30に一貫したポイントが見つかりました
詳細：xcnt == 0でxactsを実行する
ログ：バックグラウンドワーカープロセスを開始しています "bdr（6029905879776466735,1,16384、）：vm13：apply"
ログ：スタンバイ接続での予期しないEOF
ログ：スロットbdr_16384_6029905891437956874_1_16384__の論理デコードの開始
詳細：0 / 1898F90の後にコミットするストリーミングトランザクション、0 / 1898C30からWALを読み取る
LOG：論理デコードにより、0 / 1898C30に一貫したポイントが見つかりました
詳細：xcnt == 0でxactsを実行する
ログ：バックグラウンドワーカープロセスを開始しています "bdr（6029905879776466735,1,16384、）：vm13：apply"
ダウンストリームマスター：
vm13〜$ tail -fログファイル
ログ：バックグラウンドワーカーの登録 "bdr（6029905891437956874,1,16384、）：vm12：apply"
ログ：バックグラウンドワーカープロセスを開始しています "bdr（6029905891437956874,1,16384、）：vm12：apply"
LOG：論理デコードで、0 / 18A4290に一貫したポイントが見つかりました
詳細：xcnt == 0でxactsを実行する
LOG：エクスポートされた論理デコードスナップショット：xidが0の「0000071B-1」
ログ：スロットbdr_16384_6029905879776466735_1_16384__の論理デコードの開始
詳細：0 / 18A42C8の後にコミットするストリーミングトランザクション、0 / 18A4290からWALを読み取る
LOG：論理デコードで、0 / 18A4290に一貫したポイントが見つかりました
詳細：xcnt == 0でxactsを実行する
ログ：バックグラウンドワーカーの登録 "bdr（6029905891437956874,1,16384、）：vm12：apply"
ログ：バックグラウンドワーカープロセスを開始しています "bdr（6029905891437956874,1,16384、）：vm12：apply"
LOG：論理デコードで、0 / 18A4290に一貫したポイントが見つかりました
詳細：xcnt == 0でxactsを実行する
LOG：エクスポートされた論理デコードスナップショット：xidが0の「0000071B-1」
ログ：スロットbdr_16384_6029905879776466735_1_16384__の論理デコードの開始
詳細：0 / 18A42C8の後にコミットするストリーミングトランザクション、0 / 18A4290からWALを読み取る
LOG：論理デコードで、0 / 18A4290に一貫したポイントが見つかりました
詳細：xcnt == 0でxactsを実行する
ログ内のすべてが正常であり、エラーメッセージはありません（もしそうなら、構成を確認するか、開発者の罪）））。 これでセットアップと起動が完了しました。 これで、両方のデータベースにテーブルを作成して、作業を確認できます。
さらにいくつかのポイント。 ダウンストリームウィザードをオフにして、レプリケーションを一時的に停止します。 ただし、レプリカを停止すると、上流のマスターがWALログを蓄積し続けることに注意してください。これにより、制御されていないディスク容量が消費される可能性があります。 したがって、レプリカを長時間オフにしないことを強くお勧めします。
レプリカの削除は、ダウンストリームサーバーのBDR構成を削除してからダウンストリームウィザードを再起動することで永久に行われます。 次に、pg_drop_replication_slot（ 'slotname'）関数を使用して、アップストリームウィザードの対応するレプリケーションスロットを削除する必要があります。 利用可能なスロットは、pg_get_replication_slots（）関数を使用して表示できます。
結論として、私の印象をお話しします...もちろん、BDRの運用についていくつか質問がありますが、その答えはおそらく実験的に決定する必要があります。 しかし、この段階ですでにこの新しいツールが気に入っています。簡単かつ迅速に設定できます。さらに、公式に9.5でのみ表示されるという事実にも関わらず、すでに機能しています（これは約1年後です）。 したがって、このリリースでは、信頼性の高いフォールトトレラントな構成を作成できるツールが追加されますが、これは素晴らしいことです。 リリースからリリースへのPostgreSQLは、どんどん良くなっています。
実際にはそれだけです。 ご清聴ありがとうございました。
読むべきPSリンク：
BDRユーザーガイド
論理ログストリーミングレプリケーション
PostgreSQL WAL Shipping and Streaming Replication