苦しみの過程で、彼は大量の記事をシャベルで掘り、マニュアルに詳細な解説を書くことにしました。 さらに、ロシア語でマルチマスターを構成することに関する情報はほとんどなく、それはどういうわけか断片的です。
少し紹介します。 ブカルドが機能するには、次のことを行う必要があります。
1）どのサーバーにどの参加データベースが存在するかを彼に伝えます。
2）レプリケーションに関係するテーブルを彼に伝えます。
注意：開発者がアプリケーションに新しいテーブルを追加する場合、これについてbucardoに通知する必要があります。 既存のテーブルのスキーマを変更する場合も同様です。3）テーブルのどのグループが存在し、どのテーブルがどのグループに該当するかを彼に伝えます。 異なるサーバー間で異なるテーブルを複製する必要がある場合、グループが必要です。 グループを個別に指定するよりも、グループで作業する方が便利です（Nagiosのグループに非常に似ています）。
4）どのデータベースグループが存在するかを彼に伝えます。 目標は表の場合と同じです。
インストールに移りましょう。 Debian 7のオプション。パッケージpostgresql-9.1およびpostgresql-client-9.1が既にインストールされていることが理解されます。
事前準備
サーバーは
node1および
node2と呼ばれ
ます 。 また、参加しているすべてのPostreSQLサーバーが外部インターフェイスでリッスンしていることを確認する必要があります。
各サーバーにBucardoパッケージとPostgreSQLのPL / Perlサポートをインストールします。
各サーバーでアクティブ化します。
パッケージメンテナは、何らかの理由でPIDの下にディレクトリを作成することを推測しなかったため、各サーバー上に自分で作成します。
TCPソケットを介して各サーバーのDBMSに接続できることを確認します。
パスワードを覚えていない場合、最も簡単な手順は
こちらです。
PGが特定のユーザーアドレスからのリクエストを受け入れたくない場合、/ etc / postgresql / 9.1 / main / pg_hba.confを設定します
次は、データベースの初期化です。 postgresによって作成されますが、bucardoによって埋められるため、接続の問題が発生する可能性があります。
それを避けるために、事前に/etc/postgresql/9.1/main/pg_hba.confにその行を追加します。 また、すでに作業中のBucardoは、クラスターノードだけでなく、ペアノードも参照します。 したがって、私たちもそれを忘れません。 クラスタ内にさらにサーバーがある場合は、それらについて忘れないでください。 各サーバーで：
host all bucardo 127.0.0.1/32 trust host all bucardo SECOND.NODE.IP.ADDRESS/32 password
その後、DBMSを再起動します。
ブカルドをインストールする
Debianの最近のバージョンではbucardo_ctlユーティリティはbucardoに置き換えられているため、使用します。
データベースを初期化します。
ダイアログは次のようになります。
初期化プロセスで、データベースはファイル/usr/share/bucardo/bucardo.schemaから作成されたため、以前のバージョンのマニュアルで説明されているように、データベースを手で埋める必要はありません。
Bucardoがインストールされ、実行できます：
レプリケーション構成
複製を設定する前に、複製するテストベースを作成します。
各サーバーで：
セキュリティに関する別の重要なポイント 。 複製されたデータベースを構成に追加した後、Bucardoはユーザーパスワードをデータベースに入力します。 また、インストール中に要求しなかったため、postgresユーザーとまったく同じになりました。 言い換えれば、スーパーユーザーからのパスワードはbucardoデータベースに平文で保存されますが、これはやや危険です。
したがって、私たちは彼に別のパスワードを作成します。 各サーバーで：
次に、複製するデータベースへの接続方法に関する情報をBucardoに提供します。 私は高負荷状態のUnixソケット（会話の別のトピック）のファンではないため、ローカルの場合でも、TCPソケットを示します。
注意：node1サーバーでこれを行います。 一般に、さらに、両方で何を行う必要があるかが明確になるまで、node1のみを使用します。
node2サーバーからローカル（mydb_node1）とそのリモートコピー（mydb_node2）を追加します。
ここに：
mydb_nodeX-ベースの内部指定。 この名前は、ブカルドがベースとの内部作業で使用します。
dbname = mydbは、mydb_nodeXによって参照されるPostgreSQLの実際のデータベース名です。
dbuser = bucardo-このデータベースを操作するためにBucardoがDBMSに接続するユーザー。
次のような結果が表示されます。
これらの設定は、上記のパスワードが置かれているbucardoデータベースのdbテーブルから取得されます。
次に、それらの間で複製するテーブルを追加する必要があります。 ほとんどの場合、ユーザーはデータベース全体を複製するため、すべてを一度に追加します（テーブルのグループ（群）が自動的に作成されます）。 開発者が新しいテーブルを思いついたら、後でそれをグループに追加するだけで、すべての設定はグループ全体に関係するため、すべてうまくいきます。
ここに：
--herd = mydb_herd-テーブルのグループの名前。これにより、後で個別にではなく全体に対して同期を設定できます。
そしてすぐにそれを見ることができます：
また、グループも表示されます。
シーケンスについても同じことが言えます。 この例ではそうではありませんが、突然誰かが使用します。 複雑にならないように、彼らのために独自のグループを作成しません。 テーブルが一方向に複製され、シーケンスが別の方向に複製される可能性は非常に小さいです。 したがって、テーブルとシーケンス用に1つのグループがあります。
次のタスクは、レプリケーショングループを作成することです。 このグループでは、どのベースがソースになり、どのベースがデータの受信者になるかを説明します。 最初に、空の状態でグループ自体を作成します。
両方のサーバーをグループに追加し、誰がどの役割を果たすかを示します。
これが、マスター/スレーブ構成がmaster-masterと異なる唯一のポイントです。
最初は、ソースがソースであり、ターゲットが受信者であると考えるかもしれません。 実際、これは完全に真実ではありません。 ソースはソースと受信者の両方として機能する人であり、ターゲットは受信者のみです。
つまり、マスタースレーブがある場合は、1つのソースと2番目のターゲットを指定します。 そして、master-masterがある場合、両方がソースになり、target'ovはまったくありません。
MASTER-> SLAVEのオプション：
MASTER <-> MASTERのオプション：
以上です！ 基礎となるものを書きました。 どのテーブルがあるかが書かれています。 どのグループの誰が書かれています。 最後の仕上げを言うことは残っています-テーブルのどのグループがどのグループのベース間で「実行」されるかを言うことです。 つまり、「同期」を作成します。
取得したものを確認できます。
設定を変更したら、必ずBucardoを再起動してください。
=========
チェック：最初のノードでnode1を実行：
そして、2番目のnode2で次を確認します。
マルチマスターを作成した人は、反対方向でチェックする必要があります。 node2で作成し、node1でテストします。
=========
ほとんどの人が持っている質問：
1）Bucardoがオフになっている間、またはネットワークが利用できないときにソースベースのテーブルが変更された場合、ターゲットベースのテーブルはどうなりますか？
回答：すべてOK。 起動時またはネットワークが表示されると、Bucardoはデータをターゲットサーバーに転送します。 そのため、ターゲットサーバーは必要に応じて破損する可能性があります。 唯一の要件は、最初のものと同じデータスキーマ（テーブル構造）を持つ必要があることです。
__
2）ベースが大きい場合（数十から数百ギガバイト）、ブカルドは「途切れ」、最後まで同期しません。 になる方法
回答：同期を非アクティブにします。 ただし、Bucardoは、要求を記録するためのソースデータベースに対して有効にする必要があります。
bucardo update sync mydb_sync status = inactive（すべてのノードのマルチマスター用）
次に、手でpg_dump / pg_restoreを実行し、同期をアクティブモードに戻します（マルチマスターの場合、最初にダンプが開始された後に新しい要求が送信されたモードで）。