3

Postgresには、同期レプリケーション、ストリーミングレプリケーション、その他のバリアントを含むレプリケーションが組み込まれていることに気づきました。アプリケーションレベルでの特定の操作の同期を制御する機能も提供します（たとえば、送金などの重要なものには同期を使用しますが、ユーザーのコメントなどのそれほど重要ではないものには使用しないでください）。

私はDjango1.5（つまり、dev）を使用するソフトウェアに取り組んでおり、同期レプリケーションが必要になる可能性があります（コマース関連のトランザクションが実行されます）。

ほとんどの場合、組み込みツールがこの作業に最適だと思いますか。また、組み込みレプリケーションの1つのバリアントと別のバリアント、使いやすさ、品質などについて何か考えがありますか。

最後にもう1つ。SlonyとPGPoolIIは、レプリケーションでかなり人気があるようです（特に、Slony）。A）組み込みのレプリケーションよりも人気がある特定の技術的な理由、またはB）多くの人が組み込みのレプリケーションを持たないバージョンを使用しているという理由だけで、C）私は岩の下にいるPGの組み込みレプリケーションはすでに非常に人気がありますか？

更新（詳細）

物理サーバーは2つしかなく、同じラックにあります。私の意図は、1台のマシンで何かが壊滅的に失敗した場合（または二重電源障害などの単純なもの）に、自動的にマスターになることができるスレーブを提供することです。ダウンタイムが1時間程度ではなく、数分程度である限り、クライアントが自動フェイルオーバー中にダウンタイムを経験してもかまいません。

データの損失をゼロにしたいと考えており、そのためにフェイルオーバープロセスでより多くの時間を犠牲にするつもりです。同期レプリケーションを行わずにこのトレードオフを行う方法はありますか（たとえば、ライトバック確認などを行わずにログをストリーミングする）？

レプリケーションのどの戦略またはバリアントをお勧めしますか？

4

2 に答える 2

5

レプリケーションでの同期コミットの利点とコストを誤解していると思います。PostgreSQLでは、レプリケーションは、PostgreSQLの標準のクラッシュリカバリ機能を使用して、マスターまでのスレーブをリカバリすることで機能します。たとえば、電源が切れた場合、先行書き込みログセグメントがマスターとスレーブの両方で実行されることを確認できます。非同期コミットでは、コミットがWALに書き込まれ、アプリケーションに通知され、ネットワークの特性などに応じて、ほぼ同時にスレーブに通知されます。

同期コミットが役立つのは、次の2つの点です。

  1. 複数のスレーブがあり（これは重要です！）、
  2. 非同期コミットでは提供できないという耐久性の保証が必要です。

同期コミットでは、データベースは、構成可能な数のスレーブから応答が返って、コミットが発生したことをアプリケーションに通知するまで待機します。これにより、非同期コミットが機能しないいくつかの場合に耐久性が保証されます。

たとえば、マスターサーバーがRAIDアレイを介して弾丸を取り、すぐにクラッシュするとします（申し訳ありませんが、優れたハードウェアを備えたより良い例は考えられませんでした）。または、誰かが電源コードにつまずいて、サーバーの電源を切るだけでなく、ソフトウェアRAIDデバイスを破損したとします。この場合、いくつかのトランザクションが複製されておらず、WALが回復不能である可能性があるため、それらのトランザクションは失われます。同期コミットを使用すると、アプリケーションは耐久性の保証が満たされるまで待機していました。

これが意味することの1つは、1つのスレーブのみで同期コミットを行う場合、可用性はマスターまたはスレーブのいずれかでのクラッシュよりも長持ちしないため、1つのサーバーのみの場合よりも可用性が低下することです。また、スレーブが地理的に削除されている場合、トランザクションをコミットするアプリケーションの要求にかなりの遅延が発生することも意味します。

非同期から同期コミットに切り替えることは大きな変化ではありませんが、一般的に、ハードウェアで保証と可用性の面で可能な限り多くのことをすでに実行している場合は、同期コミットを最大限に活用できると思います。asyncから始めて、セットアップをasyncとしてさらに最適化できない場合は上に移動します。

于 2012-10-07T01:47:49.290 に答える
4

Re：「SlonyとPGPool IIは、レプリケーションでかなり人気があるようです（特に、Slony）。A）組み込みレプリケーションよりも人気がある特定の技術的な理由がありますか、B）多くの人がレプリケーションが組み込まれていないバージョンを使用している、またはC）私は岩の下にいて、PGの組み込みレプリケーションはすでに非常に人気がありますか？」

Slonyはかなり長い間使用されており、組み込みのPostgreSQLレプリケーションは比較的新しいため、人気があります。PostgreSQLに組み込まれているカスケードレプリケーションはさらに新しく、Slony-Iが構築されたものです。

Slony-Iには2つの主な利点があります。まず、異なるバージョンのPostgreSQL間で複製できますが、組み込みの複製システムは同じバージョンを使用する必要があるだけでなく、2つのサーバーもバイナリ互換である必要があります。もう1つの利点は、データベースクラスター全体ではなく、Slony-I上の特定のテーブルのみを複製できることです。Slony-Iの欠点は数多くあり、使い勝手が悪い、同期コミットがない、DDL（スキーマ）の変更が難しいなどがあります。Postgresでの組み込みレプリケーションの使用は、まだ行っていない場合、Slony-Iユーザーベースをすぐに超えると思います。

私が覚えている限り、PGPool IIはステートメントベースのレプリケーション（MySQLに組み込まれているもののような）を使用しており、私の意見では間違いなく最も望ましくありません。

PostgreSQLに組み込まれているホットスタンバイ/ストリーミングレプリケーションを使用します。同期コミットをオンにして、不要な場合やペナルティが高すぎる場合はオフにすることができます。その逆も可能です。LANを介して、非同期モードは100ミリ秒程度のオーダーでスレーブに到達するようです（私自身の経験から）。

于 2012-10-08T05:33:15.053 に答える