PostgreSQLレプリケーションの本番準備はできていますか?


16

PostgreSQLネイティブレプリケーションはMySQLと比較してどうですか?

私は非同期レプリケーションが最近の同期よりも長い間サポートされていることを知っています。同期は実際のプロジェクトで使用するのに信頼できますか?

回答:


31

生産準備はできていますか?

はい、生産準備が整っており、広く使用されています。Herokuのフォロワーは、AWS RDSスタンバイやリードレプリカなど、PostgreSQLの組み込み非同期レプリケーションに基づいています。ストリーミングレプリケーションは、PostgreSQLでほぼ普遍的に使用されます。

レプリケーションのセットアップは正確ではありませんが、repmgrのようなツールはそれをいくらか助け、メジャーリリースごとにゆっくりと改善されています。pg_basebackupがストリーミングレプリケーションを使用してシステムのコピーを取得する機能(および別のスタンバイから取得する機能)は大きな助けになります。

一般的に、機能は本番環境で使用可能になるまでPostgreSQLでリリースされません。バグは、他のソフトウェアと同様に発生しますが、通常は特定されるとすぐに修正されます。本当に主要な新機能には、.0リリース後にバグや問題が発見される場合がありますが、修正することが優先度の高いものです。バグが残っているだけではありません。

ストリーミングレプリケーションに関する重大な問題(同期または非同期)を認識していません。また、かなり長い間報告されたこともありません。それらは、導入されたメジャーバージョンの.0リリースでのPgの通常の標準よりも安定性に劣りましたが、両方とも急速に成熟し、完全に生産準備が整っています。

(アップデート:9.3.4より前の新しい9.3バージョンには、レプリケーションの問題を引き起こす特定のバグがありました。9.3のユーザーはすぐに9.3.4にアップデートする必要があります。古いバージョンは影響を受けません。)

私が言及したい唯一の注意点は、同期レプリケーションのマイナーな詳細です:マスターでコミットする場合、レプリカが確認するのを待っている間にコミットした後、クエリをキャンセルします。レプリカが応答するのを待っている間にマスターを再起動しても同じ効果が得られます。実際には、これは無意味ですが、考えられる唯一の問題についてです。

MySQLと比較しますか?

Pgのネイティブレプリケーションは、MySQLとはまったく異なります。

MySQLは、テーブルデータ、テーブル構造などに加えられた論理的な変更を送信する論理レプリケーションを使用し、レプリカはそれらの変更を適用します。

PostgreSQLのレプリケーションは低レベルです(9.5以下。将来のバージョンでは論理レプリケーションも追加される可能性があります)。テーブルで変更されたブロックを送信します。シンプルで正しい方法であり、レプリカサーバーの負荷を軽減しますが、より多くのネットワーク帯域幅を消費し、まだ複製されていない変更を保持するためにより多くのストレージが必要です。WALアーカイブフォールバックでストリーミングレプリケーションを使用するように最適に構成されているため、MySQLよりも構成が複雑になります。タプルの変更だけでなく、VACUUMアクティビティなどの低レベルの変更をレプリケートし、レプリカのディスク上の状態をマスターの状態と同じに保ちます。1つのデータベースのみを複製することはできません。システム全体をレプリケートする必要があります。1つの大きな、解約率の高い重要でないデータベースと1つの小さな、解約率の低い重要なデータベースがある場合、イライラする可能性があります。

全体として、それはあなたがそれで何をしたいかに依存します。

PostgreSQLのレプリケーションは、バックアップ、高可用性、および災害復旧に使用されるレプリカにとってかなり優れていると考えています。特にポイントインタイムリカバリ(PITR)と組み合わせた場合。

一方、読み取り専用のレポートレプリカには適していません。長いトランザクションの実行中にレプリケートされたデータのアプリケーションを遅延させる必要があるため、非常に長時間実行されているクエリをキャンセルするか、マスターの大幅な遅れをとる必要があるためですマスターのディスク領域を増やし、追いつくためにマスターを強制的に動作させます。

PostgreSQLでは、ディスク上の状態ではなく、テーブル構造やテーブルの内容などに対する論理的な変更が複製される論理複製有効にするための作業が進行中です。Pgのカタログ設計とユーザー定義のすべてのサポートにより、これは非常に複雑なタスクになります。9.4の基盤の一部は導入されていますが、完全な論理レプリケーションは9.6以降では使用できそうにありません。


私も持っていた質問に対する素晴らしい答え。クレイグありがとう。
-swasheck

6
同期担当者については、一部のユーザーを驚かせることが1つありますが、考えてみると本当に理にかなっています。同期レプリケーションの対象となるトランザクションのコミットは、トランザクションがマスター以外の少なくとも1つのクラスターで永続化されるまで戻りません。他のシステムから来た人は、レプリケーションの試行に時間がかかりすぎない限り発生するはずだと感じています。これは、「そうでない場合を除いて同期」を意味します。複数の同期ターゲットを使用して、レプリカが失敗した場合のストールを回避するか、非同期を使用します。
kgrittn

1
@kgrittn良い点は複数のターゲットです。トランザクションが同期レプリケーションでレプリケートされる前に、コミットが返されることを誰もが望んでいる、または期待していることを、私は少し怖がっています。彼らは本当にフォロワーが十分に追いつくまでマスターへの書き込みを一時停止する最大フォロワーギャップ制限を持つ非同期レプリケーションが必要なように聞こえますか?完璧に合理的なものですが、同期担当者ではありません。
クレイグリンガー

1
@CraigRinger:人々が求めるものは、あなたが述べたものではなく、「同期担当者を使用するが、同期に時間がかかりすぎる場合は自動的に非同期担当者にフォールバックする」と要求することがあります。そのため、マスターがレプリカから大幅に遅れている場合、マスターを一時停止する必要はありません。他のサイトへの書き込みを行わずコミットをすばやく確認したい場合です。私には、それが提供されている以上のものを約束しているように聞こえます。彼らは事前に「ええ、あなたは同期担当者を持っています。あなたは安全です」と望んでいます。クラッシュ後、「コミットされたデータはなくなっています。実際にはどこにも書き込まれていません。」
kgrittn

@CraigRingerは、おそらくpg10 / logicalで更新しますか?
エヴァンキャロル
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.