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にクエリーをマテリアライズするように指示します（データが具体化されるまで数秒間ハングする場合があります）。したがって、テーブルデータ全体が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カーソルは比較セッション全体でオープントランザクションを必要とするため、このようなインパクトは大きくなります（これは今後のバージョンで廃止されます） 。snapshotは比較セッション全体にわたって保持されるため、ユースケースによっては比較結果が役立つ場合があります。クエリーが具体化されないため、メモリ使用量と一時ファイルの生成は低くなります。非同期データのフェッチは許可されていません。パフォーマンスの観点では、このモードは一般的なユースケースでは遅くなりますが、ラージテーブルの場合は速くなります。データベースのロードが中程度の場合に推奨されます。

重要 ：適切なシナリオに適切なdata_fetch_modeを選択することは非常に重要です。プリペアドステートメントを使用すると、データベースサーバでのフットプリントが最小になるため、最も安全なアプローチであり、一般的なユースケースに適しています。もう1つのポイントは、準備されたステートメントにより、 サーバサイドが常に最新バージョンの行を見ることがデータベースことです。そのため、稼動の高ロードサーバーには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

オラクルに関する注意 ： オラクルの場合、data_fetch_mode設定は完全に無視され、準備されたステートメントやカーソルを使用せずに、LIMITで直接クエリを使用してデータが常にオラクルからフェッチされます。

  • parallel_chunk_rows：分割を検討するために必要な最小行数 並列比較のためにテーブルをマルチプルのチャンクに分割します。フェッチに使用されるハッシュ データなので、労働者は互いに衝突しません。各テーブルチャンクにはこれ以上ありません parallel_chunk_rows行より。任意の値に設定＆lt; 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：LiveCompareが自動的に開始するまでの時間（秒） ユーザがCtrl-cにヒットしたかのように自分自身を停止します。あった比較セッション 中断され、まだ終了していない場合は、セッションを渡すことで再開できます コマンドラインの引数としての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. For example: difference_sources_of_truth = node1、node2。で この例では、セクションnode1 Connectionおよびnode2 Connection .iniファイルまたはall_bdr_nodes = onで定義し、「Initial Connectionis defined, whilenode1andnode2`は有効な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 is defined, while node1 and node2は有効なBDRノードである必要があります 名前。デフォルトでは、接続はタイブレーカーと見なされません。

  • difference_statements：どんな種類のDMLステートメントになるかを制御します LiveCompareによって生成されます。 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：DMLステートメントのオーダーを制御します LiveCompareによって生成されます。 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で適用スクリプトを作成します 修正。設定名前は、 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が使用している場合 主キーとは異なる比較キー、それからLiveCompareはすべてを必要とします ignore_nullableが有効な場合、列はNOT NULLになります（デフォルト）。それは ignore_nullable = offを設定することにより、その動作をオーバーライドできます。 LiveCompareが比較でnull値を許可する列を考慮できるようにします。 コーナーケースは誤検知を引き起こす可能性があります。

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

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

  • oracle_user_tables_only：有効にすると、テーブルをフェッチするようLiveCompareに指示します オラクルのログインユーザからのみのメタデータ。これは、読み取り、 例、sys.user_tablesおよびsys.user_tab_columnsからではなく sys.all_tablesおよびsys.all_tab_columns。デフォルト：off。

  • oracle_fetch_fk_metadata：有効にすると、LiveCompareに外部をフェッチするように指示します キーメタデータ（遅いオペレーションであるかもしれません）。設定の値をオーバーライドします オラクル接続のfetch_fk_metadata。デフォルト：off。

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

  • force_collate：off以外の値と有効な照合順序に設定されている場合 名前、すべてのORDER BY操作で指定された照合順序名前を強制します 比較されるPostgresデータベース。 Postgresデータベースと比較するときに役立ちます 異なる照合順序、またはオラクルデータベースとPostgresデータベースを比較する場合（これで ケースのユーザーはforce_collate = Cを設定する必要があります。比較する場合、値Cを想定します 混在テクノロジー（ オラクルとPostgreSQLなど）、照合順序は指定されていません。 デフォルト：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出力のreplicaとしてのPostgreSQL設定 スクリプト。トリガーとルールの起動を防ぎたい場合に便利です 分岐のあるノードに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は、アルファベット文字で始まる単一単語の文字列です。この場合、ユーザが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： オラクル接続で使用されるサービス名前。デフォルト：XE。

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

  • password：プレーンテキストパスワード。これを使用しないことをお勧めしますが、 レガシー接続が必要になる場合があります。

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

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

  • fetch_fk_metadata：LiveCompareが外部キーに関するメタデータを収集する必要がある場合 接続で。デフォルト：on。

テーブルフィルター

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

特定のテーブルセットに対して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)

重要 ： ノートに設定された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モードはテーブルフィルターを使用しないmakeにノートしてください。

行フィルター

このセクションでは、行レベルフィルターを任意のテーブルに適用できるため、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モードは行フィルターを使用しないmakeにノートしてください。

列フィルター

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

このセクションの下に、行ごとに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およびフィルタリング 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モードは列フィルターを使用しないmakeにノートしてください。

比較キー

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は、update_missing型の競合だけをフェッチし、各BDRノードの競合を照会しながらスキーマmy_schemaの下のテーブルに関連します。

重要 ：このセクションはノートモード専用です。