Clever Geek Handbook

PostgreSQL 8.xでのレプリケーション：Slonyでの作業の簡素化

まえがき



良い一日。 歴史的に、Postgresqlのボックスから8番目のブランチ（および安定版の9番目の明るい未来にはまだ到達していません）にはレプリケーションシステムがありませんでした。 したがって、これらの目的のために、外部ツールSlony1が作成されます。



仕組み

。

非常に簡単に動作します：slonデーモンはPostgresqlサーバーに接続し、トリガーにしがみつき、データベースの内容を変更するイベントが発生するのを待ちます。 slonikもあります-STDINの設定を使用する設定ユーティリティと、さまざまな目的のための他のいくつかの管理ユーティリティです。

レプリケーションの一部として、Postgresqlに関しては、次の用語が一般的に使用されます。



構成が正常に完了すると、Slonyは複製されるデータベースに_clusterスキーム（「cluster」は構成で指定されたクラスターの名前）とそのテーブルのいくつかを作成します。 テーブルの目的は明らかです。 ドキュメント 、まあ、またはpsqlを使用して。 したがって、セットアッププロセス中に突然問題が発生し、再起動後に「このノード/クラスター/テーブルが既にリストにあります」という形式のメッセージを受け取った場合、ドロップインスキームが役立ちます。

また、主キーを持つテーブルのみがレプリケーションの対象になることを知っておく必要があります。

私にとって象の主な不快な特徴は、データベース内のすべてのテーブルのレプリカを作成する方法がわからないことです。1つずつリストする必要があります。 データベースに50を超えるテーブルがある場合、設定の記述は非常に退屈なタスクになります。 これらの目的のために、以下に掲載するスクリプトを作成しました。

最も好奇心The盛な人は、おそらくそのようなマナを見て、この投稿は別のテイクだと信じているでしょう。 いいえ、そうではありません。 私が見たすべてのマナは、STDIN経由でslonikに設定を直接送ることを提案しました。 このアプローチでは、システムは動作しますが、（少なくともDebian / Ubuntuの場合）2つの問題があります：

  1. 初期化スクリプトは機能しません
  2. 補助象ユーティリティは機能しません。


正しいアプローチは、perlのような設定を/etc/slony1/slon_tools.confに保存することです（たとえば、ls /usr/share/doc/slony1-bin/examples/slon_tools.conf-sample.gzにあります）。 、および/ etc / default / slony1-このマシン上に存在し、initスクリプトによって起動されるノードの数。 私が言ったように-最初の設定はperlスクリプトであり、slon_startスクリプトに含まれています。 一般的に-この投稿では手動による設定は考慮されていません-例がどこにあるかを伝えるだけです。

準備。



すでにベースと設定済みのPostgresqlがあり、プライマリキーを持つテーブルがあり、セットアップを開始する準備ができていると仮定します。 Ubuntuの異なるバージョンですべてが行われることを事前に予約します。Debianでもほぼ同じですが、他のディストリビューションで何が起こるかわかりません。

したがって、postgresql-8.3-slony1およびslony1-binパッケージが必要です。 両方のパッケージに2番目のブランチがあることが望ましいです（より安定しています）。



サーバー構成



最初に、postgresql.confで、「listen_addresses」を含む行のコメントを解除し、localhostの代わりにlocalhostを、スレーブに向かっているインターフェイスのIPアドレスで設定する必要があります。 アドレスの代わりに「*」を入力することもできます-サーバーはすべてのインターフェイスで接続を待機します。

次に、pg_hba.conf（/ etc / postgresqlにもあります）に次の形式の行を追加する必要があります

host all all 192.168.1.0/24 md5





、192.168.0.0 / 24の代わりに、ネットワークまたはIPスレーブを指定する必要があります。 次に、スレーブで同じことを行い、ウィザードのIPを示します。

次に、マスターとスレーブでPostgresqlを再起動して、新しい設定を取得します。

また、両方のマシンでpgスーパーユーザーを作成する必要があります。

createuser -sP slony







スクリプト



投稿サイズを数回増加させないために、スクリプトをここに送信しました 。 私は事前に、コードの美しさに対する賞を請求しないと言います。それどころか、それは私の自由な時間に膝の上に書かれました。 別のことが重要です-それは動作します。 次に、彼が何をするかについてお話します。

通常の操作では、root`aまたはsudoから実行する必要があります（postgresユーザーでsuを使用し、/ etcへの書き込みとinitスクリプトが実行されるため） ）スレーブがrootからsshへのアクセスを許可するようにします（パスワードはすぐに退屈するため、キーを使用する方が適切です）。 libdbd-pg-perlパッケージも必要です。



現在のバージョンはコマンドラインからのパラメータを食べません（そうすべきですが）ので、起動後にスクリプトとダイアログを入力します。 そのため、アルゴリズムは段階的に機能します。



1.クラスターの名前とマスター/スレーブの詳細をユーザーにポーリングします。


間違えた場合-データベースへの接続に問題がある場合、スクリプトはデータを再入力するように求めます。 クラスターの名前は任意です。

2.データベースを選択するためのダイアログ。


ここではすべてが簡単です。 このスクリプトは、使用可能なデータベースについてサーバーをポーリングし、複製する必要があるデータベースを選択するように提案します。 ベースを選択（または選択解除）するには、その番号を入力する必要があります。 アスタリスクですべてを選択できます。 最後にEnterキーを押す必要があります。

3.テーブル/シーケンスの追加。


選択したデータベースのリストがあるため、スクリプトはそれらからテーブルのリストを収集します。 選択したデータベースにあるすべてのテーブルとシーケンスがリストに追加されます。

4.マスターからスレーブへの基本構造の転送


順次実行されるリモートcreatedb、createlang。 次に、ローカルのpg_dump -sを実行した後、sshを介して構造がスレーブに転送されます。

5.構成の直接生成とその転送。


すべての必要なデータがそこにあり、構成が生成され、rootである場合、/ etc / slony1（スレーブを含む）に配置され、/ etc / default / slony1が編集されます（どのノードを開始する必要があるかを示します）。

6.デーモンの起動


まあ、それがすべてです。 実行されたままです。 :)



PS

質問がある場合、または何かうまくいかない場合は、誰かに役立つことを願っています-気軽にコメントしてください。


More articles:


All Articles