web-dev-qa-db-ja.com

Postgresレプリケーションが遅れている-マスター->スレーブ、スレーブ、スレーブ

現在、マスターから直接取得する1つのマスターサーバー（a）と3つのレプリケーションサーバー（b、c、d）があります。使用するarchive_commandは次のスクリプトです： https://Gist.github.com/ Geesu/8640616

すべてのサーバーは、PostgreSQL9.2.6を実行するUbuntu12.04.4です。

そして、これが各レプリケーションサーバーのrecovery.confです： https://Gist.github.com/Geesu/8640635

奇妙なのは、レプリケーションサーバーを起動してから約6時間後、そのうちの2つがすぐに遅れて、追いつくために立ち往生しているのですが、さらに遅れをとっています。マスターと比較して、どれだけ遅れているかを次に示します。

a 20287.825072
b 2.521136
c 19994.51653

サーバーの1つがほぼ完全に追いついているのに、他のサーバーが遅れをとっている理由について誰かが何か考えを持っていますか？ aとcがWALセグメントを処理していることを確認しましたが、十分な速度で処理することができません。

Aとcからのいくつかのログ例：

cp: cannot stat `/var/lib/postgresql/9.2/archive/000000080000109E0000009A': No such file or directory
2014-01-26 23:02:14 GMT LOG:  record with zero length at 109E/9AE622D8
cp: cannot stat `/var/lib/postgresql/9.2/archive/000000080000109E0000009A': No such file or directory
2014-01-26 23:02:14 GMT LOG:  streaming replication successfully connected to primary
2014-01-26 23:03:36 GMT FATAL:  could not receive data from WAL stream: SSL error: sslv3 alert unexpected message

cp: cannot stat `/var/lib/postgresql/9.2/archive/000000080000109E000000B9': No such file or directory
2014-01-26 23:03:41 GMT LOG:  record with zero length at 109E/B9E797E0
cp: cannot stat `/var/lib/postgresql/9.2/archive/000000080000109E000000B9': No such file or directory
2014-01-26 23:03:41 GMT LOG:  streaming replication successfully connected to primary

多分これは関連していますか？最終的には、適切なWALセグメントを取得して、処理されます。

これをさらにデバッグする方法についての提案はありますか？

postgresqlreplication
4
Geesu

ここでいくつか間違っていることがあります。

WALスクリプト

すべてが成功するまで、各サーバーにプッシュしようとします

まず、マスターサーバーはWALアーカイブを各レプリカにプッシュしている（またはしようとしている）ので、3つすべてがファイルを受信した場合にのみarchive_commandを成功として扱います。つまり、1つがダウンすると、他の2つは新しいWALの受信を停止します。これは、マスターのPgがスタックしたままで、同じセグメントを何度も再試行するためです。

失敗しても気付かない

スクリプトは実際には$FAILを返さないため、実際にはこれは機能しません。3つのサーバーすべてがWALファイルの受信に失敗した場合でも、スクリプトは成功を報告します。以前の失敗がシーケンス全体が役に立たず、再生できないことを意味するという事実を無視して、WALファイルに移動し続けます。これは、レプリカがローカルWALセグメントを見つけられない理由をよく説明している可能性があります。 env-varの問題（RSYNC_RSH）、既知のホストの問題、ssh keyの問題などが原因で、コピーに失敗した可能性があります。

Wal送信者スクリプトを修正する方法

プッシュ/プルモデルに切り替えることを強くお勧めします。マスターサーバープッシュWALを信頼できるストレージの場所に移動します。次に、その場所からレプリカpullを取得します。マスターはファイルを1回コピーするだけでよく、一部のサーバーがダウンしたり、他のサーバーが追いついたりした場合に、サーバーごとに異なるポイントで再試行することを心配する必要はありません。ブロックサービス（WABS）とOpenStackのSwiftも便利です。これに役立つツールは WAL-E で、archive_commandとrestore_commandとして機能します。すべてをサポートします。記載されている店舗の.

便利なことに、S3を使用する場合は、古いものを削除するのではなく、Glacierに隠して、後で削除するアーカイブポリシーを設定できます。これは、「万が一に備えて」このようなものを保存するための安価で便利な方法ですが、関連する基本バックアップも保存しない限り、役に立たないことを忘れないでください。

mustが3つのバックエンドすべてにマスタープッシュを持っている場合は、それをより賢くする必要があります。サーバーは各WALセグメントを受信し、1つのサーバーがセグメントと以前のすべてのセグメントを受信したときに成功を報告します。遅れているサーバーを再試行し続けるバックグラウンドジョブが必要になります。それでも、これは悪い考えです。これにより、WALのアーカイブが最も遅いサーバーと同じくらい遅くなります。これは実際には理想的ではなく、マスターが非常にひどくいっぱいになる可能性があります。これを機能させることができると確信していますが、IMOは非常に壊れやすく複雑です。

ストリーミングレプリケーションが壊れています-SSLv3再ネゴシエーションのバグ？

ログ内：

2014-01-26 23:03:36 GMT致命的：WALストリームからデータを受信できませんでした：SSLエラー：sslv3アラート予期しないメッセージ

サーバーはストリーミングレプリケーション用に設定されていますが、SSLの問題があります。これは、sslv3再ネゴシエーション問題の署名エラーであり、初期の脳死したOpenSSLの「修正」です。問題が修正されるはずなので、最新のOpenSSLパッチリリースに更新したことを確認してください。

そうでない場合は、回避策として、ssl_renegotiation_limit=0でpostgresql.confを試すことができます。 このランチパッドのバグ を参照してください。

3
Craig Ringer