web-dev-qa-db-ja.com

事後分析：PostgreSQLレプリケーションが失敗しました

PostgreSQL 9.4.9の本番サーバーがスレーブインスタンスに複製されていましたが、今日、インスタンスが同期していないことがわかりました。

明らかなアクションは、スレーブを再作成することです セットアップメトリック とレプリケーションアクティビティの適切なアラーム。これにより、マスターノードとスレーブノード間の同期ステータスを効果的に監視できます。

しかし、同期が失敗したので、最初に問題を診断し、根本的な原因を特定したいと思います。これは 2回目 約6か月で発生するためです。

質問：レプリケーションプロセスで失敗したものを診断して、今回はより良い方法で実行できるようにする方法を教えてください。

バージョンの詳細：

PostgreSQL 9.4.9 on x86_64-unknown-linux-gnu, compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit

スレーブノードから、/var/log/postgresql/postgresql-9.4-main.log 私は見えます：

2017-07-18 19:43:55 UTC [12816-1] LOG:  started streaming WAL from primary at 125D/68000000 on timeline 1
2017-07-18 19:43:55 UTC [12816-2] FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000125D00000068 has already been removed

2017-07-18 19:44:00 UTC [12817-1] LOG:  started streaming WAL from primary at 125D/68000000 on timeline 1
2017-07-18 19:44:00 UTC [12817-2] FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000125D00000068 has already been removed

2017-07-18 19:44:05 UTC [12821-1] LOG:  started streaming WAL from primary at 125D/68000000 on timeline 1
2017-07-18 19:44:05 UTC [12821-2] FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000125D00000068 has already been removed

2017-07-18 19:44:10 UTC [12825-1] LOG:  started streaming WAL from primary at 125D/68000000 on timeline 1
2017-07-18 19:44:10 UTC [12825-2] FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000125D00000068 has already been removed

2017-07-18 19:44:15 UTC [12826-1] LOG:  started streaming WAL from primary at 125D/68000000 on timeline 1
2017-07-18 19:44:15 UTC [12826-2] FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000125D00000068 has already been removed

新しい質問：実際の問題がどこに発生したかを後方から確認するにはどうすればよいですか？

主人 postgresql.conf： https://Pastebin.com/NJX5ku6m

スレーブpostgresql.conf： https://Pastebin.com/CUZcyazC

スレーブrecovery.conf：

standby_mode = on
primary_conninfo = 'Host=10.1.1.65 port=5432 user=replicador password=replicador'
postgresqlreplicationpostgresql-9.4data-synchronizationmaster-slave-replication
2
Gonzalo Vasquez

これに基づいて、マスターに十分なwal_keep_segmentsがなく、レプリケーションスロットを使用しておらず、hot_standby_feedbackがオフになっているか、マスターに十分な時間接続が切断されていたと思います必要なWALを削除します。

また、フォールバックとしてWALアーカイブ（マスターではarchive_command、レプリカではrestore_command）を使用していないと考えられます。

したがって、マスターが削除したトランザクションは、必要なスタンバイを記録します。

スタンバイを再作成する必要があります。次に、いずれか：

  • スタンバイを複製スロットを使用するように設定し、hot_standby_feedbackを有効にします。または

  • archive_commandとrestore_commandを有効にする

6
Craig Ringer

まず最初に、ログを見てください。警告、エラー、致命的、パニックメッセージが表示されます。

postgresql.confファイルでログの場所を確認できます。

logging_collector設定を探します。onの場合、log_directory設定で指定されたディレクトリにサーバーログが見つかります。

logging_collectorがoffに設定されている場合は、log_destination設定を確認してください。 syslogの場合、syslog設定を調べて、ログの場所を見つける必要があります。 stderrの場合、/proc/<PID>/fd/2の下に何かが見つかるかもしれません。ここで、<PID>は実行中のPostgreSQLサーバーのPIDです。

この page のドキュメントが役に立つかもしれません。

1
Arkhena