ここにシナリオがあります:
CentOS 6.2を実行しているマシンが2つあります-machine0とmachine1
どちらにもPostgreSQL 9.1がインストールされています。
それらの1つはマスターシステムとしてアクティブであり、非同期ストリーミングレプリケーションを介して他のマシンを通じて、スタンバイはマスターシステムからデータベースに変更をコピーする必要があります。
最初はmachine0がマスターでmachine1がスタンバイであると想定します。
マスター(machine0など)に障害が発生した場合(ここでの障害とは、postgresqlサーバーがクラッシュしたことを意味します)、スタンバイがマスターから引き継ぎ、新しいマスターになる必要があります。
machine1は、新しいマスターがすべてのデータベース操作を処理し、machine0のpostgresqlサーバーがオンラインに戻ると、スタンバイになり、machine1との接続を失った時点から同期を開始し、すべての変更をデータベースにコピーしてスタンバイモードのままにします。
Machine1に障害が発生すると、サイクル全体が繰り返されます。
スタンバイに障害が発生してオンラインに戻ると、マスターからの読み取りが開始され、データが同期されます。
PostgreSQLにはデフォルトでフェイルオーバーが備わっていないことを理解しているので、これを設定するために使用する必要があるツールについて混乱しています。
誰かが私が私がしようとしていることをする方法を説明するスレッド/ページに私をリンクできれば、私は本当に感謝します。
同期DBレプリケーションとフェイルオーバーに興味がある場合は、私が提案します。次の2つのツールの使用を検討できます。
DRBD(ディスク複製ブロックデバイス) は、2つの異なるサーバー上のディスク間でディスクレベルのレプリケーション(同期)を提供します。ディスクの変更はネットワークを介して複製されます。 192.168.x.xネットブロックを使用するNICには、eth2でクロスケーブルを使用するのが最適です。
ucarp は、2つの異なるサーバー間のDBVIP管理とフェイルオーバーを可能にします。
次のように組み合わせて使用できます。
2つの異なるサーバーでucarpをセットアップし、各ucarpインスタンスが仮想ルーターIDに沿って他のインスタンスと通信するようにします。
DBServer1は
/usr/local/sbin/ucarp -v 200 -p sometagname --interface=eth2 -a 10.1.2.70 -s 10.1.2.30 -b 3 -r 5 --upscript=/usr/local/sbin/vip-up.sh --downscript=/usr/local/sbin/vip-down.sh --neutral -z -B
DBServer2は
/usr/local/sbin/ucarp -v 200 -p sometagname --interface=eth2 -a 10.1.2.70 -s 10.1.2.40 -b 4 -r 5 --upscript=/usr/local/sbin/vip-up.sh --downscript=/usr/local/sbin/vip-down.sh --neutral -z -B
-b(ブロードキャスト)が1つのサーバーで3で、他のサーバーで4である理由は何ですか?両方のサーバーが再起動された場合、-bが最も小さいサーバーがucarpを最初に表示します。 -rに関しては、それはデッドレシオです。したがって、DBServer1は15秒(3X5)で起動し、DBServer2は20秒(4X5)で起動します。
DBServer1がクラッシュしたとしましょう。 DBServer2のucarpは、DBServer1のucarpのハンドシェイクを20秒間チェックします。何も検出されない場合、DBServer2のvip-up.shスクリプトがDBVIPを制御します。
これはすべて、フェイルオーバーとDBVIP管理のためだけのものです。 PostgreSQLデータベースはどうですか?驚いたことに、PostgreSQLは一度に1つのサーバーでのみ実行されます。 DBVIPを持っている人は誰でも、DRBDをプライマリ状態にする必要があります。これはvip-upスクリプトに結びつきます。それをどのようにスクリプト化しますか?
/usr/local/sbin/vip-down.shスクリプト(概念)は次のとおりです
#! /bin/sh
exec 2> /dev/null
/sbin/drbdadm disconnect drbd0
/sbin/drbdadm primary drbd0 &&
/bin/mount postgres-data-folder /mnt/drbd0
/sbin/ip addr add 10.1.2.70/24 dev eth2
/sbin/service postgres start &&
/usr/local/sbin/vipmon.sh &
touch /tmp/vip-up
/usr/local/sbin/vip-down.shスクリプト(概念)は次のとおりです
#! /bin/sh
exec 2> /dev/null
/sbin/service postgres stop
/bin/umount -l /dev/drbd0
/sbin/drbdadm secondary drbd0
/sbin/ip addr del 10.1.2.70/24 dev eth2
/bin/rm /tmp/vip-up
/usr/bin/killall -9 ucarp
/usr/local/sbin/vip-down.sh
kill `ps auxww | grep vipmon | awk '{print $2}'`
必要なのは、pg_hba.confをセットアップして、すべてのユーザーが10.1.2.70を経由するようにすることです。
基本的に、vip-upはこのシーケンスを実行します
反対に、vip-downはこのシーケンスを実行します
Vipmon.shはどうですか?無限ループでpostgresの状態(実行中)をチェックし、DRBDデバイスをチェックするようにスクリプトを作成できます(まだ投稿データフォルダーに書き込むことができます)
このセットアップでは、DRBDプライマリにpostgresがあり、他のDBServer(DRBDセカンダリ)にpostgresデータフォルダのディスクレベルのコピーがあります。 postgresがDRBDセカンダリで実行されていません。
フェイルオーバーが発生したときは、ucarpがpostgresデータをマウントしてpostgresを起動し、vipmonスクリプトをアクティブ化するのが安全であることが検出されるだけの時間が必要です。
このセットアップの優れている点は、フェイルオーバーが発生した場合、DRBDプライマリになるDBサーバーに、障害が発生したサーバーの100%ディスクレベルのコピーが存在することです。したがって、postgresを開始すると、一貫した状態でレベルが上がるはずです。トランザクションログ(pg_xlog内)は完全な状態である必要があります(フェイルオーバーによる断続性が少ない)
これらの提案がお役に立てば幸いです。私はMySQL DBAですが、雇用主のWebホスティング会社でMySQLとDRBDを定期的に使用しています。上記の方法でMySQL/DRBDをインストールしました。 PostgreSQL/DRBDを使用しているクライアントに対してこれを1回行いました。それは素晴らしい働きをします。それはオープンソースです。あなたはDRBDとucarpを学ぶためにデューデリジェンスを実行する必要があるだけです。これには、フェイルオーバー後のDRBDの再接続、両方のDBサーバーがプライマリになるスプリットブレインシナリオの処理などが含まれます。