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 BDR 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にアクティブなBDRノードの現在のリストに基づいて接続リストを構築させることができます。デフォルト：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に指示します（ワーカーはデータがマテリアライズされるまで数秒間ハングする場合があります）。その影響はすべて 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 は有効なBDRノード名である必要があります。

  • 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 は有効なBDRノード名である必要があります。デフォルトでは、接続はタイブレーカーと見なされません。

  • 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 ： BDRデータベースを使用する場合、違いのためにLiveCompareは特定のレプリケーション起点がまだ存在しない場合は作成し、そのレプリケーション起点を使用してDML修正を含む適用スクリプトを作成します。設定difference_fix_replication_origin は、LiveCompareが使用する複製起点の名前を指定します。ユーザーがこの設定に値を設定しない場合、LiveCompareは自動的にdifference_fix_replication_origin = bdr_local_only_origin を設定します。 LiveCompareが作成するレプリケーションオリジンは、比較後の検証を許可するために削除されないことに注意してくださいが、必要に応じて、レプリケーションオリジンを後で手動で削除できます。 logical_replication_mode = bdr が必要です。

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

・ difference_fix_start_query ：LiveCompareで生成された適用スクリプトの先頭で実行される任意のクエリ。さらに、 BDR比較が実行されており、 difference_fix_start_query が空の場合、 LiveCompare は自動的に次のことも行います。

- If the divergent connection is BDR 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 からBDRメタデータを取得してデータ接続リストを構築するため、ユーザーはデータ接続を指定する必要はありません。

  • 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またはBDRを使用する場合、特定の複製セットをフィルタリングでき、 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 に設定すると、クエリが実行されたときにテーブル比較の先頭にのみ適用されます。これは、サーバー側のカーソルを使用してデータを取得することを意味します。

  • 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 を除外します。一方、テーブルpublic.table2 の場合、列column2 、edb_tran 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 セクションは競合モードでは無視されます。

競合フィルター

このセクションでは、 BDRノードから競合を取得するときに--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は、各BDRノードで競合を照会中に、タイプがupdate_missing であり、スキーマmy_schema の下のテーブルに関連する競合のみを取得します。

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