Postgresql 9.0でのレプリケーション

良い一日。 PostgreSQL 9のリリースから一定の時間が経過したことを考慮して、新しい機能の1つであるネイティブレプリケーションを試してみることにしました。 ご存知のように、新しいメカニズムはマスターからスレーブへのXLOGの転送に基づいています。 脂肪の利点の1つは、ALTERの通常の処理です。 言い換えれば、9番目のバージョンの管理者はSlonyなしで実行できます。



インストール済みのパッケージ（および、そうでない場合は、Debian / Ubuntu用にここから入手できます ）、testdbデータベースが作成されていると想定しています。 /var/lib/postgresql/9.0/にpostgresデータベースがあると仮定してプロセスを説明します。そうでない場合は、正しいパスを使用してください。



それでは、行きましょう：

1. listen && pg_hba.confを設定します

マスターのIPが192.168.0.1で、スレーブが192.168.0.2であるとします。 次に、postgresql.confのlisten行は次のようになります。

listen_addresses = '192.168.0.1'







そして、ウィザードのpg_hba.confには次のようなエントリがあります。

host replication postgres 192.168.0.2/32 trust







2.マスターに複製に必要なすべてを含める

# , . hot_standby archive ().

wal_level = hot_standby



#

max_wal_senders = 2



# ? - , .

wal_keep_segments = 32



# ( , , ). , . , .

archive_mode = on

archive_command = 'cp %p /var/lib/postgresql/9.0/main/archive/%f'







ここで、ウィザードを再起動する必要があります。



3.データベースをマスターからスレーブに送信します。

ネットワーク経由でデータを送信できるものが必要です。 もちろんrsyncを使用しましたが、もちろん他のツールも使用できます。 スレーブでpostgresqlを終了し、ウィザードで次の操作を実行します。

$ psql -c "SELECT pg_start_backup('label', true)"

$ rsync -a /var/lib/postgresql/9.0/main/ slave:/var/lib/postgresql/9.0/main/ --exclude postmaster.pid

$ psql -c "SELECT pg_stop_backup()"









4.スレーブでhot_standbyをオンにします

postgresql.confに追加します。

hot_standby = on







5.スレーブでレプリケーション構成を作成します。

これを行うには、/ var / lib / postgresql / 9.0 / mainにあるファイルrecovery.conf（作成する必要があります）で、次のように記述します。

standby_mode = 'on'

primary_conninfo = 'host=192.168.0.1 port=5432 user=postgres'

trigger_file = '/var/lib/postgresql/9.0/main/trigger'

restore_command = 'cp /var/lib/postgresql/9.0/main/archive/%f "%p"'







別に、trigger_fileについて説明します。 デフォルトではそうではありません。 fakapの場合、（このファイルを作成することにより）レプリケーションプロセスを停止し、スレーブを書き込み可能にするために必要です。



6.完了！

スレーブを実行します。 チームがスレーブ上にある場合

ps aux | grep receiver





のようなものを表示

postgres 1953 0.0 0.0 101980 4156 ? Ss 19:19 0:00 postgres: wal receiver process streaming 2/B40001D0





（読んでください-wal受信機の説明を含むpostgresプロセスがあります）-私たちはすべてが機能すると仮定することができます。



7.モニタリング

さて、悲しいことについて少し-象とは異なり、ネイティブ複製は人間が読める形式で遅延を表示する方法を知りません。

レプリケーションを監視する方法の1つは、マスター/スレーブ上のジャーナル位置の違いを考慮することです。

psql -c "SELECT pg_current_xlog_location()" -h192.168.0.1

--------------------------

0/2000000

(1 row)



psql -c "select pg_last_xlog_replay_location()" -h192.168.0.2

pg_last_xlog_replay_location

------------------------------

0/2000000

(1 row)





取得した結果から、スラッシュを切り取ってから、HEXから通常の数値に変換してから、結果を抽象値にします。結果の重大なしきい値は、ケースごとに異なります。

より正確な方法で、タイムスタンプタイプのフィールドを1つ持つプレートを作成し、1つのレコードを保持し、n秒（たとえば30）ごとにその値を現在の時刻に更新します。 次に、スレーブ上の同じプレートの内容をウィザードのレコードから差し引くと、遅延時間が得られます。



8.ひどいことが起こった場合

原則として、複製は2つの場合に必要です。負荷分散と、マスターに何かが起こった場合です。 マスターが拒否した場合、アクションは次のようになります。

a）スレーブ上でトリガーファイルを作成します（5項で説明）。 スレーブは記録のために開き、レプリケーションを停止します-クライアントを転送できます。

b）次に、マスターにサービスを提供するマシンが操作に戻ると、プロセスを逆にします- 元のマスターからレプリカを作成します- マスターで 5番目の項目を実行します。 復旧したら、スレーブのトリガーファイルを削除します。すべて正常に戻ります。



PSこのテキストは、 このWikiページの無料翻訳です。