LiveCompare

© Copyright EnterpriseDB UK Limited 2019-2021-無断複写・禁無断転載

＃はじめに

LiveCompareは、任意の数のデータベースを比較して、それらが同一であることを確認するように設計されています。このツールは、任意の数のデータベースを比較し、比較レポート、相違点のリスト、および便利なDMLスクリプトを生成して、ユーザがオプションでDMLを適用し、任意のデータベースの不整合を修正できるようにします。

デフォルトでは、比較セットにはデータベース内のすべてのテーブルが含まれます。LiveCompareでは、マルチプルのテーブルを同時にチェックできます（マルチプルのworkerprocesses）。

各データベース比較は「比較セッション」と呼ばれます。プログラムが初めて起動すると、新しいセッションがスタートされ、テーブルごとの比較がスタートされます。スタンドアローンモードでは、すべてのテーブルが比較されると、プログラムは停止し、すべてのレポートを生成します。 LiveCompareは、コンテキスト情報を失うことなく停止および開始できるため、都合の良いときに実行できます。

各テーブル比較オペレーションは「比較ラウンド」と呼ばれます。テーブルが大きすぎる場合、LiveCompareはテーブルをマルチプルの比較ラウンドに分割し、同時に他のワーカーによって実行されている他のテーブルと並行して実行されます。

スタンドアローンモードでは、テーブルの最初の比較ラウンドは、テーブルの最初（既存の最も古いPK）からテーブルの最後（最も新しいPK）まで始まります。ラウンドの開始後に挿入された新しい行は無視されます。 LiveCompareは、各テーブルから最小および最大PKを取得オーダーにPK列をソートします。ソートできない各PK列について、LiveCompareはそのコンテンツをstringにキャストします。 ::textを使用して実現されたPostgreSQLでは、to_charを使用してオラクルで実現されます。

比較アルゴリズムを実行する場合、各ワーカーはN + 1個のデータベース接続を必要とし、Nは比較されるデータベースの数です。追加の必須接続は、プログラムキャッシュが保持される出力/レポートデータベースへの接続であるため、ユーザは比較セッションを停止/再開できます。

比較アルゴリズムで見つかった違いは、後で都合の良いときにユーザが手動で再確認できます。これは、複製の整合性チェックを許可するために行うことをお勧めします。差分の再チェック時に、その特定の行で複製が検出され、差分がもう存在しないため、差分が削除されます。そうでない場合は、永続としてマークされます。

実行の最後に、プログラムはDMLスクリプトを生成して、ユーザがそれをレビューし、差異を1つずつ修正するか、DMLスクリプト全体を単純に適用して、すべての永続的な差異を修正できるようにします。

LiveCompareは、行レベルでロジカルデータの整合性を保証に潜在的に使用できます。例、次のシナリオの場合：

  • データベース技術の移行（オラクル x Postgres）;

  • サーバーの移行またはアップグレード（古いサーバーx新しいサーバー）;

  • 物理レプリケーション（プライマリxスタンバイ）;

  • フェイルオーバーインシデント後、例、新しいプライマリデータを 古い分離されたプライマリデータ。

  • フェイルオーバー後に予期しないスプリットブレインシチュエーションが発生した場合。古い場合 プライマリが適切にフェンスされておらず、アプリケーションがデータを書き込みました。 LiveCompareを使用して、古いデータに存在するデータを正確に知ることができます。 プライマリであり、新しいプライマリには存在しません。必要に応じて、 DBAは これらのデータを新しいプライマリに適用するためにLiveCompareが生成するDMLスクリプト。

  • 論理レプリケーション。 3種類のロジカルレプリケーションテクノロジーは サポート： Postgresネイティブロジカルレプリケーション、pglogicalおよびBDR。

比較パフォーマンス

LiveCompareは、稼動システムでの使用に最適化されており、後述のチューニング用のさまざまなパラメーターがあります。比較ラウンドは読み取り専用のワークロードです。ユースケースの例では、4つの接続と4つのワーカーで9m 17sの6つのテーブルの43,109,165行を比較し、1秒あたり約77k行、または4時間未満で10億行のパフォーマンスを比較しました。

上記のユースケースは、一般的なユースケースと考えることができます。低負荷、テスト、移行、およびその他の特定のシナリオでは、data_fetch_mode設定を変更してサーバサイドカーソルを使用することで速度を改善できる場合があります。私たちの実験では、サーバーサイドカーソルの種類ごとに、小さなテーブルまたはラージテーブルを含むユースケースのパフォーマンスが向上します。

ユーザーのセキュリティに関する考慮事項

PostgreSQL 13以前の場合、LiveCompareには、比較されるすべてのデータを読み取ることができるユーザが必要です。 PostgreSQL 14では、LiveCompareに使用できる新しいロールpg_read_all_dataが導入されました。

logical_replication_mode = bdrの場合、LiveCompareにはbdr_superuserロールを付与されたユーザが必要です。 logical_replication_mode = pglogicalの場合、LiveCompareにはpglogical_superuserroleが付与されているユーザが必要です。

BDRでDMLスクリプトを適用するには、すべての分岐接続（潜在的にすべてのデータ接続）で、bdr.xact_replicationを無効にするためにbdr_superuserを付与されたユーザが必要です。

BDRが使用されている場合、LiveCompareはすべての固定行をbdr_local_only_originという複製オリジンに関連付けます。 LiveCompareは、過去のトランザクション日時を使用してDMLを適用するため、データベースで実行されている実際のDMLとBDRの競合がある場合、LiveCompare DMLは常に競合を失います。

デフォルト設定のdifference_fix_start_queryを使用すると、トランザクションinapplyスクリプトは、悪意のあるトリガーを書き込むことで修正を適用するロールにデータベースユーザーがアクセスできないオーダーに、ロールをテーブルの所有者に変更します。その結果、分岐接続のユーザは、テーブルの所有者にロールをスイッチができるニーズがあります。