it-swarm-ja.com

Postgresのレプリケーションの復元、タイムラインの競合

ストリーミングレプリケーション(マスター、スレーブ構成)を備えたpostgresデータベース(バージョン9.4)があります。マスターデータベースAとスレーブデータベースBを呼び出しましょう。

Aを実行しているサーバーに障害が発生し、スイッチオーバーを実行する必要がありました。そこで、Bを新しいマスターに昇格させました。今まではすべて良好で、正常に機能しています。

これで、壊れたサーバーを回復し、Aが新しいスレーブになるように、レプリケーションを再度セットアップしたいと思います。そこで、Bからバックアップを取り、サーバーAに置き、リカバリファイルを設定して起動します。ここでの問題は、2つの異なるタイムラインにあると言われているため、実際には機能しなくなっていることです。

A(新しいスレーブ)からのメッセージは次のとおりです。

2015-10-30 14:28:04 LOG:  database system was shut down in recovery at 2015-10-30 14:27:28 CET 
2015-10-30 14:28:04 LOG:  entering standby mode 
2015-10-30 14:28:04 LOG:  redo starts at 1A/5802B1A8 
2015-10-30 14:28:04 LOG:  consistent recovery state reached at 1A/581FA248 
2015-10-30 14:28:04 LOG:  record with zero length at 1A/581FA248 
2015-10-30 14:28:04 LOG:  database system is ready to accept read only connections 
2015-10-30 14:28:05 LOG:  started streaming WAL from primary at 1A/58000000 on timeline 2 
2015-10-30 14:28:07 ERROR:  requested starting point 19/FE000000 on timeline 1 is not in this server's history 
2015-10-30 14:28:07 DETAIL:  This server's history forked from timeline 1 at 19/FDCF9BA0. 
2015-10-30 14:28:12 ERROR:  requested starting point 19/FE000000 on timeline 1 is not in this server's history 
2015-10-30 14:28:12 DETAIL:  This server's history forked from timeline 1 at 19/FDCF9BA0.

私のリカバリファイルは次のようになります。

standby_mode = 'on'
primary_conninfo = 'Host=serverB port=5432 user=replication-user'
restore_command = 'copy "Z:\\pg_xlog\\%f" "%p"'
archive_cleanup_command = '"C:\\Program Files\\PostgreSQL\\9.4\\bin\\pg_archivecleanup" "Z:\\pg_xlog" "%r"'
trigger_file = 'Z:\\trigger\\pgsql.trigger.sekasto021'
recovery_target_timeline = 'latest'

グーグル私はほとんど同じ質問を見つけました ここ しかし答えはありません。 Michael Paquier からページを見つけました。私に何が起こっているのかを説明しています(バージョン9.3からは問題ないと彼は言っていますが)。彼は言う:

FATAL:  timeline 2 of the primary does not match recovery target timeline 1

これは、マスターノードからWALセグメントをコピーするか、WALアーカイブを使用することによってのみ解決できます。

しかし悲しいことに、壁のアーカイブを使用してマスターからwalセグメントをコピーすることによって彼が何を意味するのかわかりません。

どんな助け/ガイダンスも歓迎します。ありがとう

更新:私は この質問 をstackoverflowに投稿し、代わりにここに置くように求められました

1
Keyjote

Craig Ringerが述べたように、私は新しいバックアップを実行してチェックし、スレーブサーバーをセットアップした後それが機能しました。

しかし、私がすべてを行っている間、古いマスターデータベース(A)のスレーブでもある古いサーバーがあったことも思い出しました(そのサーバーは実行されていないはずだったので、最初は考えていませんでした) 。とにかく、古いスレーブを停止し、バックアップして再度復元した後、それは単に機能しました。

私が言ったように、最初はバックアップが悪いためだと思っていましたが、最終的には3番目のサーバー(2番目のスレーブデータベース)によって生成されるエラーメッセージになりました。私の主張を証明するために、古いサーバーを起動して、エラーメッセージを再度受け取りました。

2015-10-31 10:26:37 CET ERROR:  requested starting point 19/FE000000 on timeline 1 is not in this server's history
2015-10-31 10:26:37 CET DETAIL:  This server's history forked from timeline 1 at 19/FDCF9BA0.

したがって、レプリケーションはすべて単独で機能しているように見えますが、2番目のレプリケーションによって実行されたこのエラーメッセージは私を失望させていました。

繰り返しになりますが、Craigの助けに感謝します。

0
Keyjote

これで、壊れたサーバーを回復し、Aが新しいスレーブになるように、レプリケーションを再度セットアップしたいと思います。そこで、Bからバックアップを取り、サーバーAに置き、リカバリファイルを設定して起動します。ここでの問題は、2つの異なるタイムラインにあると言われているため、実際には機能しなくなっていることです。

次に、Bからのバックアップを正しく作成しませんでした。ログから、Aの古いコピーをBのレプリカとして開始しようとしているように見えます。これは機能しません。

Aから古いデータディレクトリを削除/名前変更する必要があります。次に、pg_basebackupを使用してBの新しいバックアップを作成します。

(他の方法もあります-マニュアルを参照してください-しかし、これは最も簡単で簡単に正しく理解できます)。

タイムライン切り替え後のストリーミングレプリケーションの問題は、現在の問題とは関係ありません。

0
Craig Ringer