ストリーミングレプリケーション - ポストグル

私はセットアップストリーミングレプリケーションを持っています。マスターサーバーとセカンダリサーバー。アーカイブを有効にしました。また、postgresログファイルに私は以下のエラーが表示されます。ストリーミングレプリケーション - ポストグル

< 2017-12-05 03:08:45.374 UTC > WARNING: archive_mode enabled, yet archive_command is not set 
< 2017-12-05 03:08:46.668 UTC > ERROR: requested WAL segment 0000000100000000000000E3 has already been removed 
< 2017-12-05 03:08:51.675 UTC > ERROR: requested WAL segment 0000000100000000000000E3 has already been removed 
< 2017-12-05 03:08:56.682 UTC > ERROR: requested WAL segment 0000000100000000000000E3 has already been removed

ストリーミングレプリケーションにはarchive_mode = onを有効にする必要がありますか？上記のエラーを避けるにはどうすればいいですか？

max_wal_senders = 3 
wal_keep_segements = 32

出典

2017-12-05 varun7447

マスターで 'wal_keep_segements'を増やすことから始めます –

すでにwal_keep_segmentsを32に設定しました – varun7447

少なくとも1GB（〜60ウォール）に増やすことになりました。上記のエラーが表示されたら、スレーブを再構築するためにジャイブしてください。または、 'wal_keep_segments'を増やす代わりにarchive_commandを有効にしますが、あなたの状況では、とにかくスレーブを再構築する必要があります –

https://www.postgresql.org/docs/current/static/warm-standby.html

ファイルベースの連続アーカイブせずにストリーミングレプリケーションを使用する場合スタンバイがそれらを受け取った前に、サーバが古いWALセグメントをリサイクルすることがあります。このような場合は、スタンバイをから再初期化してにする必要があります。 wal_keep_segmentsを、WALセグメントが早すぎてリサイクルされないようにするか、またはスタンバイの複製スロットを設定することによって、確実に大きな値に設定してください。スタンバイからアクセス可能なWALアーカイブを設定した場合、スタンバイは個のセグメントを保持している限り、常にアーカイブを使用して追いつくことができるので、これらのソリューションは必須ではありません。

強調マイン。

wal_keep_segmentsを十分に大きくして（ブロックの変更量で十分です）、archive_commandを設定し、マスターから削除されたウォールをスレーブに利用可能にするようにストレージを設定します。 ...

出典

2017-12-05 08:23:11

複製スロットをソリューションとして追加し、wal_keep_segmentsより信頼性の高いスロットを追加するとよいでしょう。 –

ファイルベースのアーカイブを使用しています。 recovery.confファイルにはrestore_commandがあります。しかし、しばらくすると、WALはアーカイブディレクトリにログを記録し、スペースの問題を引き起こします。ファイルベースのアーカイブが推奨されているか、複製スロットですか？レプリケーションスロットを使用すると、WALログのアーカイブについて心配する必要はありません。 recovery.confファイルのarchive_cleanup_commandを使用して古いWALログをクリーンアップすることはできますか？ – varun7447

@Laurenz私がレプリケーションスロットを使用する場合、スペースの問題を避けることができますが、このアプローチでパフォーマンスに何か影響がありますか？レプリケーションスロット（ログ配布）は、非同期レプリケーションを使用します。障害発生時のデータ損失はどうですか？ – varun7447

ストリーミングレプリケーション - ポストグル

答えて

関連する問題