Settings

一般設定

  • logical_replication_mode ：プログラムが接続とテーブルフィルター設定を解釈する方法（詳細は以下を参照）、および比較を開始する前に接続で確認する要件に影響します。現在、可能な値は次のとおりです。

- `off`: Assumes there is no logical replication between the databases;

- `native`: Assumes there is native logical replication between the
databases. Enables the usage of the `Table Filter -> publications`
setting to specify the list of tables to be used. Requires PostgreSQL 10+ on
all databases.

- `pglogical`: Assumes there is pglogical replication between the databases.
Enables the usage of the `Table Filter -> replication_sets` setting to
specify the list of tables to be used. Also enables the usage of `node_name`
to specify the data connections, which require setting the `Initial
Connection` that is used to retrieve DSN information of the nodes. Requires
the `pglogical` extensions to be installed on all databases.

- `bdr`: Assumes all data connections are nodes from the same PGD cluster.
Enables usage of `Table Filter -> replication_sets` setting to specify list
of tables to be used. Also enables usage of `node_name` to
specify the data connections, which require setting `Initial Connection`
that is used to retrieve DSN information of the nodes. Requires `pglogical`
and `bdr` extensions installed on all databases.

  • 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

Oracleに関する注意 ：Oracleの場合、 data_fetch_mode 設定は完全に無視され、データは常に直接クエリを使用してOracleからフェッチされ、データはクライアント側のカーソルを介してbuffer_size のチャンクで取得されます。

  • 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`: Disables row comparison using hashes. Full comparison, in this
case, is  performed by comparing the row column by column.

- `row_hash`: Enables row comparison using hashes and enables table
splitting. Tables are split so each worker compares a maximum of
`parallel_chunk_rows` per table. Data row is hashed in PostgreSQL, so the
comparison is faster than `full_row`. However, if for a specific row the
hash does not match, then for that specific row, LiveCompare will fallback
to `full_row` algorithm (i.e., compare row by row). If any data connections
is not PostgreSQL, then LiveCompare uses a row hash thats defined as the MD5
hash of the concatenated column values of the row, being considered a
"common hash" among the database technologies being compared.

- `block_hash`: Works the same as `row_hash`, but instead of comparing row
by row, LiveCompare builds a "block hash", i.e., a hash of the hashes of all
rows in the data buffer that was just fetched (maximum of `buffer_size`
rows). Conceptually it works like a 2-level Merkle Tree. If the block hash
matches, then LiveCompare advances the whole block (this is why this
comparison algorithm is faster than `row_hash`). If block hash does not
match, then LiveCompare falls back to `row_hash` and performs comparison row
by row in the buffer to find the divergent rows. This is the default value.

  • 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` (default)
- `inserts`
- `updates`
- `deletes`
- `inserts_updates`
- `inserts_deletes`
- `updates_deletes`

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

  • difference_statement_order ： LiveCompareによって生成されるDMLステートメントの順序を制御します。 difference_statement_order の値は、次のいずれかです。

- `delete_insert_update`
- `delete_update_insert` (default)
- `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は次のことも自動的に行います。

- If the divergent connection is PGD 3.6.7, add
`SET LOCAL bdr.xact_replication = off;`
- Add commands that setup transaction to use the replication origin
specified in `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は発散する各行のオリジン名をフェッチします。これはデバッグ目的に役立つ場合があります。デフォルト：off 。有効にするには、 logical_replication_mode をpglogical またはbdr に設定する必要があります。

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

重要 ：テーブルにPKがある場合、column_intersection = on であっても、PK列が異なることは許可されません。

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

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

  • 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 と同様に、named sectionに「データコネクション」を定義します。セクション名は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 ファイルのこのセクションは、 first データベースの すべての テーブルに対して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 （EPASで）を使用する場合、準備されたステートメントが実行されると、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 をフィルタリングします。 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 は比較キーと見なされます。

上記のColumn Filter セクションで説明されている、欠落している列、除外または欠落しているテーブルに関する同じ動作は、 Comparison Key .同様に、 Comparison Key セクションは競合モードでは無視されます。

競合フィルター

このセクションでは、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は、タイプがupdate_missing であり、スキーマmy_schema の下のテーブルに関連する競合のみをフェッチします。各PGDノードの競合を照会します。

重要 ：このセクションは--conflicts モード専用であることに注意してください。