Filter Settings#
テーブルフィルタ#
.ini
ファイルのこのセクションは、省略するか空のままにした場合、最初のデータベースのすべてのテーブルに対してLiveCompareが実行されることを意味します。
特定のテーブルセットに対してLiveCompareを実行する場合、これを指定するさまざまな方法があります。
出版物#
特定のパブリケーションをフィルタリングできます。LiveCompareは、それらのパブリケーションに関連付けられているテーブルのみを使用します。変数publication_name
を使用して、条件式を構築できます。たとえば、
publications = publication_name = livepub
logical_replication_mode = native が必要です。
replication_sets#
pglogicalまたはPGDを使用する場合、特定のレプリケーションセットをフィルタリングでき、LiveCompareはこれらのレプリケーションセットに関連付けられたテーブルでのみ動作します。変数set_name
を使用して、条件式を構築できます。たとえば、
replication_sets = set_name in (default, bdrgroup)
logical_replication_mode = pglogical
またはlogical_replication_mode = bdr が必要です。
スキーマ#
特定のスキーマをフィルタリングできます。LiveCompareは、それらのスキーマに属するテーブルでのみ動作します。変数schema_name
を使用して、条件式を構築できます。たとえば、
schemas = schema_name != badschema
テーブル#
変数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に設定すると、クエリが実行されるテーブル比較の先頭にのみRow Filterが適用されます。これは、サーバーサイドのカーソルを使用してデータを取得すると、データが比較の開始時の状態のスナップショットとして表示されることを意味します。Postgresでは、
data_fetch_modeをprepared_statementsデフォルトに設定すると、準備されたクエリーにRow Filterが含まれ、取得されるすべてのデータバッファーで実行されます。これは、クエリがRow Filterでnow()、CURRENT_TIMESTAMP、またはSYSDATEEDB 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
があるとします。
[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
によってフィルタリングされている場合、このテーブルの列フィルタはサイレントに無視されます。
重要
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 は比較キーとして考慮されます。
列フィルタ で説明している欠落している列、またはフィルタリングまたは欠落しているテーブルに関する同じ動作も、比較キーに適用されます。同様に、
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
の下のテーブルに関連する競合のみを取得します。
重要
このセクションは`--conflicts` モード専用です。