General 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サイドディスクに保存できます。 ``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`` ~~ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LiveCompare 3.0で削除されました。この設定が\ ``.ini`` ファイルに存在する場合、LiveCompare 3.0でファイルを使用する前に削除します。 repair_data_fetch ^^^^^^^^^^^^^^^^^ データの取得を並列的に実行するかどうか、つまり、データベースへの非同期接続を使用するかどうかを指定します。多方向比較のパフォーマンスが向上します。 PostgreSQLではないデータ接続がある場合、この設定は自動的に無効になります。これは、 data_fetch_mode = stable_statementsまたはdata_fetch_mode = server_side_cursors_with_holdの場合にのみ許可されます。デフォルトオン。 ``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はラウンドの状態が保存されたポイントからそのテーブルのラウンドを再開します。 repair_cost_limit ^^^^^^^^^^^^^^^^^ 0の場合、comparison_cost_migrate秒の昼寝をする前に各ワーカーが処理する行数に対応します。デフォルト0は、各ワーカーが昼寝をせずに行を処理することを意味します。 repair_cost_deploy ^^^^^^^^^^^^^^^^^^ repair_cost_limit > 0の場合、この設定は各ワーカーのスリープ時間を指定します。デフォルト0.0 stop_after_time ^^^^^^^^^^^^^^^ **Ctrl-C** を押したかのようにLiveCompareが停止する秒単位の時間。コマンドラインの引数としてセッションIDを渡すことにより、中断された比較セッションがまだ終了していない場合は再開できます。デフォルトstop_after_time = 0、これは、自動中断が無効であることを意味します。 consensus_mode ^^^^^^^^^^^^^^ LiveCompareがどのデータ接続が発散しているかを判断するために使用されるコンセンサスアルゴリズム。指定できる値は、off、simple_majority、quorum_based、またはsource_of_truthです。 consensus_mode =source_of_truthの場合、difference_sources_of_truthを埋める必要があります。デフォルトsimple_majority。 .. Note:: `consensus_mode = off` および`comparison_algorithm = block_hash` の場合、LiveCompareはより詳細な比較アルゴリズムに切り替えません。これにより、特定のテーブルで発散が見つかった場合のパフォーマンスが大幅に向上しますが、どの行が発散しているかに関する情報が不足します。その後、ユーザーはLiveCompareを再度実行して発散テーブルがある場合を`[Table Filter]` に追加し、発散テーブルのみを比較して、どの行が発散しているかに関する情報を取得できます。 destination_required_quorum ^^^^^^^^^^^^^^^^^^^^^^^^^^^ consensus_mode = quorum_basedの場合、この設定は、どの接続が発散しているかを決定するために必要な最小クォーラムを指定します。 0.0〜1.0の数値である必要があります。 0.0は接続が必要ないことを意味し、1.0はすべての接続が必要であることを意味します。どちらの場合も極端であるため、使用をお勧めしません。デフォルト値は0.5であり、それに近い値を使用することをお勧めします。 destinations_of_truth ^^^^^^^^^^^^^^^^^^^^^ 真のソースとして検討する接続名またはノード名、logical_replication_mode = bdrおよびall_bdr_nodes = onの場合、コンマ区切りのリスト。これは、consensus_mode =source_of_truthの場合にのみ使用されます。例えば destinations_of_truth = node1,node2。この例では、.iniファイルでセクションnode1 Connectionおよびnode2 Connectionを定義するか、 all_bdr_nodes = onで初期接続のみが定義されますが、 node1およびnode2は有効なPGDノード名である必要があります。 destination_tie_migrates ^^^^^^^^^^^^^^^^^^^^^^^^ コンセンサスアルゴリズムがタイブレーカーとして考慮される接続名またはノード名、logical_replication_mode = bdrおよびall_bdr_nodes = onの場合は、タイブレーカーとして考えられます。コンセンサスアルゴリズムがタイ状況を見つけた場合。次に例を示します。この例では、.iniファイルでセクションnode1 Connectionおよびnode2 Connectionsを定義するか、 all_bdr_nodes = onで初期接続のみが定義されますが、 node1およびnode2は有効なPGDノード名である必要があります。デフォルト 接続をタイブレーカーとして考慮しません。 destination_statements ^^^^^^^^^^^^^^^^^^^^^^ LiveCompareが生成するDMLステートメントの種類を制御します。 destination_statementsの値は、次のいずれかです。 - ``all`` デフォルト - ``inserts`` - ``updates`` - ``deletes`` - ``inserts_updates`` - ``inserts_deletes`` - ``updates_deletes`` destination_allow_null_updates ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ UPDATE SET Col = NULLのようなコマンドを差分レポートで許可するかどうかを決定します。 デフォルトオン。 destination_statement_order ^^^^^^^^^^^^^^^^^^^^^^^^^^^ LiveCompareが生成するDMLステートメントの順序を制御します。 frequency_statement_orderの値は、次のいずれかです。 - ``delete_insert_update`` - ``delete_update_insert`` デフォルト - ``insert_update_delete`` - ``insert_delete_update`` - ``update_insert_delete`` - ``update_delete_insert`` destination_fix_replication_origin ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ PGDデータベースを使用する場合、差分のために、LiveCompareは特定のレプリケーションオリジンがまだ存在しない場合は作成します。次に、レプリケーションオリジンを使用して、DML修正を含む適用スクリプトを作成します。 frequency_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に接続されている場合、このレプリケーションオリジンは作成されないため、このレプリケーションオリジンを削除しないことをお勧めします。 destination_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 ^^^^^^^^^^^^^^^^^^ コンソール出力に進行状況バーを表示するかどうかを決定します。この設定を無効にすると、バッチ実行に役立つ場合があります。 デフォルトオン。 Output_schema ^^^^^^^^^^^^^ 出力接続で、比較レポートテーブルが作成されるスキーマ。 デフォルトlivecompare。 hash_column_name ^^^^^^^^^^^^^^^^ すべてのデータの取得には、行内のすべての実際の列のハッシュである特定の列が含まれます。この設定は、この列の名前を指定します。 デフォルトlivecompare_hash。 rownumber_column_name ^^^^^^^^^^^^^^^^^^^^^ 一部の取得では、クエリ列内でrow_number()ファンクション値を使用する必要があります。この設定は、この列の名前を指定します。デフォルトlivecompare_rownumber。 fetch_row_origin ^^^^^^^^^^^^^^^^ この設定が有効になっている場合、LiveCompareは各発散行のオリジン名を取得します。これは、デバッグの目的で役立つ場合があります。有効にするには、logical_replication_modeをpglogicalまたはbdrに設定する必要があります。デフォルトオフ。 column_intersection ^^^^^^^^^^^^^^^^^^^ この設定が有効になっている場合、比較される特定のテーブルについて、LiveCompareはすべての接続でテーブルの列の交差点でのみ動作し、接続に存在する可能性のある追加の列を無視します。この設定が無効になっている場合、LiveCompareは、すべての接続のテーブルで列が同等であるかどうかを確認し、列の不一致がある場合はテーブルの比較を中止します。デフォルトオフ。 .. Important:: テーブルにPKがある場合、 `column_intersection = on` であっても、PK列は異なることはできません。 ignore_nullable ^^^^^^^^^^^^^^^ 特定のテーブル比較では、LiveCompareが主キーとは異なる比較キーを使用している場合、ignore_nullableが有効になっているデフォルトの場合、LiveCompareではすべての列が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から読み取るため、高速です。 デフォルトオフ。 oracle_fetch_fk_metadata ^^^^^^^^^^^^^^^^^^^^^^^^ 有効にすると、外部キーメタデータを取得するようにLiveCompareに指示します。これは、低速な操作になる場合があります。 Oracle接続のfetch_fk_metadata設定の値をオーバーライドします。 デフォルトオフ。 schema_qualified_table_names ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ この設定が有効になっている場合、テーブル名はスキーマ修飾されたものとして扱われます。これを無効にすると、スキーマ修飾テーブル名を使用せずにテーブルを比較できます。 Oracle x Postgresの比較では、 oracle_user_tables_onlyを有効にすることも必要です。 Postgres x Postgresでは、同じデータベース内でも、異なるスキーマの下にあるテーブルの比較ができます。また、 schema_qualified_table_namesが有効になっている場合、テーブルフィルタ->テーブル、行フィルタ、および列フィルタでは、スキーマ名のないテーブル名が許可されます。 デフォルトオン。 ~~\ ``force_collate`` ~~ ^^^^^^^^^^^^^^^^^^^^^^^^ LiveCompare 3.0で削除されました。この設定が\ ``.ini`` ファイルに存在する場合、LiveCompare 3.0でファイルを使用する前に削除します。 work_directory ^^^^^^^^^^^^^^ LiveCompare作業ディレクトリへのパス。出力ファイルを含むセッションフォルダーがこのディレクトリに作成されます。 デフォルト(現在のディレクトリ)。 abort_on_setup_error ^^^^^^^^^^^^^^^^^^^^ 有効にすると、テーブル比較ラウンドを設定しようとしたときにLiveCompareがエラーを発生すると、比較セッション全体が中止されます。 デフォルトオフ。 .. 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設定を出力適用スクリプトのレプリカとして使用します。これは、発散があるノードでDMLを適用しているときにトリガーとルールが起動されないようにしたい場合に役立ちます。これを有効にするには、PostgreSQLのスーパーユーザーが必要です。それ以外の場合、効果はありません。 デフォルトオフ。 Split_updates ^^^^^^^^^^^^^ 有効にすると、LiveCompareはUPDATE発散を分割します。つまり、 UPDATE DMLを生成する代わりに、適用スクリプトで対応するDELETEおよびINSERTを生成します。 デフォルトオフ。 float_point_round ^^^^^^^^^^^^^^^^^ データベースからの浮動小数点値を比較するときにLiveCompareが丸める10進数を指定する整数 デフォルト-1、浮動小数点の四捨五入を無効にします。