ホットスタンバイPostgreSQLデータベースを使用する場合、特に挿入トランザクションで数千万のデータを挿入する必要がある場合（通常、t select * from t;への挿入を継続するのが一般的なアプローチです）、バックグラウンドログエラーは次のように報告されます。
csv形式のログ：
2013-07-01 13：25：29.430 CST ,,, 27738、、51d112c8.6c5a、1、、2013-07-01 13:25:28 CST ,, 0、LOG、00000、 "ストリーミングレプリケーションが正常にプライマリに接続されました",,,,,,,," libpqrcv_connect、libpqwalreceiver.c：171 "、" "
2013-07-01 13：25：29.430 CST ,,, 27738、、51d112c8.6c5a、2、、2013-07-01 13:25:28 CST ,, 0、FATAL、XX000、 "WALストリームからデータを受信できませんでした：FATAL：要求されたWALセグメント0000000800002A0000000000はすでに削除されています
" ,,,,,,,, "libpqrcv_receive、libpqwalreceiver.c：389 「、」
備考：エラー情報によれば、メインライブラリで大量のxlogが生成されていることは簡単にわかります。また、postgreSQLはトランザクションを実行しているため、送信時にスタンバイデータベースに送信されます。トランザクションの実行には時間がかかりすぎ、チェックポイントのデフォルトの間隔を超えているため、一部のxlogはスタンバイデータベースに送信されていませんが、削除されています。この問題を解決するために、一般的に利用可能なソリューションは次のとおりです。
まず、
wal_keep_segments の値を調整します。GUCパラメータwal_keep_segmentsを2000などの大きな値に設定します。各セグメントのデフォルト値は16MBで、これは32000MBに相当します。つまり、キャッシュスペースとして約30GBのスペースです。
ただし、この方法では根本的に問題を解決することはできません。結局、本番環境またはTPCCテストでは、トランザクションが数十億のレコードを挿入する必要がある場合でも、問題が発生する可能性があります。
2.アーカイブの有効化アーカイブ
とは、スタンバイデータベースに送信されていないxlogを特定のディレクトリにバックアップし、データベースの再起動時にそれらをスタンバイデータベースに復元することを意味します。
GUCパラメータ設定の例は次のとおりです。
主库的postgresql.conf文件中：
wal_level = hot_standby
archive_mode = on
archive_command = 'rsync -zaq％p postgres @ pg-slave：/ var / lib / pgsql / wal_restore /％f && test！-f / var / lib / pgsql / backup / wal_archive /％f && cp％p / var / lib / pgsql / backup / wal_archive / '
archive_timeout = 300
max_wal_senders = 5
wal_keep_segments = 0＃設定した理由がわからないこの？
备库的postgresql.conf文件中：
wal_level = hot_standby
archive_mode = on
archive_command = 'test！-f / var / lib / pgsql / backup / wal_archive /％f && cp -i％p / var / lib / pgsql / backup / wal_archive /％f </ dev / null '
hot_standby = on
wal_keep_segments = 1
备库的recovery.conf文件中：
standby_mode = 'on'
primary_conninfo = 'host = pg-master port = 5432 user = replicator'
restore_command = 'cp / var / lib / psql / wal_restore /％f％p'
archive_cleanup_command = ' pg_archivecleanup / var / lib / pgsql / wal_restore /％r '
3.レプリケーションスロットを有効にします（pg9.4以降でのみ使用可能）。
この方法は基本的な解決策であり、xlogが失われることはありません。つまり、xlogがコピーされる前は削除されません。
アクティベーション方法：
（1）postgresql.confに追加：
max_replication_slots = 2000
（2）スタンバイデータベースにコピーする前に、メインライブラリがスロットを作成する必要があります。
postgres =＃SELECT * FROM pg_create_physical_replication_slot（ 'node_a_slot'）;
スロット名| xlog_position
------------- + ---------------
node_a_slot |
postgres =＃SELECT * FROM pg_replication_slots;
slot_name | slot_type | datoid | database | active | xmin | restart_lsn
------------- + ----------- + --- ----- + ---------- + -------- + ------ + -------------
node_a_slot | physical | | | f | |
（1行）
（3）スタンバイデータベースのrecovery.confファイルに行を追加します。
standby_mode = 'on'
primary_conninfo = 'host = 192.168.4.225 port = 19000 user = wslu password = xxxx'
primary_slot_name = 'node_a_slot'
スタンバイデータベースの構成方法については、以下を参照してください。
http://blog.csdn.net/prettyshuang/article/details/50898363#t10
参照：
https://www.postgresql.org/docs/9.4/static/runtime-config-replication.html
https://www.postgresql.org/docs/9.4/static/warm-standby.html#CASCADING-REPLICATION
http://blog.2ndquadrant.com/postgresql-9-4-slots/
http://grokbase.com/t/postgresql/pgsql-general/13654jchy3/trouble-with-replication
http://stackoverflow.com/questions/28201475/how-do-i-fix-a-postgresql-9-3-slave-that-cannot-keep-up-with-the-master
