LiveCompare

© Copyright EnterpriseDB UK Limited 2019-2021 - 全著作権所有。

はじめに

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

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

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

各テーブル比較操作は「比較ラウンド」と呼ばれます。テーブルが大きすぎる場合、LiveCompareはテーブルを多重比較ラウンドに分割し、同時に他のワーカーが実行している他のテーブルとともに実行します。

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

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

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

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

LiveCompareを使用して、行レベルで論理データの整合性を保証できます。たとえば、次のシナリオの場合。

  • データベース技術の移行（Oracle x Postgres）;

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

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

  • フェイルオーバーインシデントの後、たとえば、新しいプライマリデータを古い分離されたプライマリデータと比較するため。

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

  • 論理複製。 Postgresネイティブ論理レプリケーション、 pglogical 、 BDRの3種類の論理レプリケーションテクノロジーがサポートされています。

比較パフォーマンス

LiveCompareは実稼働システムでの使用に最適化されており、後述するチューニング用のさまざまなパラメーターがあります。比較ラウンドは読み取り専用のワークロードです。ユースケースの例では、4つの接続と4つのワーカーを使用して9分17秒で6つのテーブルの43,109,165行を比較しました。

上記のユースケースは、一般的なユースケースと見なすことができます。低負荷、テスト、移行、およびその他の特定のシナリオでは、サーバー側のカーソルを使用するように 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 のデフォルト設定では、適用スクリプトのトランザクションはロールを表の所有者に変更し、データベースユーザーが悪意のあるトリガーを作成して修正を適用するロールにアクセスするのを防ぎます。その結果、ダイバージェント接続のユーザーには、ロールをテーブル所有者に切り替える機能が必要です。