Settings

一般設定

• logical_replication_mode プログラムが接続とテーブルフィルタ設定を解釈する方法、および比較を開始する前に接続でチェックする要件に影響します。現在、使用可能な値は次のとおりです。

  • off データベース間に論理レプリケーションがないことを想定しています。

  • native データベース間にネイティブ論理レプリケーションがあることを想定しています。 Table Filter -> publications 設定の使用を有効にして、使用するテーブルのリストを指定します。すべてのデータベースでPostgreSQL 10+が必要です。

  • pglogical データベース間にpg論理レプリケーションがあることを前提としています。 Table Filter -> replication_sets 設定の使用を有効にして、使用するテーブルのリストを指定します。また、 node_name を使用してデータ接続を指定できるようにします。これには、ノードのDSN情報を取得するために使用されるInitial Connection の設定が必要です。すべてのデータベースにpglogical 拡張機能をインストールする必要があります。

  • bdr すべてのデータ接続が同じPGDクラスターからのノードであると仮定します。 Table Filter -> replication_sets 設定の使用を有効にして、使用するテーブルのリストを指定します。また、 node_name を使用してデータ接続を指定できるようにします。これには、ノードのDSN情報を取得するために使用されるInitial Connection の設定が必要です。すべてのデータベースにpglogical およびbdr 拡張機能をインストールする必要があります。

• all_bdr_nodes logical_replication_mode がbdr に設定されている場合、初期接続のみを指定し、LiveCompareにアクティブなPGDノードの現在のリストに基づいて接続リストを構築させることができます。デフォルトoff

• max_parallel_workers 考慮する並列プロセスの数。各プロセスは、キューからテーブルで動作します。デフォルト2

重要

各プロセスはN+1のオープン接続を保持します。1つは各データ接続に、もう1つは出力データベースにです。

• buffer_size すべてのデータ取得操作でテーブルから取得する行数。デフォルト4096

• log_level ログファイルの詳細レベル。可能な値 debug 、info 、warning 、またはerror 。デフォルトinfo

• data_fetch_mode LiveCompareがデータベースからデータを取得する方法に影響します。

  • prepared_statements データの取得にプリペアドステートメントLIMIT を使用したクエリーを使用します。毎回、非常に少量のデータデフォルトではbuffer_size = 4096 行のみが取得されるため、3つのモードすべての中で最も影響が最も小さく、同じ理由でより安全な取得モードです。非同期データの取得を許可しますparallel_data_fetch で定義一般的なユースケースでは、この取得方法は良好なパフォーマンスを提供しますが、大規模なテーブルではパフォーマンスの低下が感じられる場合があります。これはデフォルトであり、サーバー負荷が中〜高の場合に強くお勧めします。

  • server_side_cursors_with_hold データの取得にサーバーサイドのカーソル WITH HOLD を使用します。テーブルデータは単一のトランザクションで取得されるため、 xmin が抑制され、肥大化とレプリケーションの問題が発生し、 VACUUM の正常な実行を妨げる可能性があります。また、 WITH HOLD 句は、クエリをマテリアライズするようにPostgresに指示するため、ワーカーはデータがマテリアライズされるまで数秒ハングする可能性がありますため、テーブルデータ全体がRAMを消費し、一時ファイルとしてPostgresサイドディスクに保存できます。 parallel_chunk_rows デフォルトで無効を使用することにより、その影響をすべて軽減し、buffer_size を少し増やすことにより速度を向上させることができます。非同期データの取得を許可しますparallel_data_fetch で定義一般的な使用ケースでは、この取得方法はprepared_stataments と比較して利点はありませんが、複数の小さなテーブルの場合、より高速です。ただし、このモードは、テストや移行シナリオなど、負荷が非常に低い場合にのみお勧めします。

  • server_side_cursors_without_hold データの取得にサーバーサイドのカーソル WITHOUT HOLD を使用します。 server_side_cursors_with_hold と同様、このモードはxmin を抑制することもできるため、Postgresでの肥大化、VACUUM 、およびレプリケーションの問題を発生させる可能性があります。ただし、 WITHOUT HOLD カーソルは比較セッション全体でオープンなトランザクションを必要とするため、このような影響はより高くなります。この要件は後のバージョンで解除されます。スナップショットは比較セッション全体で保持されるため、ユースケースによっては、比較結果が役立つ場合があります。クエリは実体化されないため、メモリ使用量と一時ファイルの生成は低いままです。非同期データの取得は許可されていません。パフォーマンスの面では、このモードは一般的なユースケースでは遅くなりますが、大規模なテーブルの場合、このモードの方が速くなる場合があります。データベースの負荷が低〜中程度の場合にお勧めします。

重要

適切なシナリオに適切な`data_fetch_mode` を選択することは非常に重要です。準備されたステートメントを使用すると、データベースサーバーのフットプリントが最小になるため、最も安全なアプローチであり、一般的なユースケースに適しています。もう1つのポイントは、準備されたステートメントを使用すると、LiveCompareが常に最新バージョンの行を参照できるということですが、これは、ビジー状態のデータベースでサーバーサイドのカーソルを使用している場合には発生しない場合があります。したがって、実稼働の高負荷サーバーには`prepared_statements` を使用し、テスト、移行シナリオ、低負荷サーバーには`server_side_cursors_*` 設定のいずれかを使用することをお勧めします。最良の戦略は、おそらく、非常に大規模なテーブルに`server_side_cursors_without_hold` を使用し、残りのテーブルに`prepared_statements` を混合することです。次の表は、費用/便益比の比較を示しています。

	prepared statements	server side cursors with hold	server side cursors without hold
xmin hold	very low	medium	high
xmin released per	buffer	chunk	whole comparison session
temp files	very low	very high	low
memory	very low	high	low
allows async conns	yes	yes	no
fastest for	general	small tables	large tables
recommended load	high	very low	low-medium

• parallel_chunk_rows 並列比較のためにテーブルを複数のチャンクに分割することを検討するために必要な最小行数。データの取得にはハッシュが使用されるため、ワーカーは互いに衝突しません。各テーブルチャンクにはparallel_chunk_rows 行以下があります。任意の値<1に設定すると、テーブル分割が無効になります。デフォルト0 無効。

重要

テーブル分割は、複数のワーカーが大きなテーブルを並列比較するのに役立ちますが、各ワーカーのパフォーマンスは、すべての行に適用されるハッシュ条件の影響を受ける可能性があります。 Postgresの構成によっては、特にデフォルトの`random_page_cost = 4` では、最近のハードドライブには保守的すぎると考えられますが、Postgresクエリプランナーは誤ってビットマップヒープスキャンを優先する場合があります。データベースがSSDで実行されている場合、LiveCompareでビットマップヒープスキャンを無効にすると、比較パフォーマンスが大幅に向上します。 start_query 設定を使用して、接続ごとにこれを行うことができます。

start_query = set enable_bitmapscan = off

• parallel_data_fetch データの取得を並列的に実行するかどうかを指定しますつまり、データベースへの非同期接続を使用します。多方向比較のパフォーマンスが向上します。 PostgreSQLではないデータ接続がある場合、この設定は自動的に無効になります。 data_fetch_mode = prepared_statements またはdata_fetch_mode = server_side_cursors_with_hold の場合にのみ許可されます。デフォルトon

• comparison_algorithm LiveCompareがテーブル行を介してデータを比較する方法に影響します。ハッシュを使用すると、完全な行比較よりも高速です。次の値のいずれかになります。

  • full_row ハッシュを使用した行比較を無効にします。この場合、完全な比較は、行を列ごとに比較することにより実行されます。 Oracle 10gデータベースを含む比較の場合、 full_row は唯一の有効なcomparison_algorithm 設定値であることに注意してください。

  • row_hash ハッシュを使用した行比較を有効にし、テーブルの分割を有効にします。テーブルは分割されているため、各ワーカーはテーブルごとの最大parallel_chunk_rows を比較します。 PostgreSQLではデータ行がハッシュされるため、比較はfull_row よりも高速です。ただし、特定の行のハッシュが一致しない場合、その特定の行に対して、LiveCompareはfull_row アルゴリズムにフォールバックしますつまり、行ごとに比較します。データ接続がPostgreSQLではない場合、LiveCompareは、検討中の行の連結列値のMD5ハッシュとして定義された行ハッシュ、比較対象のデータベーステクノロジー間の 共通ハッシュ を使用します。

  • block_hash 同様に動作しますrow_hash と同様ですが、LiveCompareは行ごとに比較する代わりに、 ブロックハッシュ 、つまり、取得されたばかりのデータバッファー最大buffer_size 行のすべての行のハッシュのハッシュをビルドします。概念的には、2レベルのマークルツリーのように機能します。ブロックのハッシュが一致する場合、LiveCompareはブロック全体を進めます。これが、この比較アルゴリズムがrow_hash よりも高速である理由です。ブロックハッシュが一致しない場合、LiveCompareはrow_hash にフォールバックし、バッファーで行ごとに比較を実行して、発散する行を見つけます。これはデフォルト値です。

• min_time_between_heart_beats ハートビート メッセージをログに記録するまで待機する秒単位の時間。各ワーカーは、比較されるラウンドパーツごとに個別に追跡します。デフォルト30秒。

• min_time_between_round_saves 比較アルゴリズムが進行中のときに各ラウンドの状態を更新するまで待機する秒単位の時間。ラウンド保存はハートビート中にのみ発生できるため、 min_time_between_round_saves はmin_time_between_heart_beats 以上である必要があります。ラウンドが終了すると、LiveCompareは常にそのテーブルのラウンドの状態を更新します。デフォルト60秒。

重要

**Ctrl-C**を押してLiveCompareの実行をキャンセルし、再度開始すると、LiveCompareはラウンドの状態が保存されたポイントから開始して、そのテーブルのラウンドを再開します。

• comparison_cost_limit > 0の場合、comparison_cost_delay 秒の昼寝をする前に各ワーカーが処理する行数に対応します。デフォルト0は、各ワーカーが昼寝をせずに行を処理することを意味します。

• comparison_cost_delay comparison_cost_limit > 0 の場合、この設定は各ワーカーのスリープ時間を指定します。デフォルト0.0

• stop_after_time Ctrl-C を押したかのようにLiveCompareが停止する秒単位の時間。コマンドラインの引数としてセッションIDを渡すことにより、中断された比較セッションがまだ終了していない場合は再開できます。デフォルトstop_after_time = 0 、これは自動中断が無効であることを意味します。

• consensus_mode どのデータ接続が発散しているかを判断するためにLiveCompareが使用するコンセンサスアルゴリズム。使用可能な値はsimple_majority 、quorum_based 、またはsource_of_truth です。 consensus_mode = source_of_truth の場合、 difference_sources_of_truth を入力する必要があります。デフォルトsimple_majority

• difference_required_quorum consensus_mode = quorum_based の場合、この設定は、どの接続が発散しているかを決定するために必要な最小クォーラムを指定します。 0.0〜1.0の数値である必要があります。 0.0は接続が必要ないことを意味し、1.0はすべての接続が必要であることを意味します。どちらの場合も極端であるため、使用をお勧めしません。デフォルト値は0.5であり、それに近い値を使用することをお勧めします。

• difference_sources_of_truth 真実のソースとして検討する接続名またはノード名、logical_replication_mode = bdr およびall_bdr_nodes = on の場合、ノード名をコンマ区切りのリスト。 consensus_mode = source_of_truth の場合にのみ使用されます。例 difference_sources_of_truth = node1,node2 この例では、 node1 Connection およびnode2 Connection のいずれかを.ini ファイルまたはall_bdr_nodes = on で定義する必要があり、Initial Connection のみが定義されますが、 node1 およびnode2 は有効なPGDノード名である必要があります。

• difference_tie_breakers コンセンサスアルゴリズムがタイ状況を見つけたときは常に、タイブレーカーとして考えられる接続名またはノード名、logical_replication_mode = bdr およびall_bdr_nodes = on の場合はノード名。例 difference_tie_breakers = node1,node2 この例では、セクションnode1 Connection およびnode2 Connections のいずれかを.ini ファイルまたはall_bdr_nodes = on で定義する必要があり、Initial Connection のみが定義されますが、 node1 およびnode2 は有効なPGDノード名である必要があります。デフォルト 接続をタイブレーカーとして考慮しません。

• difference_statements LiveCompareが生成するDMLステートメントの種類を制御します。 difference_statements の値は次のいずれかです。

  • all デフォルト

  • inserts

  • updates

  • deletes

  • inserts_updates

  • inserts_deletes edb_17_

• difference_allow_null_updates UPDATE SET col = NULL のようなコマンドを差分レポートで許可するかどうかを決定します。デフォルトon

• difference_statement_order LiveCompareが生成するDMLステートメントの順序を制御します。 difference_statement_order の値は次のいずれかです。

  • delete_insert_update

  • delete_update_insert デフォルト

  • insert_update_delete

  • insert_delete_update

  • update_insert_delete

  • update_delete_insert

• difference_fix_replication_origin PGDデータベースを使用する場合、違いのために、LiveCompareは特定のレプリケーションオリジンがまだ存在しない場合は作成します。次に、レプリケーションオリジンを使用して、DML修正を含む適用スクリプトを作成します。 difference_fix_replication_origin は、LiveCompareが使用するレプリケーションオリジンの名前を指定します。この設定の値を設定しない場合、LiveCompareはdifference_fix_replication_origin = bdr_local_only_origin を設定します。 LiveCompareが作成するレプリケーションオリジンは、比較後の検証を可能にするためにドロップされません。ただし、必要に応じて、後でレプリケーションオリジンを手動でドロップできます。 logical_replication_mode = bdr が必要です。

重要

PGD 3.6.18では、ローカル専用トランザクションを適用するために使用する新しい事前作成された`bdr_local_only_origin` レプリケーションオリジンを導入しました。したがって、LiveCompareがPGD 3.6.18に接続されている場合、このレプリケーションオリジンは作成されないため、このレプリケーションオリジンを削除しないことをお勧めします。

• difference_fix_start_query LiveCompareによって生成された適用スクリプトの先頭で実行される任意のクエリー。さらに、 PGD比較が実行されており、 difference_fix_start_query が空の場合、 LiveCompareは以下も自動的に行います。

  • 発散接続がPGD 3.6.7の場合、 SET LOCAL bdr.xact_replication = off;

  • difference_fix_replication_origin で指定されたレプリケーションオリジンを使用するようにトランザクションを設定するコマンドを追加します。

• show_progress_bars コンソール出力に進行状況バーを表示するかどうかを決定します。この設定を無効にすると、バッチ実行に役立つ場合があります。デフォルトon

• output_schema 出力接続で、比較レポートテーブルが作成されるスキーマ。デフォルトlivecompare

• hash_column_name すべてのデータ取得には、行内のすべての実際の列のハッシュである特定の列が含まれます。この設定は、この列の名前を指定します。デフォルトlivecompare_hash

• rownumber_column_name 一部の取得では、クエリ列内でrow_number() ファンクション値を使用する必要があります。この設定は、この列の名前を指定します。デフォルトlivecompare_rownumber

• fetch_row_origin この設定が有効になっている場合、LiveCompareは発散する各行のオリジン名を取得します。これは、デバッグの目的で役立つ場合があります。有効にするには、logical_replication_mode をpglogical またはbdr に設定する必要があります。デフォルトoff

• column_intersection この設定が有効になっている場合、比較される特定のテーブルについて、LiveCompareはすべての接続でテーブルの列の交差点でのみ動作し、接続に存在する可能性のある追加の列を無視します。この設定が無効になっている場合、LiveCompareは、すべての接続のテーブルで列が同等であるかどうかを確認し、列の不一致がある場合はテーブルの比較を中止します。デフォルトoff

重要

テーブルにPKがある場合、 column_intersection = on であっても、PK列は異なることはできません。

• ignore_nullable 特定のテーブル比較で、LiveCompareが主キーとは異なる比較キーを使用している場合、LiveCompareはignore_nullable が有効になっているデフォルトの場合、すべての列をNOT NULL にする必要があります。 ignore_nullable = off を設定することにより、その動作をオーバーライドできます。これにより、LiveCompareは比較でNull許容列を考慮できます。これは、一部のコーナーケースで偽陽性を生成する可能性があります。

• check_uniqueness_enforcement LiveCompareがユーザー定義の比較キーを使用しているか、テーブル内のすべての列を比較キーとして使用している場合、LiveCompareはcheck_uniqueness_enforcement 設定が有効になっているデフォルトで比較キーのテーブルの一意性をチェックします。

• oracle_ignore_unsortable 有効にすると、列がテーブルPKの一部でない場合、Oracleのソート不可データ型 BLOB、 CLOB、 NCLOB、 BFILE の列を無視するようにLiveCompareに指示します。この設定を有効にする場合、 column_intersection も有効にすることをお勧めします。

• oracle_user_tables_only 有効にすると、Oracleにログインしたユーザーからのみテーブルメタデータを取得するようにLiveCompareに指示します。このアプローチは、たとえば、sys.all_tables およびsys.all_tab_columns の代わりにsys.user_tables およびsys.user_tab_columns から読み取るため、高速です。デフォルトoff

• oracle_fetch_fk_metadata 有効にすると、外部キーメタデータを取得するようにLiveCompareに指示します。これは、遅い操作になる場合があります。 Oracle接続のfetch_fk_metadata 設定の値をオーバーライドします。デフォルトoff

• schema_qualified_table_names この設定が有効になっている場合、テーブル名はスキーマ修飾されたものとして扱われます。これを無効にすると、スキーマ修飾テーブル名を使用せずにテーブルを比較できます。 Oracle x Postgresの比較では、oracle_user_tables_only も有効にする必要があります。 Postgres x Postgresでは、同じデータベース内でも、異なるスキーマの下にあるテーブルの比較ができます。また、 schema_qualified_table_names が有効になっている場合、 Table Filter -> tables 、Row Filter 、およびColumn Filter は、スキーマ名のないテーブル名を許可します。デフォルトon

• force_collate off 以外の値および有効な照合名に設定されている場合、比較対象のすべてのPostgresデータベースのORDER BY 操作で指定された照合名を強制します。異なる照合順序でPostgresデータベースを比較する場合、またはOracleとPostgresデータベースを比較する場合に役立ちます。この場合、force_collate = C を設定します。混合テクノロジーOracleとPostgreSQLなどを比較し、照合順序が指定されていない場合、値C になります。デフォルトoff

• work_directory LiveCompare 作業ディレクトリへのパス。出力ファイルを含むセッションフォルダーがこのディレクトリに作成されます。デフォルト. 現在のディレクトリ。

• abort_on_setup_error 有効にすると、テーブル比較ラウンドを設定しようとしたときにLiveCompareがエラーを発生すると、比較セッション全体が中止されます。デフォルトoff

重要

abort_on_setup_error 設定は`compare` モード中にのみ考慮されます。 recheck モードでは、LiveCompareは常にセットアップの最初のエラーで強制終了します。

• custom_dollar_quoting_delimiter LiveCompareが違いを見つけると、文字列にドル引用符を使用してDMLを出力します。デフォルトの動作では、ランダムな文字列を作成して構成します。どうしてもカスタムのものを使用したい場合は、このパラメーターを使用する区切り文字として設定できます。定数のみを設定する必要があり、定数の周囲の$ シンボルは設定する必要はありません。デフォルトoff 、これはLiveCompareがワードLiveCompare のmd5 ハッシュを使用することを意味します。

• session_replication_role_replica 有効にすると、LiveCompareはsession_replication_role PostgreSQL設定を出力適用スクリプトでreplica として使用します。これは、発散があるノードでDMLを適用しているときにトリガーとルールが起動されないようにしたい場合に役立ちます。これを有効にするには、PostgreSQLのスーパーユーザーが必要です。それ以外の場合、効果はありません。デフォルトoff

• split_updates 有効にすると、LiveCompareはUPDATE 発散を分割します。つまり、UPDATE DMLを生成する代わりに、適用スクリプトで対応するDELETE およびINSERT を生成します。デフォルトoff

• float_point_round データベースからの浮動小数点値を比較するときにLiveCompareが丸める10進数を指定する整数。デフォルト-1 、浮動小数点の丸めを無効にします。

初期接続

初期接続は、logical_replication_mode がpglogical またはbdr に設定されている場合にのみ使用されます。 node_name 設定のみを使用するようにデータ接続を設定している場合、プログラムがノード名からDSNの取得を開始するときに使用されます。

• technology RDBMSテクノロジー。現在、使用可能な値はpostgresql のみです。

• dsn PostgreSQL接続文字列。 dsn が設定されている場合、 host 、port 、dbname 、およびuser は無視されます。 dsn 設定には、他のすべての parameter key words allowed by libpq を含めることもできます。

• host サーバーアドレス。 Unixソケット接続を使用する場合は、空のままにします。

• port ポート。デフォルト5432

• dbname データベース名。デフォルトpostgres

• user データベースユーザー。デフォルトpostgres

• application_name .アプリケーション名。他のすべての接続情報の代わりにdsn を設定した場合でも使用できます。デフォルトlivecompare_initial

出力接続

出力接続は、LiveCompareが比較レポートテーブルを作成する場所を指定します。

• technology RDBMSテクノロジー。現在、使用可能な値はpostgresql のみです。

• dsn PostgreSQL接続文字列。 dsn が設定されている場合、 host 、port 、dbname 、およびuser は無視されます。 dsn 設定には、他のすべての parameter key words allowed by libpq を含めることもできます。

• host サーバーアドレス。 Unixソケット接続を使用する場合は、空のままにします。

• port ポート。デフォルト5432

• dbname データベース名。デフォルトpostgres

• user データベースユーザー。デフォルトpostgres

• application_name .アプリケーション名。他のすべての接続情報の代わりにdsn を設定した場合でも使用できます。デフォルトlivecompare_output

データ接続

データ接続は、Initial Connection およびOutput Connection と同様の接続セクションですが、LiveCompareはデータ接続上のデータを効果的に取得および比較します。

Initial Connection およびOutput Connection と同様に、データ接続は名前付けセクションで定義されます。セクション名は<Name> Connection の形式であり、 <Name> は、英文字で始まる任意の1ワード文字列です。この場合、Name として使用するものは、データ接続の 接続ID と呼ばれます。各データ接続には、データ接続のリスト内で一意の接続IDが必要です。

logical_replication_mode = bdr およびall_bdr_nodes = on の場合、データ接続を指定する必要はありません。 LiveCompareは、Initial Connection からPGDメタデータを取得することにより、データ接続リストを構築します。

• technology RDBMSテクノロジー。現在使用可能な値はpostgresql またはoracle です。

• node_name クラスター内のノードの名前。 logical_replication_mode をpglogical またはbdr に設定する必要があり、Initial Connection が埋められることも必要です。 node_name が設定されている場合、 dsn 、host 、port 、dbname 、およびuser 設定はすべて無視されます。

• dsn PostgreSQL接続文字列。 dsn が設定されている場合、 host 、port 、dbname 、およびuser は無視されます。 dsn 設定には、他のすべての parameter key words allowed by libpq を含めることもできます。

• host サーバーアドレス。 Unixソケット接続を使用する場合は、空のままにします。

• port ポート。デフォルト5432

• dbname データベース名。デフォルトpostgres

• service Oracle接続で使用されるサービス名。デフォルトXE

• user データベースユーザー。デフォルトpostgres

• password プレーンテキストのパスワード。これの使用はお勧めしません。ただし、一部の古い接続では必要になる場合があります。

• application_name .アプリケーション名。他のすべての接続情報の代わりにdsn またはnode_name を設定した場合でも使用できます。デフォルトlivecompare_<Connection ID>

• start_query データベースへの接続が開くたびに実行される任意のクエリー。

• fetch_fk_metadata LiveCompareが接続上の外部キーに関するメタデータを収集するかどうかを指定します。デフォルトon

テーブルフィルタ

.ini ファイルのこのセクションは、省略するか空のままにした場合、最初のデータベースのすべてのテーブルに対してLiveCompareが実行されることを意味します。

特定のテーブルセットに対してLiveCompareを実行する場合、これを指定するさまざまな方法があります。

• publications 特定のパブリケーションをフィルタリングできます。LiveCompareは、これらのパブリケーションに関連付けられているテーブルのみを使用します。変数publication_name を使用して、条件式を構築できます。たとえば、

publications = publication_name = livepub

logical_replication_mode = native が必要です。

• replication_sets pglogicalまたはPGDを使用する場合、特定のレプリケーションセットをフィルタリングでき、LiveCompareはこれらのレプリケーションセットに関連付けられているテーブルでのみ動作します。変数set_name を使用して、条件式を構築できます。たとえば、

replication_sets = set_name in (default, bdrgroup)

logical_replication_mode = pglogical またはlogical_replication_mode = bdr が必要です。

• schemas 特定のスキーマをフィルタリングでき、LiveCompareはそれらのスキーマに属するテーブルでのみ動作します。変数schema_name を使用して、条件式を構築できます。たとえば、

schemas = schema_name != badschema

• tables 変数table_name は、LiveCompareで作業するテーブルのみをフィルタリングする条件式を構築するのに役立ちます。例

tables = table_name not like %%account

条件式で、 % 文字を%% としてエスケープします。

schema_qualified_table_names が無効になっていない限り、テーブル名はスキーマ修飾する必要があります。たとえば、特定のテーブルのリストのみをフィルタリングできます。

tables = table_name in (myschema1.mytable1, myschema2.mytable2)

一般設定schema_qualified_table_names を無効にする場合、接続start_query 設定でPostgresの適切なsearch_path も設定する必要があります。例

[General Setting]
...
schema_qualified_table_names = off

[My Connection]
...
start_query = SET search_path TO myschema1, myschema2

[Table Filter]
tables = table_name in (mytable1, mytable2)

重要

search_path で設定された2つ以上のスキーマに同じ名前のテーブルが含まれる場合、最初に見つかったもののみが比較の対象となります。

Table Filter セクションには、publications 、replication_sets 、schemas 、およびtables フィルターを組み合わせることができます。 LiveCompareは、指定したすべてのフィルタの交差部分にあるテーブルのセットを検討します。例

[Table Filter]
publications = publication_name = livepub
replication_sets = set_name in (default, bdrgroup)
schemas = schema_name != badschema
tables = table_name not like %%account

テーブルフィルタは、最初にデータベースに適用されてテーブルリストを構築します。テーブルが最初のデータベースに存在し、フィルタで検討されているが、他のデータベースに存在しない場合、次のようなものがログに追加され、その特定のテーブルの比較がスキップされます。

2019-06-17 11:52:41,403 - ERROR - live_table.py - 55 - GetMetaData - P1: livecompare_second_1: Table public.test does not exist
2019-06-17 11:52:41,410 - ERROR - live_round.py - 201 - Initialize - P1: Table public.test does not exist on second connection. Aborting comparison

同様に、テーブルが他のデータベースに存在するが、最初のデータベースに存在しない場合、テーブルフィルタを適用しなかった場合でも、比較では考慮されません。

テーブルの列名が完全に同じでなくcolumn_intersection が有効になっていない限り、同じ順序である場合、特定のテーブルの比較もスキップされます。適切なメッセージもログファイルに追加されます。

現在、LiveCompareは、両方のテーブルでデータ型または制約が同じであるかどうかをチェックしません。

重要

conflicts モードはテーブルフィルターを利用しません。

行フィルタ

このセクションでは、行レベルのフィルタを任意のテーブルに適用できるため、LiveCompareは行フィルタを満たす行にのみ機能します。

このセクションの下に、テーブルのリストを1行に1テーブルずつ書くことができます。 schema_qualified_table_names が無効になっていない限り、すべてのテーブル名はスキーマ修飾されている必要があります。例

[Row Filter]
public.table1 = id = 10
public.table2 = logdate >= 2000-01-01

この場合、テーブルpublic.table1 の場合、LiveCompareはid = 10 句を満たす行でのみ機能します。テーブルpublic.table2 の場合、logdate >= '2000-01-01 を満たす行のみが比較の対象となります。

一般設定schema_qualified_table_names を無効にする場合、接続start_query 設定でPostgresの適切なsearch_path も設定する必要があります。例

[General Setting]
...
schema_qualified_table_names = off

[My Connection]
...
start_query = SET search_path TO public

[Row Filter]
table1 = id = 10
table2 = logdate >= 2000-01-01

あらゆる種類のSQL条件 WHERE 句に入力するのと同じものは、テーブル行フィルタと同じ行で受け入れられます。たとえば、大規模なテーブルがあり、特定の数のIDのみを比較する場合は、すべてのIDを使用して一時テーブルを作成できます。次に、次のように IN 句を使用してJOIN をエミュレートできます。

[Row Filter]
public.large_table = id IN (SELECT id2 FROM temp_table)

行フィルタが誤って書き込まれている場合、LiveCompareはフィルタを適用しようとしますが、失敗します。したがって、この特定のテーブルの比較はスキップされ、例外がログファイルに書き込まれます。

テーブルがRow Filter セクションにリストされているが、どういうわけかTable Filter によってフィルタリングされている場合、このテーブルの行フィルタはサイレントに無視されます。

重要

conflicts モードは行フィルターを利用しません。

行フィルタで現在のタイムスタンプを使用する

Row Filter は、data_fetch_mode に応じて異なる方法で適用されます。

• Postgresでは、 data_fetch_mode をserver_side_cursors_with_hold またはserver_side_cursors_without_hold に設定すると、クエリが実行されるテーブル比較の先頭にのみRow Filter が適用されます。これは、サーバーサイドのカーソルを使用してデータを取得すると、データが比較の開始時の状態のスナップショットとして表示されることを意味します。

• Postgresでは、data_fetch_mode をprepared_statements デフォルトに設定すると、準備されたクエリーにRow Filter が含まれ、取得されるすべてのデータバッファーで実行されます。これは、クエリがRow Filter でnow() 、CURRENT_TIMESTAMP 、またはSYSDATE EDB Postgres Advanced Serverでを使用する場合、準備されたステートメントが実行されると、Postgresが現在のタイムスタンプを再評価することを意味します。

したがって、Row Filter でnow() 、CURRENT_TIMESTAMP 、またはSYSDATE を使用しているとします。たとえば

[Row Filter]
public.table3 = logdate < CURRENT_TIMESTAMP

この場合、サーバーサイドのカーソルを使用して、現在のタイムスタンプがクエリの先頭でのみ評価されるようにする必要があります。つまり、 data_fetch_mode はprepared_statements とは異なる値に設定する必要があります。

Oracleでは、data_fetch_mode 設定は無視され、クエリーは最初に実行されます。次に、データはクライアントサイドのカーソルを介して取得されます。このアプローチにより、データは比較の開始時の状態のスナップショットとして表示されます。これはクライアントサイドのカーソルですが、動作はPostgresでサーバーサイドのカーソルを使用するのと似ています。

列フィルタ

このセクションでは、列レベルのフィルターを任意のテーブルに適用できるため、LiveCompareは列フィルターの一部ではない列でのみ機能します。

このセクションの下に、テーブルのリストを1行に1テーブルずつ書くことができます。 schema_qualified_table_names が無効になっていない限り、すべてのテーブル名はスキーマ修飾されている必要があります。たとえば、 public.table1 とpublic.table2 の両方に列column1 、column2 、column3 、column4 、およびcolumn5 があるとします。

[Column Filter]
public.table1 = column1, column3
public.table2 = column1, column5

この場合、テーブルpublic.table1 の場合、LiveCompareは列column2 、column4 、およびcolumn5 でのみ機能し、column1 およびcolumn3 をフィルタリングします。テーブルpublic.table2 の場合、列column2 、column3 、およびcolumn4 のみが比較で考慮され、column1 およびcolumn5 がフィルタリングされます。

一般設定schema_qualified_table_names を無効にする場合、接続start_query 設定でPostgresの適切なsearch_path も設定する必要があります。例

[General Setting]
...
schema_qualified_table_names = off

[My Connection]
...
start_query = SET search_path TO public

[Column Filter]
table1 = column1, column3
table2 = column1, column5

存在しない列名が列フィルタで指定されている場合、つまり、列が指定されたテーブルに存在しない場合、LiveCompareは欠落している列に関するメッセージをログに記録し、それらを無視します。有効なものがある場合のみを使用します。

テーブルがColumn Filter セクションにリストされているが、何らかの理由でTable Filter によってフィルタリングされている場合、このテーブルの列フィルタはサイレントに無視されます。

重要

Column Filter で指定された列がテーブルPKの一部である場合、比較で無視されません。 LiveCompareはそれをログに記録し、このような列のフィルターを無視します。

重要

conflicts モードは列フィルターを利用しません。

比較キー

Column Filter と同様に、このセクションでは、テーブルごとに列のリストを指定することもできます。これらの列は、テーブルに主キーまたはUNIQUE 制約がある場合でも、特定のテーブルの比較キーとして考えられます。

例

[Comparison Key]
public.table1 = col_a, col_b
public.table2 = c1, c2

この例では、テーブルpublic.table1 の場合、比較キーは列col_a およびcol_b です。テーブルpublic.table2 の場合、列c1 およびc2 は比較キーとして考慮されます。

列フィルタ で説明している欠落している列、またはフィルタリングまたは欠落しているテーブルに関する同じ動作も、比較キーに適用されます。同様に、

Comparison Key セクションはconflicts モードでは無視されます。

競合フィルター

このセクションでは、 PGDノードから競合を取得するときに--conflicts モードで使用するフィルターを指定できます。任意のSQL条件式を構築し、式でこれらのフィールドを使用できます。

• origin_node サブスクリプションの上流ノード。

• target_node サブスクリプションのダウンストリームノード。

• local_time ノードで競合が発生したときのタイムスタンプ。

• conflict_type 競合のタイプ。

• conflict_resolution 適用された解像度。

• nspname 関連するリレーションのスキーマ名。

• relname 関係するリレーションのリレーション名。

セクションの下でconflicts 属性を使用する必要があります。例

[Conflicts Filter]
conflicts = conflict_type = update_missing AND nspname = my_schema

この構成の部分を.ini ファイルに追加すると、LiveCompareは、各PGDノードで競合を照会しているときに、タイプupdate_missing であり、スキーマmy_schema の下のテーブルに関連する競合のみを取得します。

重要

このセクションは`--conflicts` モード専用です。