すべてのプロダクト
Search
ドキュメントセンター

ApsaraDB for OceanBase (Deprecated):一致ルールの構成と変更

最終更新日:Dec 30, 2025

このトピックでは、移行または同期オブジェクトの一致ルールの構成と変更に関する背景情報、制限事項、手順、シナリオ、およびトラブルシューティングのヒントについて説明します。

背景

データ移行タスクまたはデータ同期タスクを作成する場合は、移行または同期するオブジェクトを指定する必要があります。データ伝送サービスでは、オブジェクトを直接指定したり、オブジェクトをインポートしたり、オブジェクトの一致ルールを構成したりできます。ワイルドカードベースの一致ルールを構成して、移行または同期オブジェクトを指定および変更できます。ソースとターゲット間のオブジェクトマッピングロジックを構成することもできます。これにより、シンプルかつ効率的な方法で移行または同期する多数のオブジェクトを指定できます。一致ルールを満たす新しいテーブルは、増分同期の DDL 操作によってターゲットに自動的に同期できます。詳細については、「同期と制限事項でサポートされている DDL 操作」をご参照ください。

データベース間のデータ移行/同期のためのワイルドカードパターン

次の表に、データベース間のデータ移行/同期のためにデータ伝送サービスでサポートされているワイルドカードパターンを示します。

説明
  • 次の表では、アスタリスク(*)はワイルドカードを示します。

  • 双方向同期タスクでは、データベースまたはテーブルの集約はサポートされていません。

カテゴリ

サポートされているルール

説明

オブジェクトの直接移行

*.*

kd_test*.person*

名前が kd_test で始まるすべてのデータベース内の、名前が person で始まるすべてのテーブルが、ソースからターゲットに移行されます。ソースデータベース名とテーブル名は変更されません。

*.<ソーステーブル>

kd_test*.person

名前が kd_test で始まるすべてのデータベース内の、person という名前のすべてのテーブルが、ソースからターゲットに移行されます。ソースデータベース名とテーブル名は変更されません。

<ソースデータベース>.*

kd_test.person*

kd_test という名前のデータベース内の、名前が person で始まるすべてのテーブルが、ソースからターゲットに移行されます。ソースデータベース名とテーブル名は変更されません。

<ソースデータベース>.<ソーステーブル>

kd_test.person

kd_test という名前のデータベース内の、person という名前のテーブルが、ソースからターゲットに移行されます。ソースデータベース名とテーブル名は変更されません。

移行後のオブジェクトの名前変更

<ソースデータベース>.<ソーステーブル>=<ターゲットデータベース>.<ターゲットテーブル>

kd_test.person=kd_test_new.person_new

kd_test という名前のデータベース内の、person という名前のテーブルが、ソースからターゲットに移行されます。 kd_test データベースは kd_test_new に名前が変更され、person テーブルは person_new に名前が変更されます。

<ソースデータベース>.*=<ターゲットデータベース>.*

kd_test.person*=kd_test_new.person*

kd_test という名前のデータベース内の、名前が person で始まるすべてのテーブルが、ソースからターゲットに移行されます。 kd_test データベースは kd_test_new に名前が変更され、ソーステーブル名は変更されません。

*.<ソーステーブル>=*.<ターゲットテーブル>

kd_test*.person=kd_test*.person_new

名前が kd_test で始まるすべてのデータベース内の、person という名前のすべてのテーブルが、ソースからターゲットに移行されます。テーブル名は person_new に変更され、ソースデータベース名は変更されません。

オブジェクトの集約

<ソースデータベース>.*=<ターゲットデータベース>.<ターゲットテーブル>

kd_test.person*=kd_test.person_all

ソースの kd_test という名前のデータベース内の、名前が person で始まるすべてのテーブルが、ターゲットの kd_test データベース内の person_all テーブルに集約されます。

*.<ソーステーブル>=<ターゲットデータベース>.<ターゲットテーブル>

kd_test*.person=kd_test_all.person

ソースの、名前が kd_test で始まるすべてのデータベース内の、person という名前のすべてのテーブルが、ターゲットの kd_test_all データベース内の person テーブルに集約されます。

*.*=<ターゲットデータベース>.<ターゲットテーブル>

kd_test*.person*=kd_test_all.person_all

ソースの、名前が kd_test で始まるすべてのデータベース内の、名前が person で始まるすべてのテーブルが、ターゲットの kd_test_all データベース内の person_all テーブルに集約されます。

*.*=<ターゲットデータベース>.*

kd_test*.person*=kd_test_all.person*

ソースの、名前が kd_test で始まるすべてのデータベース内の、名前が person で始まるすべてのテーブルが、ターゲットの kd_test_all データベースに集約されます。ソーステーブル名は変更されません。

*.*=*.<ターゲットテーブル>

kd_test*.person*=kd_test*.person_all

ソースの、名前が kd_test で始まるすべてのデータベース内の、名前が person で始まるすべてのテーブルが、ターゲットの、名前が kd_test で始まるデータベース内の person_all テーブルに集約されます。ソースデータベース名は変更されません。

一致ルールの要件は次のとおりです。

  • ターゲットのデータベース名とテーブル名の両方にワイルドカードを使用することはできません。例:kd_test*.person*=kd_test*.person*

  • ソースとターゲットの両方のデータベースにワイルドカードを使用する場合、データベースの式はソースとターゲットで同じでなければならず、これはデータベースの直接移行を示します。

  • ソースとターゲットの両方のテーブルにワイルドカードを使用する場合、テーブルの式はソースとターゲットで同じでなければならず、これはテーブルの直接移行を示します。

  • ターゲットでデータベースにワイルドカードを使用する場合は、ソースのデータベースにもワイルドカードを使用する必要があります。

  • ターゲットでテーブルにワイルドカードを使用する場合は、ソースのテーブルにもワイルドカードを使用する必要があります。

データベースと Message Queue インスタンス間のデータ移行/同期のためのワイルドカードパターン

次の表に、データベースと Message Queue インスタンス間のデータ移行/同期のためにデータ伝送サービスでサポートされているワイルドカードパターンを示します。

説明

次の表では、アスタリスク(*)はワイルドカードを示します。

サポートされているルール

説明

*.*=<トピック名>

*.*=topic

複数のデータベース内の複数のテーブルが 1 つのトピックにマッピングされます。

*.<ソーステーブル>=<トピック名>

*.b=topic

複数のデータベース内の b という名前のテーブルが 1 つのトピックにマッピングされます。

<ソースデータベース>.*=<トピック名>

a.*=topic

データベース a 内の複数のテーブルが 1 つのトピックにマッピングされます。

<ソースデータベース>.<ソーステーブル>=<トピック名>

a.b=topic

データベース a 内のテーブル b がトピックにマッピングされます。

制限事項

  • データ伝送サービスでは複数のルールがサポートされています。各ルールは 1 行に配置し、先頭または末尾にスペースを入れないでください。

  • 移行または同期オブジェクトの一致ルールは空にできません。オブジェクト除外ルールは空にできます。

  • スキーマ移行および完全移行中は、変更のための DDL 操作はサポートされていません。

  • 一致ルールを構成して移行または同期オブジェクトを選択する場合、テーブル名に改行、スペース、または特殊文字を含めることはできません。特殊文字は . | " ' ` ( ) = ; / & \ * ? [ ] [ ! ] です。

  • ソースの同じデータベース内の異なるテーブルをターゲットの異なるデータベースにマッピングする複数のマッチングルールを設定することは許可されていません。例:a.a* = b.a* & a.b* = c.b*

  • データベースまたはテーブルの集約シナリオでは、逆方向増分はサポートされていません。

    説明

    データ転送サービスは、データ移行タスクまたはデータ同期タスクが保存または開始されるときにのみ、データベースまたはテーブルの集約が存在するかどうかをチェックします。タスクの実行中に発生するデータベースまたはテーブルの集約はブロックしません。ただし、逆方向増分中にデータベースまたはテーブル間のマッピングが正しく識別されず、データ品質が損なわれる可能性があります。

  • 現在、データ伝送サービスは DDL 文 CREATE DATABASE をサポートしていません。ソースで作成された新しいデータベースがオブジェクト一致ルールを満たしている場合は、ターゲットで対応するデータベースを手動で作成して、新しいデータベースのデータ同期を続行する必要があります。

考慮事項

  • オブジェクト一致ルールと除外ルールを構成した後、オブジェクト一致ルールと除外ルールの差集合内にあるオブジェクトを選択できます。

    説明

    2 つの集合間の差集合には、一方の集合に存在するが、もう一方の集合には存在しないすべての要素が含まれます。

  • DDL 同期が有効になっている場合、DDL 文を使用してソースで新しいテーブルを作成したり、テーブルのスキーマを変更したりするときに、テーブルがオブジェクト一致ルールと除外ルールの差集合内にある場合、この DDL 文はデータ伝送サービスによってターゲットに同期できます。

  • 複数のテーブルを集約する場合は、次の考慮事項に注意してください。

    • マッチングルールを指定して、ソースとターゲット間のマッピングを設定することを推奨します。

    • ターゲットでスキーマを手動で作成することをお勧めします。データ伝送サービスを使用してスキーマを作成する場合は、スキーマ移行ステップで失敗したオブジェクトをスキップします。

    • [DDL 同期] を選択した場合、データベースまたはテーブルが誤って削除される可能性があります。たとえば、ソース側の複数のデータベースやテーブルをターゲット側の単一のデータベースやテーブルに集約する場合、ソース側でデータベースやテーブルが削除されると、ターゲット側で集約後のデータベースやテーブルが削除される可能性があります。

    • データ移行タスクを作成するときは、[フル移行] をクリックし、[ターゲットデータベース内の空でないテーブルの処理][無視] を選択します。

      説明

      [無視] を選択すると、完全検証のために IN モードでデータがプルされます。この場合、ターゲットにソースに存在しないデータが含まれていると検証は適用されず、検証のパフォーマンスが低下します。

  • テーブルに名前変更マッピングルールが設定されている場合、名前変更マッピングルールが優先されます。たとえば、ルール a.b[0-3]a.b[3-5]=a.c が設定されている場合、a.b3 テーブルは a.c に名前が変更されます。

  • DDL 文 RENAME TABLE を実行するときに、名前が変更されたテーブルが元の一致ルールまたは除外ルールを満たしていない場合、予期しない同期の問題が発生する可能性があります。注意して進めてください。

データベース間の一致ルールの構成

  1. [移行オブジェクトの選択] または [同期オブジェクトの選択] に進む前に、データ移行または同期タスクの手順を完了します。

    詳細については、対応するデータソースタイプのデータ移行またはデータ同期タスクに関するトピックをご参照ください。

    説明
  2. [移行オブジェクトの選択] セクションで、[一致ルール] を選択します。

    image

  3. [移行範囲の指定] セクションで、[オブジェクト移行ルール][オブジェクト除外ルール] (オプション) を指定します。 詳細については、「ワイルドカードルール」をご参照ください。

    説明

    設定されたルールにスペースが含まれている場合、オブジェクトの移行または同期プロジェクトが失敗する可能性があります。

  4. [検証] をクリックします。

    一致する結果を表示するには、検証が成功した後、[プレビュー] オブジェクト をクリックします。ワイルドカードベースの一致ルールと除外ルールは、テーブルとビューに適用されます。[最終オブジェクト]新規オブジェクト、および削除済みオブジェクトタブに一致結果が表示されます。

    タブ

    説明

    最終オブジェクト

    指定された一致ルールにヒットした移行オブジェクトが表示されます。

    新しいオブジェクト

    以前の一致の結果にない移行オブジェクトが表示されます。

    削除されたオブジェクト

    以前の一致の結果にのみ含まれる移行オブジェクトが表示されます。

    移行または同期オブジェクトを選択するための一致ルールを構成した後、フィルタリング条件を設定できます。

    image

    1. [一致結果] > [最終オブジェクト] を選択し、ポインターを対象のテーブルオブジェクトの上に移動します。

    2. [設定] をクリックします。

    3. 設定ダイアログボックスで、標準 SQL の WHERE 句を指定して、行単位でデータをフィルターします。次に、[構文の検証] をクリックします。詳細については、「SQL 条件を使用してデータをフィルターする」をご参照ください。

    4. 構文検証に合格したら、[OK] をクリックします。

      [列の表示] セクションで、移行オブジェクトの列情報を表示することもできます。

  5. プロンプトに従って後続のタスク設定を完了します。

サンプルシナリオ

  • オブジェクトの直接移行

    ソースの、名前が jenkins_api で始まるすべてのデータベース内の、名前が test で始まるすべてのテーブルをターゲットに移行し、元のデータベース名とテーブル名を保持します。これを行うには、次の図に示すように一致ルールを構成します。

    image.png

  • 移行後のオブジェクトの名前変更

    ソースの jenkins_my2dh_one という名前のデータベース内の、名前が test で始まるすべてのテーブルをターゲットに移行し、jenkins_my2dh_one データベースの名前を jenkins_my2dh_one_new に変更し、元のテーブル名を保持します。これを行うには、次の図に示すように一致ルールを構成します。

    image.png

  • オブジェクトの集約

    ソースの、名前が jenkins_api で始まるすべてのデータベース内の、名前が order で始まるすべてのテーブルを、ターゲットの jenkins_api_all データベース内の order テーブルに集約します。これを行うには、次の図に示すように一致ルールを構成します。

    截屏2023-12-04 18.33.49.png

  • オブジェクト除外ルールの構成

    ソースの jenkins_api_mysql56 データベース内の、名前が history_ で始まる履歴テーブルと、名前が log で終わるログテーブルを移行から除外します。これを行うには、次の図に示すように一致ルールを構成します。

    image.png

データベース間の一致ルールの変更

ルールの説明

  • 逆方向増分フェーズのデータ移行タスクに移行オブジェクトを追加することはできません。

  • PolarDB-O データベースから Oracle 互換モードの OceanBase データベースにデータを移行する場合、移行オブジェクトを追加することはできません。

  • 次の表に、一致ルールを変更できるシナリオを示します。

    データ移行フェーズ

    移行タスクのステータス

    フェーズのステータス

    /

    開始されていません

    /

    完全移行

    実行中

    実行中

    失敗

    失敗

    停止

    停止

    増分同期/逆方向増分

    実行中

    実行中

    実行中

    監視中

    失敗

    失敗

    停止

    停止

手順

  1. [オブジェクトの表示] ダイアログボックスに移動します。

    1. ApsaraDB for OceanBase コンソールにログインします。

    2. 左側のナビゲーションウィンドウで、[データ転送] > [データ移行] を選択します。

    3. [データ移行] ページで、対象のタスクの名前をクリックして詳細ページに移動します。

      image.png

    4. 右上隅にある [オブジェクトの表示] をクリックします。移行オブジェクトと変更レコードが表示されます。

  2. [オブジェクトの表示] ダイアログボックスの右下隅にある [ルールの変更] をクリックします。

    image

  3. [ルールの変更] ダイアログボックスで、移行オブジェクトの一致ルールを変更して、オブジェクトを追加または削除します。

  4. [検証] をクリックします。一致結果を表示するには、検証が成功した後に [オブジェクトのプレビュー] をクリックします。

    新しいオブジェクトにポインターを合わせ、表示される [構成] をクリックして、このオブジェクトのフィルター条件を構成できます。

    image

  5. [次へ] をクリックします。

    • オブジェクトを追加すると、システムはこれらのオブジェクトに対して事前チェックを実行します。

    • オブジェクトを削除すると、削除されるオブジェクトの数が表示されます。

  6. 事前チェックが成功するか、削除するオブジェクトの数を確認したら、[送信] をクリックします。

オブジェクトの変更が実行された後、[オブジェクトの表示] をページの右上隅でクリックし、[変更履歴] をクリックして変更履歴と詳細を表示できます。

image

データベースからメッセージキューインスタンスへのデータ移行/同期の照合ルールの構成

OceanBase データベースから DataHub、Kafka、または RocketMQ インスタンスにデータを同期する場合、マッチングルールを設定して同期するオブジェクトを選択できます。

  1. データ同期タスクを作成し、指示に従って[同期対象の選択]ステップに進みます。

    詳細については、対応するデータソースタイプのデータ同期タスクに関するトピックをご参照ください。

  2. [同期オブジェクトの選択] セクションで、[照合ルール] を選択します。

    image

  3. [オブジェクト同期ルール] および [オブジェクト除外ルール] (任意) を指定します。 詳細については、「照合ルールでサポートされているワイルドカード パターン」をご参照ください。

    照合ルールを構成する場合、ビジネスロジックはデータ同期タスクのタイプによって異なります。

    • ターゲットが DataHub インスタンスの場合、トピックタイプは Tuple または BLOB にすることができます。

      • Tuple タイプの場合、ワイルドカードまたはスペースを含まない既存のトピック名のみを入力できます。テーブルを選択すると、それらは 1 対 1 の方法でトピックにマッピングされます。

      • BLOB タイプの場合、多対 1 および 1 対 1 のマッピング方法がサポートされており、スペースは使用できません。

        同期タイプを指定したときに [スキーマ同期] を選択した場合は、既存のトピックの名前を入力するか、新しいトピックを作成するかを選択できます。1 つのマッピング方法のみがサポートされています。トピックの作成または選択には、1 つのマッピング方法のみを選択できます。同期タイプを指定したときに [スキーマ同期] を選択しなかった場合は、既存のトピックの名前のみを入力できます。

    • ターゲットが Kafka または RocketMQ インスタンスの場合、多対 1 および 1 対 1 のマッピング方法がサポートされており、スペースは使用できません。

      同期タイプを指定したときに [スキーマ同期] を選択した場合は、既存のトピックの名前を入力するか、新しいトピックを作成するかを選択できます。同期タイプを指定したときに [スキーマ同期] を選択しなかった場合は、既存のトピックの名前のみを入力できます。

  4. [検証] をクリックします。

    検証が成功したら、[プレビュー] オブジェクトをクリックして、一致する結果を表示します。一致する結果は、[最終オブジェクト]新規オブジェクト、および削除済みオブジェクトタブに表示されます。

    照合ルールを構成して同期オブジェクトを選択した後、フィルタリング条件を設定できます。

    image

    1. [照合結果] > [最終オブジェクト] を選択し、対象のテーブルオブジェクトにポインターを合わせます。

    2. [設定] をクリックします。

    3. [設定] ダイアログボックスでは、次の操作を実行できます。

      • [行フィルター] セクションで、標準 SQL の WHERE 句を指定して行でデータをフィルターします。 次に、[構文を検証] をクリックします。 詳細については、「SQL 条件を使用してデータをフィルターする」をご参照ください。

      • [シャーディング列] ドロップダウンリストから、使用するシャーディング列を選択します。複数のフィールドをシャーディング列として選択できます。このパラメーターはオプションです。

        特に指定がない限り、プライマリキーをシャーディング列として選択します。プライマリキーの負荷が分散されていない場合は、パフォーマンスの問題を回避するために、一意の識別子を持つ負荷分散フィールドをシャーディング列として選択します。シャーディング列は、次の目的で使用できます。

        • 負荷分散: ターゲットテーブルが同時書き込みをサポートしている場合、メッセージの送信に使用されるスレッドは、シャーディング列に基づいて認識できます。

        • 順序性: データ転送サービスは、シャーディング列の値が同じであれば、メッセージが順番に受信されることを保証します。順序性は、列に対して DML 文を実行する順序を指定します。

      • [列の選択] セクションで、同期する列を選択します。詳細については、「列フィルタリング」をご参照ください。

    4. [OK] をクリックします。

  5. 指示に従って後続のタスク設定を完了します。

データベースからメッセージキューインスタンスへのデータ移行/同期の照合ルールを変更する

  1. [オブジェクトの表示] ダイアログボックスに移動します。

    1. ログインします。

      ApsaraDB for OceanBase コンソールにログインします。

    2. 左側のナビゲーションウィンドウで、[データ伝送] > [データ同期] を選択します。

    3. [データ同期] ページで、ターゲットタスクの名前をクリックして詳細ページに移動します。

      image.png

    4. 右上隅にある [オブジェクトの表示] をクリックします。同期オブジェクトと変更レコードが表示されます。

  2. [オブジェクトの表示] ダイアログボックスで、右下隅にある [ルールの変更] をクリックします。

    image

  3. [ルールの変更] ダイアログボックスで、同期オブジェクトの照合ルールを変更して、オブジェクトを追加または削除します。

    照合ルールを構成する場合、ビジネスロジックはデータ同期タスクの種類によって異なります。詳細については、このトピックの「データベースからメッセージキューインスタンスへのデータ移行/同期の照合ルールを構成する」セクションをご参照ください。

  4. [検証] をクリックします。 一致結果を表示するには、検証が成功したら[オブジェクトのプレビュー] をクリックします。

    新しいオブジェクトにポインターを合わせ、表示される [構成] をクリックして、このオブジェクトのフィルター条件を構成できます。

    image

  5. [次へ] をクリックします。

    • オブジェクトを追加すると、システムはこれらのオブジェクトに対して事前チェックを実行します。

    • オブジェクトを削除すると、削除されるオブジェクトの数が表示されます。

  6. 事前チェックが成功したか、削除するオブジェクトの数を確認したら、[送信] をクリックします。

    オブジェクトの変更が実行された後、ページの右上隅にある [オブジェクトの表示] をクリックし、[変更されたレコード] をクリックして、変更レコードと詳細を表示できます。

    image

FAQ

  • 権限不足

    ソースデータベースユーザーの権限設定にご注意ください。移行ユーザーに必要なすべての権限を付与しない場合、一部のオブジェクトがデータ転送サービスのフロントエンドに表示されず、マッチングルールを正しく設定できません。この場合、データ転送サービスがターゲットオブジェクトを見つけられないためにデータ移行タスクまたはデータ同期タスクが中断されるのを防ぐため、これらのオブジェクトを [オブジェクト除外ルール] に追加する必要があります。

  • DML フィルタリングはサポートされていません

    DDL 同期が無効になっている場合、データ伝送サービスでは、一致ルールに基づいてオブジェクトを選択できます。増分同期中に作成された新しいテーブルが一致ルールを満たしている場合、関連する DDL 文は無視されますが、データ伝送サービスは引き続き DML 文を同期します。その結果、オブジェクトをターゲットに移行または同期できないため、データ移行タスクまたはデータ同期タスクが中断されます。したがって、ターゲットでテーブルを作成するか、テーブルをブロックリストに追加する必要があります。