LiveCompare

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

＃はじめに

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

デフォルトでは、比較セットにはデータベース内のすべてのテーブルが含まれます。 LiveCompareでは、マルチプルのテーブル（マルチプルのワーカープロセス）を同時にチェックでき、いくつかのテーブルまたはテーブル内の行のセクションのみをチェックできるように高度に構成できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

比較パフォーマンス

LiveCompareは、稼動システムでの使用に最適化されており、後述のチューニング用のさまざまなパラメーターがあります。比較ラウンドは読み取り専用のワークロードです。使用例では、4つの接続と4つのワーカーで9分17秒の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_superuserロールが付与されたユーザが必要です。

BDRでDMLスクリプトを適用するには、すべての分岐接続（場合によってはすべてのデータ接続）で、bdr.xact_replicationを無効にオーダーにbdr_superuserが付与されているユーザが必要です。

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

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