既存の Postgresql 9.3 2 ノード ストリーミング レプリケーション クラスタに repmgr を追加する準備をしています。
以前は、主なビジネスに影響を与える深刻な問題がありました。問題は、マスターとスレーブ間の遅延でした。次のように構成を調整することで解決しました。
マスター postgresql 構成:
archive_timeout = 60
synchronous_commit = on
synchronous_standby_names = 'slave1'
archive_command = 'test ! -f /walshare/%f && cp %p /walshare/%f'
スレーブの recovery.conf:
standby_mode = 'on'
primary_conninfo = 'host=master port=5432 user=repuser password=xxx application_name=slave1'
restore_command = 'cp /walshare/%f "%p"'
slave1 は master から NFS 経由で /walshare をマウントします。
postgres@slave1:~$ mount -t nfs
master:/walshare on /walshare type nfs (rw,noatime,nolock,bg,nfsvers=4,intr,tcp,actimeo=1800,addr=xx.xx.xx.xx,clientaddr=xx.xx.xx.xx)
同期コミットを有効にすることで、マスターとスレーブ間の遅延の問題を最終的に解決しました。
いいえ、管理タスクとフェイルオーバーを容易にするために、repmgr によって管理されるように現在のクラスターを再構成したいと考えています。
新しい VM (PG-9.4 を使用) を作成し、データベースを古いクラスターから新しいクラスターに移行する予定です。
pg_xlog のディスク容量の問題を回避するために、pg_xlog ディレクトリを PGDATA 論理ボリュームと同じボリューム グループの別の論理ボリュームに配置することにしました。
/dev/mapper/datavg-pgsqllv mounted on /var/lib/pgsql
/dev/mapper/datavg-pgxloglv mounted on /var/lib/pgsql/9.4/data/pg_xlog
私の質問は次のとおりです。
- そのrepmgrは同期コミットをネイティブにアクティブにしますか、それともマスターのpostgresql.confに手動で追加する必要がありますか?
- 同期コミットをオンにすると、スレーブが応答しない場合にマスターが失敗します。repmgr はどのように状況を管理しますか?
- repmgr が新しいスレーブ (クローン マスター) を作成するとき、/var/lib/pgsql/9.4/data/pg_xlog を削除して、新しいスレーブを再作成しますか?
- pgsqllv と pgxloglv を同じボリューム グループに配置しても、I/O パフォーマンスに影響はありませんか? pg_xlog には専用ディスクを使用する必要がありますか?
- repmgr の公式ドキュメント、wal_keep_segments = 5000 に従い、pg_xlog で 80 GB が必要です。80 GB は固定です。または、pg_xlog のディスク領域の増加を管理するために、100 GB 以上の論理ボリュームを作成する必要がありますか?
あなたの助けに感謝します、