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（デフォルトでは10000000にデフォルト）を使用することで軽減でき、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はテーブルを無効にします 分割。接続がPostgreSQLでない場合、テーブル分割は LiveCompareによって自動的に無効になります。デフォルト：10000000。

  • 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 that's 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_round_saves：それぞれを更新前に待機する時間（秒） 比較アルゴリズムが進行中のラウンド状態。に注意してください ラウンドが終了すると、LiveCompareは常にそのテーブルのラウンド状態を更新します。 デフォルト：60秒。

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

  • 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では、ローカルのみのトランザクションの適用に使用される新しいpre-createdbdr_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カラムを区別することはできません。

  • 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_namesettingのみを使用してデータ接続を設定している場合、ノード名から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と同様に、「dataconnection」は名前付けセクションで定義されます。セクション名前は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 orlogical_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を無効にしている場合は、connectionstart_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を無効にしている場合は、connectionstart_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行に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、 フィルタリングおよびcolumn5でのみ機能し、column1およびcolumn3を除外しますが、表public.table2では、列column2、 フィルタリング 、beおよびcolumn5。

一般設定schema_qualified_table_namesを無効にしている場合は、connectionstart_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にノートしてください。

競合フィルター

このセクションでは、 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の下のテーブルに関連します。

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