web-dev-qa-db-ja.com

Postgresqlの1つのマスター、複数のスレーブのフェイルオーバー

私の問題は以下のトピックで尋ねられたものと同じです

ストリーミングレプリケーションフェイルオーバー-2番目のスレーブを新しいマスターにポイントする方法

現在、私はPostgresql 9.5で作業しています。マスターが1つとスレーブサーバーが2つあります。マスターがクラッシュし、スレーブの1つが新しいマスターとして割り当てられた後、完全なベースバックアップなしで他のスレーブのマスターを変更します。

回答に書かれている手順を試しましたが、うまくいかないようです。この問題の解決方法を誰かに教えてもらえますか？

役立つ場合に備えて、設定の詳細をいくつか書いています。

standby_mode = on
primary_conninfo = 'Host=10.10.10.160 port=5432 user=repuser password=*****'
restore_command = 'cp /archivedir/%f %p'
trigger_file = '/tmp/postgresql.trigger.5432'

10.10.10.160は、新しいマスターサーバーのIPアドレスです。

また/archivedirフォルダーはマスターサーバーとスレーブサーバーの両方で空のようですが、これは正常ですか？以下の設定はpostgresql.conf：

wal_level = hot_standby 
archive_mode = on
archive_command = 'test ! -f /archivedir/%f && cp %p /archivedir/%f'
max_wal_senders = 3
hot_standby = on
postgresqlreplicationpostgresql-9.5
2
zibidyum

Dezsoの助けを借りてなんとか解決しました。

これにはカスケードレプリケーションを使用しました。現在のアーキテクチャはM-> S1-> S2のようなものです。

マスター：10.10.10.146、S1：10.10.10.130、s2：10：10：10：160、

まず、以下のコマンドを使用して、3つのシステムすべてでrepuserを作成しました。

Sudo -u postgres createuser -U postgres repuser -P -c 5 --replication

パスワードを割り当て、好きなものを入力するように求められ、repuserが作成されます。このユーザーをレプリケーション関連の操作に使用します。

マスターサーバーの現在の構成は次のとおりです。

postgresql.conf

listen_addresses = 'localhost, 10,10,10,146'
wal_level = hot_standby
archive_mode = on
archive_command = 'test ! -f /here i wrote full directory starting from root/%f && cp %p /here i wrote full directory starting from root/%f'
max_wal_senders = 3

pg_hba.conf

# Allow replication connections
Host     replication     repuser         10.10.10.130/32        md5
Host     replication     repuser         10.10.10.160/32        md5
# IPv4 local connections:
Host    all             all             127.0.0.1/32            md5
Host    all             all             0.0.0.0/0               md5
# IPv6 local connections:
Host    all             all             ::1/128                 md5

この構成の後、マスターサーバーを再起動します。

次に、マスターからS1への完全バックアップを取得する必要があります。まず、S1でpostgresqlサービスを停止します。次に、データディレクトリを削除します（ディレクトリは、私のシステムではvar/lib/pgsql/9.5/dataです）。削除後、フルバックアップコマンドを実行します。

Sudo -u postgres pg_basebackup -h 10.10.10.146 -D /var/lib/pgsql/9.5/data -U repuser -v -P --xlog-method=stream

これにより、データフォルダーがS1サーバーにコピーされます。 S1でpostgresql.confを開き、以下の変更を行います

listen_addresses = 'localhost, 10,10,10,130'
wal_level = hot_standby
archive_mode = on
archive_command = 'test ! -f /full directory starting from root/%f && cp %p /full directory starting from root/%f'
max_wal_senders = 3
hot standby=on

Pg_hba.confを開き、以下の変更を行います。

# Allow replication connections
Host     replication     repuser         10.10.10.160/32        md5
# IPv4 local connections:
Host    all             all             127.0.0.1/32            md5
Host    all             all             0.0.0.0/0               md5
# IPv6 local connections:
Host    all             all             ::1/128                 md5

最後に、dataフォルダの下にrecovery.confファイルを作成します。 recovery.confは次のようになります。

standby_mode=on
primary_conninfo='Host=10.10.10.146 port=5432 user=repuser password=password_of_repuser'
trigger_file='/full directory starting from root/any_folder_name'

たとえば、trigger_file = '/tmp/trigger_failover'をrecovery.confファイルに追加し、/ tmpディレクトリの下にtrigger_failoverという名前のフォルダーを作成します。S1はフェイルオーバープロセスを開始し、マスターサーバーとして機能し始めます。

上記の設定後、S1サーバーを起動すると、MとS1がマスターおよびスレーブとして機能するようになります。次に、S2サーバーを構成する必要があります。手順は、S1の構成とほとんど同じです。

まず、S2でpostgresqlサービスを停止します。次に、S1で行ったようにデータディレクトリを削除します。私の場合、S2はS1と同じフォルダアーキテクチャを持っているため、データフォルダも/var/lib/pgsql/9.5/dataディレクトリにあります。今度は以下のコマンドを実行して、S1サーバーから完全バックアップを取得します。

Sudo -u postgres pg_basebackup -h 10.10.10.30 -D /var/lib/pgsql/9.5/data -U repuser -v -P --xlog-method=stream

いいえ、S2で構成ファイルを変更します。 postgresql.confで以下の変更を行います。

listen_addresses = 'localhost, 10,10,10,160'
wal_level = hot_standby
archive_mode = on
archive_command = 'test ! -f /full directory starting from root/%f && cp %p /full directory starting from root/%f'
max_wal_senders = 3
hot standby=on

そして、recovery.confで以下の変更を行います。

standby_mode=on
primary_conninfo='Host=10.10.10.160 port=5432 user=repuser password=password_of_repuser'
recovery_target_timeline='latest'

これで完了です。次に、S2でpostgresqlサービスを開始し、M、S1、およびS2でレプリケーションメカニズムが機能することを確認します。

このアーキテクチャにより：

  • mがダウンした場合は、S1をトリガーして新しいマスターとして機能させることができ、S1はS2とのレプリケーションを持ちます。

  • S1がダウンした場合、S2をMにポイントするだけで簡単に変更できます
    S2のrecovery.confファイルのprimary_conninfoコマンドを使用すると、
    MおよびS2との複製。

  • そして最後に、S2がダウンしても、MはS1との複製を保持します。

0
zibidyum