実稼働環境でのPostgresql 9.1のストリーミングレプリケーションの実装に問題がありました。 そして以来 彼女とはビジネスがなかったので、彼らは彼女の「極端なテスト」を行うことにしました。
これを行うために、Ubuntu Serverを備えた2つのVMWare Player仮想マシンが起動されました。 Postgresql 9.1にストリーミングレプリケーションをインストールおよび構成しました。
同期速度
複製されたデータベースのテストテーブルにループで多数の行を追加するスクリプトがホストマシンから起動されました。 スクリプトは3つのスレッドで実行されました。
仮想マシンでは、プロセッサ（bashの無限ループ）とテストテーブルからデータを読み取ることの両方で負荷が作成されました。 不均一な負荷もチェックされました-スレーブ上で切断され、次にマスター上で切断されました。
結果は非常に素晴らしい写真でした。 それらは「目で」評価されましたが、1〜2秒以上の間、非同期化は認められませんでした。 そして、そのような非同期化は、非常に高い負荷（複数の並列負荷プロセス）で、短時間だけ発生しました。
停電安定性
fsync =オフ
更新および挿入操作を高速化するために、Postgresqlの以前のバージョンがfsync = offオプションとともに使用されました。 fsyncを無効にし、仮想マシンのハードシャットダウン（電源障害のシミュレーション）を使用したレプリケーションの動作をテストしました。
結果はかなり予測可能でした。 起動してデータベースを復元した後、マスターのバイナリログの現在のポイントがスレーブの処理されたポイントよりも早いことが判明しました。 つまり データベースは完全に同期されていないため、サーバーを最初から同期する必要があります（スレーブデータベースを作成する通常の手順に従って、データディレクトリ全体をコピーします）。
fsync =オン
サーバーを同期した後、fsyncが有効な場合のレプリケーションの動作をテストしました。
「ハード」シャットダウンでは、特別なことは何も起こりませんでした。 彼は立ち上がり、マスターと一緒に雑誌に「追いついた」。
より興味深い状況は、マスターをオフにするときです。 正確に切断されると、電源はオフになり、待機し、オンになり、チェックされ、すべて正常に終了しました。 ベースは上昇し、回復し、スレーブと同期することが判明しました。
次に、データセンターで「電気の点滅」のシミュレーションを実行しました。 マスターサーバーは、任意の時点で数回「ハードリセット」されました。 通常、これらの瞬間は、Postgresqlサーバーの起動時またはその少し後に発生しました。 その結果、マスターのベースは正常に上昇しましたが、スレーブにはいくつかの小さな問題がありました。 スレーブログで、トランザクションレコードのサイズが間違っているというメッセージがポップアップし始め、マスターと同期しませんでした。 ただし、スレーブでPostgresqlを再起動すると、すべて正常に機能しました。
fsync値に応じた挿入速度
挿入速度のfsync値への依存性は、いくつかのサイクルでテストされました。 結果によると、fsync = offの場合、速度は約3.3％速くなります。 電源がオフになったときにベースの損失を加速することは価値があります-それは誰もが決めることです。 私は個人的にfsync = onでPostgresqlのみを使用するつもりです。
ファイルトリガーを使用してスレーブをマスターモードに切り替えます
切り替えはうまく機能します。 しかし、1つの「しかし」があります。 このスイッチを使用すると、スレーブは完全に独立したマスターになります。 つまり マスターと完全に同期せずにスレーブ状態に戻すことは不可能です。 これは、新しいタイムラインが作成されたという事実の結果です-タイムライン。 また、この結果、複数のスレーブを使用する場合、他のすべてのスレーブは新しいマスターから切断されます。 そしてそれらを接続するには、完全な同期が必要です。
まとめ
これらのテストの結果、私は個人的に、Postgresql 9.1のストレム複製が完全に機能し、信頼できると確信しました。