本記事では、移行オブジェクトの一致ルールに関する背景情報、制限事項、設定・変更方法、データベース間シナリオ例、およびよくある質問について説明します。
背景
データ移行タスクを新規作成する際には、具体的な移行対象を指定する必要があります。データ移行では、オブジェクトの指定、インポートオブジェクト、マッチングルールの3つの方法から選択できます。その中で、マッチングルール方式では、ワイルドカードルールを記述することで移行対象を指定または変更でき、ソース側およびターゲット側のオブジェクトマッピングロジックを設定できます。シンプルかつ効率的な文字列マッチング機能により、移行対象が多数ある場合でも設定の難易度を大幅に低減できます。同時に、マッチングルールに一致する新規テーブルは、増分DDLによってターゲット側に自動的に同期されます。増分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を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*。ソース側のデータベースとターゲット側のデータベースがどちらもワイルドカードルールの場合、データベースレベルの式は完全に一致している必要があります。これはデータベースの水平移行を意味します。
ソース側のテーブルとターゲット側のテーブルがどちらもワイルドカードルールの場合、テーブルレベルの式は完全に一致している必要があります。これはテーブルの水平移行を意味します。
ターゲット側のデータベースがワイルドカードルールの場合、ソース側のデータベースもワイルドカードルールである必要があります。
ターゲット側のテーブルがワイルドカードルールの場合、ソース側のテーブルもワイルドカードルールである必要があります。
データベースからメッセージキューへのワイルドカードルールの説明
データ移行でサポートされているデータベースからメッセージキューへのワイルドカードルールとその要件は以下のとおりです。
説明
以下の表で、アスタリスク(*)はワイルドカードルールを示します。
サポートされているワイルドカードルール |
例 |
説明 |
|---|---|---|
| *.*=<Topic 名> | *.*=topic | 複数データベースの複数テーブルを1つのトピックにマッピング |
| *.<ソーステーブル>=<Topic 名> | *.b=topic | 複数データベースのテーブルbを1つのトピックにマッピング |
| <ソースデータベース>.*=<Topic 名> | a.*=topic | データベースaの複数テーブルを1つのトピックにマッピング |
| <ソースデータベース>.<ソーステーブル>=<Topic 名> | a.b=topic | データベースaのテーブルbを1つのトピックにマッピング |
使用上の制限
データ移行では複数のルールを入力できますが、各ルールは行をまたぐことはできず、前後にスペースを含めることもできません。
移行オブジェクトのルールは空にすることはできませんが、除外オブジェクトのルールは空にできます。
データ移行は、構造移行やフル移行中のDDL変更をサポートしていません。
マッチングルールにより移行オブジェクトを選択する場合、データ移行は、テーブル名に特殊文字(改行、スペース、および .|"'`()=;/&*?[][!] を含む場合をサポートしていません。
データ移行は、複数のマッチングルールを使用して、ソース側の同一データベース内の異なるテーブルをターゲット側の異なるデータベースにマッピングすることをサポートしていません。例:
a.a* = b.a* & a.b* = c.b*。データ移行は現在
CREATE DATABASEのDDLステートメントをサポートしていません。新規作成するデータベース名がデータ移行のマッチングルール内に含まれる場合、ターゲット側で手動でデータベースを作成する必要があります。その後、新しいデータベースのデータ同期を続けることができます。
注意事項
移行対象ルールと除外対象ルールの設定後、ソース側のテーブル名が移行対象ルールと除外対象ルールの差集合に含まれる場合、該当するオブジェクトを選択できます。
説明
差集合とは、与えられた2つの集合について、最初の集合には存在するが2番目の集合には存在しないすべての要素を含む新しい集合を返すことです。
DDL同期機能を有効にした後、ソース側でDDLステートメントを使用して新しいテーブルを作成またはテーブル構造を変更すると、そのテーブル名またはテーブル構造名が移行対象ルールと除外対象ルールの差集合に含まれる場合、そのDDLステートメントがデータ移行によってターゲット側にリアルタイムで同期されます。
データベースまたはテーブルの統合シナリオでは:
ソース側とターゲット側の関係をマッチングルールを使用してマッピングすることを推奨します。
ターゲット側で直接テーブル構造を作成することを推奨します。データ移行を使用して作成する場合は、構造移行の手順で一部の失敗したオブジェクトをスキップしてください。
データベースまたはテーブルの統合シナリオで DDL同期 を選択した場合、誤って削除するリスクがあります。例えば、ソース側の複数のデータベースやテーブルがターゲット側の1つのデータベースやテーブルに統合されている場合、ソース側の1つのデータベースやテーブルを削除すると、ターゲット側の統合されたデータベースやテーブルも削除される可能性があります。
新しいデータ移行タスクを作成する際、ターゲット側テーブルオブジェクトにレコードが存在する場合の処理ポリシー を 無視する に設定してください。
テーブルにリネームマッピングが存在する場合、リネームマッピングが優先されます。例えば、ルール
a.b[0-3]とa.b[3-5]=a.cの両方が存在する場合、テーブルa.b3はa.cにリネームされます。RENAME TABLEのDDLステートメントを実行する際、RENAME後のテーブルオブジェクトが元のマッチングルールや除外ルールに含まれない場合、予期しない同期問題が発生する可能性があるため、慎重に操作してください。
データベース間のマッチングルールの設定
新しいデータ移行タスクを作成し、移行対象を選択してください の手順に進みます。
詳細については、データ移行モジュールの該当タイプの新規データ移行タスクドキュメントをご参照ください。
移行対象を選択してください エリアで、マッチングルール を選択します。
移行範囲を選択してください エリアで、オブジェクト移行ルール と オブジェクト除外規則 (オプション) を入力します。サポートされているマッチングルールの詳細については、ワイルドカードルールの説明をご参照ください。
説明
設定したルールにスペースが含まれていると、移行対象が誤ってしまう可能性があります。
確認 をクリックします。
マッチング結果を確認する必要がある場合は、検証に成功した後、プレビュー をクリックして確認してください。ご入力いただいたワイルドカード移行対象ルールと除外対象ルールは、テーブルとビューに同時適用されます。マッチング結果 には、最終オブジェクト、新規オブジェクト、削減オブジェクトが含まれます。
オブジェクト説明最終オブジェクト 設定されたマッチングルールで最終的にマッチした移行オブジェクト。 新規オブジェクト 最終マッチング結果と前回設定のマッチング結果を比較して、新規に追加された移行オブジェクト。 削減オブジェクト 最終マッチング結果と前回の設定によるマッチング結果を比較して、削減された移行オブジェクト。 マッチングルールによって移行対象を選択した後、フィルター条件を設定する操作を行うことができます。

マッチング結果 > 最終オブジェクト パネルで、ターゲットテーブルオブジェクト上にカーソルを合わせます。
表示された 設定 アイコンをクリックします。
設定 ダイアログで、標準SQLステートメントの
WHERE句を入力して行フィルタリングを設定します。設定完了後、構文の検証 をクリックします。詳細は SQL条件でデータをフィルタリングするをご参照ください。構文検証に合格したら、OK をクリックします。また、列を表示 セクションで、移行オブジェクトの列情報を確認できます。
プロンプトに従って、後続のタスク設定を完了します。
シナリオ例
データベース・テーブルの水平移行
ソース側のlgtestで始まるすべてのデータベース内で、cで始まるすべてのテーブルをターゲット側に移行し、データベース名とテーブル名は変更しません。マッチングルールの設定は以下のとおりです。

データベース・テーブルの名前変更
ソース側のlgtest2という名前のデータベース内で、booksで始まるすべてのテーブルをターゲット側に移行し、データベースlgtest2をlgtest2_newに名前変更します。テーブル名は変更しません。マッチングルールの設定は以下のとおりです。

データベース・テーブルの集約
ソース側のlgtestで始まるすべてのデータベース内で、cで始まるすべてのテーブルをターゲット側のデータベースlg_test1内のcoursesテーブルに集約します。マッチングルールの設定は以下のとおりです。

除外オブジェクトルールの設定
ソース側のlgtest2という名前のデータベース内で、bで始まり、sで終わるテーブルは同期しないように設定します。マッチングルールの設定は以下のとおりです。

除外オブジェクトルールの設定
ソース側のmcm_test1という名前のデータベース内で、testで始まり、9で終わるテーブルは同期しないように設定します。マッチングルールの設定は以下のとおりです。
データベースからメッセージキューへのマッチングルールの設定
OceanBaseデータベースのデータをKafkaに移行する際、マッチングルールを設定することで、移行対象を選択できます。
データ移行タスクを タイプとオブジェクトを選択してください ステップに配置します。
詳細については、データ移行 モジュールの該当タイプの新規データ移行タスクドキュメントをご参照ください。
移行対象を選択してください エリアで、ルールによる一致 を選択します。
オブジェクト移行ルール と オブジェクト除外規則 を入力します(オプション)。サポートされているマッチングルールの詳細については、ワイルドカードルールの説明をご参照ください。
OceanBaseデータベースのデータをKafkaに移行する際、多対一または一対一のマッピングがサポートされていますが、スペースは使用できません。移行タイプの選択時に スキーマ移行 が選択されている場合は、既存のTopic名を入力するか、新しいTopicを作成できます。移行タイプの選択時に スキーマ移行 が選択されていない場合は、既存のTopic名のみを入力できます。
確認 をクリックします。
マッチング結果を確認する必要がある場合は、検証が成功した後に オブジェクトのプレビュー をクリックして確認してください。マッチング結果 には、最終オブジェクト、新規オブジェクト、削除オブジェクトが含まれます。
マッチングルールによってデータベースから移行するオブジェクトを選択した後、フィルタ条件やシャーディング列などの設定を行えます。

マッチング結果 > 最終オブジェクト パネルで、対象テーブルオブジェクトにマウスカーソルを合わせます。
表示された 設定 アイコンをクリックします。
設定 ダイアログボックスで、以下の操作を実行できます。
OceanBaseデータベースのオブジェクトを移行する場合、行フィルター エリアのテキストボックスに、標準SQL文の
WHERE句を入力して行フィルタを設定します。設定後、構文の検証 をクリックします。詳細については、SQL条件によるデータのフィルタリングをご参照ください。シャーディング列 のドロップダウンリストから、ターゲットのシャーディング列を選択します。複数のフィールドをシャーディング列として選択できます。このパラメータはオプションです。
シャーディング列を選択する際、特別な状況がない限り、デフォルトで主キーを選択するのが適切です。主キーに負荷の偏りがある場合は、一意の識別子で負荷が比較的均等なフィールドをシャーディング列として選択し、潜在的なパフォーマンス問題を回避してください。シャーディング列の主な役割は以下のとおりです:
負荷分散:ターゲット側で同時書き込みが可能な場合、シャーディング列によってメッセージ送信に使用する特定のスレッドを区別します。
順序性:同時書き込みによって生じる可能性のある順序の乱れを防ぐため、OMSはシャーディング列の値が同じ場合でも、ユーザーが受信するメッセージが順序付けられていることを保証します。ここでの順序とは、変更の順序(DMLが一列に対して実行される順序)を指します。
列を選択 エリアで、移行する列を選択します。詳細については、列のフィルタリングをご参照ください。
OK をクリックします。
移行オブジェクトのマッチングルールの変更
マッチングルール変更の説明
次の表は、マッチングルールを変更できるシナリオを示しています。
| データ移行タスクのステップ | データ移行タスクの状態 | ステップの状態 |
| / | 未開始 | / |
| フル移行 | 実行中 | 実行中 |
| 失敗 | 失敗 | |
| 一時停止 | 一時停止 | |
| 増分同期 | 実行中 | 実行中 |
| 実行中 | 監視中 | |
| 失敗 | 失敗 | |
| 一時停止 | 一時停止 |
マッチングルールの変更操作
**オブジェクトの表示**ダイアログに進みます。
OB Cloudデータベースコンソールにログインします。
左側のナビゲーションペインで、データサービス > **データ移行**をクリックします。
**データ移行ページで、データ移行**タブをクリックします。
**データ移行**タブで、対象タスクの名前をクリックして詳細ページに進みます。
ページの右上隅にある**オブジェクトの表示をクリックし、移行されたオブジェクトと変更履歴**を確認します。
**オブジェクトの表示ダイアログで、右下のルールを変更する**をクリックします。
**ルールを変更する**ダイアログで、移行オブジェクトのマッチングルールを変更し、オブジェクトを追加または削除します。
**確認をクリックします。マッチング結果を確認する必要がある場合は、検証が成功した後にオブジェクトのプレビュー**をクリックして確認します。
マウスカーソルを新規オブジェクトに合わせて、表示された**設定**アイコンをクリックすると、新規オブジェクトにフィルタ条件を設定できます。

**次へ: 変更の確認**をクリックします。
新しいルールで移行オブジェクトが追加されている場合は、移行タイプを再設定して事前チェックを行います。
OceanBaseデータベースのデータをKafkaに移行する場合、多対一または一対一のマッピングがサポートされていますが、スペースは使用できません。移行タイプの選択時に**スキーマ移行が選択されている場合は、既存のTopic名を入力するか、新しいTopicを作成できます。移行タイプの選択時にスキーマ移行**が選択されていない場合は、既存のTopic名のみを入力できます。
新しいルールで移行オブジェクトが削除されている場合、ページには具体的な削除オブジェクトが表示されます。
事前チェックが成功するか、削除オブジェクトに誤りがないことを確認したら、**提出する**をクリックします。

よくある質問
権限不足
ソース側ユーザーの権限設定にご注意ください。ユーザーに付与された権限が不足している場合、一部のオブジェクトがデータ移行のフロントエンドで表示されず、マッチングルールを正しく設定できない可能性があります。そのため、権限が付与されていないオブジェクトを**オブジェクト除外規則**に追加し、データ移行タスクがターゲット側のオブジェクトを見つけられないために中断するのを防ぐ必要があります。
DMLのフィルタリングがサポートされていない
DDL同期が有効になっていない場合、データ移行ではマッチングルールを使用してオブジェクトを選択することが許可されます。増分同期の過程で、新規テーブルがマッチングルールを満たす場合、関連するDDLステートメントは無視されますが、データ移行はDMLステートメントの同期を続けるため、ターゲット側のオブジェクトに書き込めずにデータ移行タスクが中断する可能性があります。そのため、ターゲット側に新規テーブルを作成するか、そのテーブルをコンポーネントのブラックリストに追加する必要があります。