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`` .. Important:: 各プロセスは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`` カーソルは比較セッション全体でオープンなトランザクションを必要とするため、このような影響はより高くなります。この要件は後のバージョンで解除されます。スナップショットは比較セッション全体で保持されるため、ユースケースによっては、比較結果が役立つ場合があります。クエリは実体化されないため、メモリ使用量と一時ファイルの生成は低いままです。非同期データの取得は許可されていません。パフォーマンスの面では、このモードは一般的なユースケースでは遅くなりますが、大規模なテーブルの場合、このモードの方が速くなる場合があります。データベースの負荷が低〜中程度の場合にお勧めします。 .. Important:: 適切なシナリオに適切な`data_fetch_mode` を選択することは非常に重要です。準備されたステートメントを使用すると、データベースサーバーのフットプリントが最小になるため、最も安全なアプローチであり、一般的なユースケースに適しています。もう1つのポイントは、準備されたステートメントを使用すると、LiveCompareが常に最新バージョンの行を参照できるということですが、これは、ビジー状態のデータベースでサーバーサイドのカーソルを使用している場合には発生しない場合があります。したがって、実稼働の高負荷サーバーには`prepared_statements` を使用し、テスト、移行シナリオ、低負荷サーバーには`server_side_cursors_*` 設定のいずれかを使用することをお勧めします。最良の戦略は、おそらく、非常に大規模なテーブルに`server_side_cursors_without_hold` を使用し、残りのテーブルに`prepared_statements` を混合することです。次の表は、費用/便益比の比較を示しています。 .. csv-table:: :header: "",prepared statements,server side cursors with hold,server side cursors without hold :widths: 15,12,12,20 :align: left :class: longtable 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 .. Note "Note about Oracle":: Oracleの場合、`data_fetch_mode` 設定は完全に無視され、データは常に直接照会を使用してOracleから取得されます。データは、クライアントサイドのカーソルを介して`buffer_size` のチャンクで取得されます。 - ``parallel_chunk_rows`` 並列比較のためにテーブルを複数のチャンクに分割することを検討するために必要な最小行数。データの取得にはハッシュが使用されるため、ワーカーは互いに衝突しません。各テーブルチャンクには\ ``parallel_chunk_rows`` 行以下があります。任意の値<1に設定すると、テーブル分割が無効になります。デフォルト\ ``0`` 無効。 .. Important:: テーブル分割は、複数のワーカーが大きなテーブルを並列比較するのに役立ちますが、各ワーカーのパフォーマンスは、すべての行に適用されるハッシュ条件の影響を受ける可能性があります。 Postgresの構成によっては、特にデフォルトの`random_page_cost = 4` では、最近のハードドライブには保守的すぎると考えられますが、Postgresクエリプランナーは誤ってビットマップヒープスキャンを優先する場合があります。データベースがSSDで実行されている場合、LiveCompareでビットマップヒープスキャンを無効にすると、比較パフォーマンスが大幅に向上します。 `start_query` 設定を使用して、接続ごとにこれを行うことができます。 .. code:: ini 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秒。 .. Important:: **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`` が必要です。 .. Important:: 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`` .. Important:: テーブルに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`` .. Important:: `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`` と同様に、データ接続は名前付けセクションで定義されます。セクション名は\ `` Connection`` の形式であり、 ```` は、英文字で始まる任意の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_`` - ``start_query`` データベースへの接続が開くたびに実行される任意のクエリー。 - ``fetch_fk_metadata`` LiveCompareが接続上の外部キーに関するメタデータを収集するかどうかを指定します。デフォルト\ ``on`` テーブルフィルタ ---------------- ``.ini`` ファイルのこのセクションは、省略するか空のままにした場合、最初のデータベースのすべてのテーブルに対してLiveCompareが実行されることを意味します。 特定のテーブルセットに対してLiveCompareを実行する場合、これを指定するさまざまな方法があります。 - ``publications`` 特定のパブリケーションをフィルタリングできます。LiveCompareは、これらのパブリケーションに関連付けられているテーブルのみを使用します。変数\ ``publication_name`` を使用して、条件式を構築できます。たとえば、 .. code:: ini publications = publication_name = livepub ``logical_replication_mode = native`` が必要です。 - ``replication_sets`` pglogicalまたはPGDを使用する場合、特定のレプリケーションセットをフィルタリングでき、LiveCompareはこれらのレプリケーションセットに関連付けられているテーブルでのみ動作します。変数\ ``set_name`` を使用して、条件式を構築できます。たとえば、 .. code:: ini replication_sets = set_name in (default, bdrgroup) ``logical_replication_mode = pglogical`` または\ ``logical_replication_mode = bdr`` が必要です。 - ``schemas`` 特定のスキーマをフィルタリングでき、LiveCompareはそれらのスキーマに属するテーブルでのみ動作します。変数\ ``schema_name`` を使用して、条件式を構築できます。たとえば、 .. code:: ini schemas = schema_name != badschema - ``tables`` 変数\ ``table_name`` は、LiveCompareで作業するテーブルのみをフィルタリングする条件式を構築するのに役立ちます。例 .. code:: ini 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) .. Important:: `search_path` で設定された2つ以上のスキーマに同じ名前のテーブルが含まれる場合、最初に見つかったもののみが比較の対象となります。 ``Table Filter`` セクションには、\ ``publications`` 、\ ``replication_sets`` 、\ ``schemas`` 、および\ ``tables`` フィルターを組み合わせることができます。 LiveCompareは、指定したすべてのフィルタの交差部分にあるテーブルのセットを検討します。例 .. code:: ini [Table Filter] publications = publication_name = livepub replication_sets = set_name in (default, bdrgroup) schemas = schema_name != badschema tables = table_name not like %%account テーブルフィルタは、最初にデータベースに適用されてテーブルリストを構築します。テーブルが最初のデータベースに存在し、フィルタで検討されているが、他のデータベースに存在しない場合、次のようなものがログに追加され、その特定のテーブルの比較がスキップされます。 .. code:: text 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は、両方のテーブルでデータ型または制約が同じであるかどうかをチェックしません。 .. Important:: `conflicts` モードはテーブルフィルターを利用しません。 行フィルタ ---------- このセクションでは、行レベルのフィルタを任意のテーブルに適用できるため、LiveCompareは行フィルタを満たす行にのみ機能します。 このセクションの下に、テーブルのリストを1行に1テーブルずつ書くことができます。 ``schema_qualified_table_names`` が無効になっていない限り、すべてのテーブル名はスキーマ修飾されている必要があります。例 .. code:: ini [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`` によってフィルタリングされている場合、このテーブルの行フィルタはサイレントに無視されます。 .. Important:: `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`` があるとします。 .. code:: ini [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`` によってフィルタリングされている場合、このテーブルの列フィルタはサイレントに無視されます。 .. Important:: `Column Filter` で指定された列がテーブルPKの一部である場合、比較で無視されません。 LiveCompareはそれをログに記録し、このような列のフィルターを無視します。 .. Important:: `conflicts` モードは列フィルターを利用しません。 比較キー -------- .. Tip "New feature":: LiveCompare比較キーのサポートは、LiveCompareバージョン2.0以降で利用できます。 !!! ``Column Filter`` と同様に、このセクションでは、テーブルごとに列のリストを指定することもできます。これらの列は、テーブルに主キーまたは\ ``UNIQUE`` 制約がある場合でも、特定のテーブルの比較キーとして考えられます。 例 .. code:: ini [Comparison Key] public.table1 = col_a, col_b public.table2 = c1, c2 この例では、テーブル\ ``public.table1`` の場合、比較キーは列\ ``col_a`` および\ ``col_b`` です。テーブル\ ``public.table2`` の場合、列\ ``c1`` および\ ``c2`` は比較キーとして考慮されます。 :ref:`列フィルタ <列フィルタ>` で説明している欠落している列、またはフィルタリングまたは欠落しているテーブルに関する同じ動作も、比較キーに適用されます。同様に、 ``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`` の下のテーブルに関連する競合のみを取得します。 .. Important:: このセクションは`--conflicts` モード専用です。