Introduction ============ 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。 - サーバーの移行またはアップグレード古いサーバーx新しいサーバー。 - 物理レプリケーションプライマリ×スタンバイ。 - フェイルオーバーインシデントの後、たとえば、新しいプライマリデータを古い分離されたプライマリデータと比較します。 - フェイルオーバー後に予期しないスプリットブレイン状況が発生した場合。古いプライマリが適切にフェンスされず、アプリケーションがデータを書き込んだ場合、LiveCompareを使用して、古いプライマリに存在し、新しいプライマリに存在しないデータを正確に知ることができます。必要に応じて、 DBAはLiveCompareが生成するDMLスクリプトを使用して、これらのデータを新しいプライマリに適用できます。 - 論理レプリケーション。 Postgresネイティブ論理レプリケーション、pglogical、およびEDB Postgres DistributedPGD、以前はBDRとして知られている3種類の論理レプリケーションテクノロジーがサポートされています。 比較パフォーマンス ------------------ LiveCompareは、実稼働システムで使用するように最適化されており、チューニングのためのさまざまなパラメーターを備えています。比較ラウンドは読み取り専用のワークロードです。ユースケース例では、4つの接続と4つのワーカーを使用して9分17秒で6つのテーブルの43,109,165行を比較し、1秒あたり約77,000行、または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`` ロールを持つユーザーが必要です。 PGDでDMLスクリプトを適用するには、すべての分岐接続潜在的にすべてのデータ接続で、 bdr_superuserロールを持つユーザーが\ ``bdr.xact_replication`` を無効にする必要があります。 PGDが使用されている場合、LiveCompareはすべての固定行を\ ``bdr_local_only_origin`` と呼ばれるレプリケーションオリジンに関連付けます。 LiveCompareは、かなり過去のトランザクション日時を含むDMLも適用するため、データベースで実行されている実際のDMLとPGD競合がある場合、LiveCompare DMLは常に競合に負けます。 デフォルト設定の\ ``difference_fix_start_query`` では、適用スクリプトのトランザクションはテーブルの所有者にロールを変更して、データベースユーザーが悪意のあるトリガーを書いて修正を適用するロールへのアクセスを取得しないようにします。その結果、分岐接続のユーザーは、ロールをテーブル所有者に切り替えることができる必要があります。