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

ApsaraDB for OceanBase (Deprecated):TiDB データベースから OceanBase Database の MySQL テナントにデータを移行する方法

最終更新日:Feb 27, 2025

このトピックでは、データ伝送サービスを使用して、TiDB データベースから OceanBase Database の MySQL テナントにデータを移行する方法について説明します。

重要

データ移行タスクが長時間非アクティブな状態のままになっていると、増分ログの保存期間によっては復元できない場合があります。非アクティブな状態は、失敗停止、および 完了 です。データ転送サービスは、関連リソースを再利用するために、3 日間以上非アクティブな状態のままであるデータ移行タスクを解放します。データ移行タスクのアラートを設定し、タスクの例外をタイムリーに処理することをお勧めします。

背景

データ伝送サービスを使用すると、スキーマ移行、完全移行、および増分同期によって、既存のビジネスデータと増分データを TiDB データベースから OceanBase Database の MySQL テナントにシームレスに移行できます。

TiDB は、ハイブリッドトランザクション/分析処理(HTAP)をサポートする統合分散データベースです。 TiDB データベースから OceanBase Database の MySQL テナントに増分データを同期するには、TiCDC クラスタと Kafka クラスタをデプロイする必要があります。

image.png

TiCDC は、TiDB の増分データ同期ツールであり、配置ドライバ(PD)クラスタを使用して高可用性を提供します。これは、TiDB クラスタのスケジューリングモジュールであり、通常は 3 つの PD ノードで構成されます。 TiKV Server は、TiDB クラスタの TiKV ノードです。変更ログのデータ変更を TiCDC クラスタに送信します。 TiCDC は複数の TiCDC プロセスを実行して TiKV ノードからデータを取得および処理し、Kafka クラスタにデータを同期します。 Kafka クラスタは、TiCDC によって変換された TiDB データベースの増分ログを保存します。増分同期中に、データ伝送サービスは Kafka クラスタから対応するデータを取得し、OceanBase Database の MySQL テナントにリアルタイムでデータを移行します。

Kafka データソースにバインドせずに TiDB データソースを作成した場合、増分同期を実行できません。

前提条件

  • データ伝送サービスには、クラウドリソースにアクセスするための権限があります。詳細については、「データ伝送のロールに権限を付与する」をご参照ください。

  • ソース TiDB データベースとターゲット OceanBase Database の MySQL テナントにデータ移行用の専用データベースユーザーを作成し、対応する権限をユーザーに付与しました。詳細については、「データベースユーザーを作成する」をご参照ください。

制限事項

  • ソースデータベースの制限事項

    スキーマ移行または完全移行中に、データベースまたはテーブルスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクが中断される可能性があります。

  • TiDB 4.x および 5.x のみがサポートされています。

  • データ伝送サービスは、TiDB データベースから OceanBase Database の MySQL テナントへのデータ移行の DDL 同期をサポートしていません。

  • データ伝送サービスは、ターゲットデータベースのトリガーをサポートしていません。ターゲットデータベースにトリガーが存在する場合、データ移行が失敗する可能性があります。

  • データ伝送サービスは、TiDB データベースから OceanBase Database の MySQL テナントへの、プライマリキーのないテーブルとスペースを含むデータの移行をサポートしていません。

  • データソース識別子とユーザーアカウントは、データ伝送システムでグローバルに一意である必要があります。

  • データ伝送サービスは、オブジェクトのデータベース名、テーブル名、および列名が特殊文字を含まない ASCII エンコードである場合にのみ、オブジェクトの移行をサポートします。特殊文字は、改行、スペース、および次の文字です。 . | " ' ` ( ) = ; / & \.

  • データ伝送サービスは、TiCDC Open Protocol のみをサポートしています。サポートされていないプロトコルを使用すると、ヌルポインターエラーが返されます。

  • TiCDC を使用して Kafka インスタンスにデータを同期する場合、構成ファイルに enable-old-value = true 設定を追加する必要があります。そうしないと、データ同期メッセージの形式が無効になる可能性があります。詳細については、「タスク構成ファイル」をご参照ください。

考慮事項

  • ソースに同じ名前の外部キーが含まれている場合、スキーマ移行中にエラーが発生します。この場合、外部キーの名前を変更してタスクを復元できます。

  • ソースデータベースで UTF-8 文字セットを使用する場合は、文字化けを避けるために、ターゲットデータベースで UTF-8 または UTF-16 などの互換性のある文字セットを使用することをお勧めします。

  • TiCDC によって同期的に使用されているトピックにデータを書き込まないでください。そうしないと、ヌルポインターエラーが返されます。

  • DECIMAL、FLOAT、DOUBLE などのデータ型の列に対するデータ伝送サービスの移行精度が予想どおりであるかどうかを確認します。ターゲットフィールド型の精度がソースフィールド型の精度よりも低い場合、精度が高い値が切り捨てられる可能性があります。これにより、ソースフィールドとターゲットフィールド間でデータの不整合が発生する可能性があります。

  • ターゲットで一意なインデックスを変更する場合は、データの不整合を避けるために、データ移行タスクを再起動する必要があります。

  • ノード間またはクライアントとサーバー間のクロックが同期していない場合、増分同期または逆増分同期中のレイテンシが不正確になる可能性があります。

    たとえば、クロックが標準時刻よりも早い場合、レイテンシは負になる可能性があります。クロックが標準時刻よりも遅い場合、レイテンシは正になる可能性があります。

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

    • 一致ルールを指定して、ソースデータベースとターゲットデータベース間のマッピングを構成することをお勧めします。

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

  • ソースとターゲットのテーブルスキーマの差異により、データ整合性が生じる可能性があります。いくつかの既知のシナリオを以下に示します。

    • ターゲットでテーブルスキーマを手動で作成する場合、いずれかの列のデータ型がデータ伝送サービスでサポートされていないと、ターゲットで暗黙的なデータ型変換が発生し、ソースデータベースとターゲットデータベース間で列型が不整合になる可能性があります。

    • ターゲットの列の長さがソースデータベースの列の長さよりも短い場合、この列のデータが自動的に切り捨てられ、ソースデータベースとターゲットデータベース間でデータの不整合が発生する可能性があります。

  • データ移行タスクの作成時に [増分同期] のみを選択した場合、データ転送サービスでは、ソースデータベースのローカル増分ログを 48 時間以上保持する必要があります。

    データ移行タスクの作成時に [フル移行][増分同期] を選択した場合、データ転送サービスでは、ソースデータベースのローカル増分ログを 7 日間以上保持する必要があります。 データ転送サービスが増分ログを取得できない場合、データ移行タスクが失敗したり、移行後にソースデータベースとターゲットデータベースの間でデータの不整合が発生したりする可能性があります。

  • ソースデータベースまたはターゲットデータベースに大文字と小文字のみが異なるテーブルオブジェクトが含まれている場合、ソースデータベースまたはターゲットデータベースで大文字と小文字が区別されないため、データ移行の結果が予期したとおりにならない可能性があります。

サポートされているソースおよびターゲットのインスタンスタイプ

次の表では、OB_MySQL は OceanBase Database の MySQL テナントを表します。

ソース

ターゲット

TiDB (VPC 内の自己管理データベース)

OB_MySQL (OceanBase クラスタインスタンス)

TiDB (パブリック IP アドレスを持つ自己管理データベース)

OB_MySQL (OceanBase クラスタインスタンス)

TiDB (VPC 内の自己管理データベース)

OB_MySQL (サーバーレスインスタンス)

TiDB (パブリック IP アドレスを持つ自己管理データベース)

OB_MySQL (サーバーレスインスタンス)

データ型マッピング

TiDB データベース

OceanBase Database の MySQL テナント

INTEGER

INTEGER

TINYINT

TINYINT

MEDIUMINT

MEDIUMINT

BIGINT

BIGINT

SMALLINT

SMALLINT

DECIMAL

DECIMAL

NUMERIC

NUMERIC

FLOAT

FLOAT

REAL

REAL

DOUBLE PRECISION

DOUBLE PRECISION

BIT

BIT

CHAR

CHAR

VARCHAR

VARCHAR

BINARY

BINARY

VARBINARY

VARBINARY

BLOB

BLOB

TEXT

TEXT

ENUM

ENUM

SET

SET

DATE

DATE

DATETIME

DATETIME

TIMESTAMP

TIMESTAMP

TIME

TIME

YEAR

YEAR

手順

  1. ApsaraDB for OceanBase コンソール にログインし、データ移行タスクを購入します。

    詳細については、「データ移行タスクを購入する」をご参照ください。

  2. [データ伝送] > [データ移行] を選択します。表示されるページで、データ移行タスクの [構成] をクリックします。

    image.png

    既存のタスクの構成を参照する場合は、[構成の参照] をクリックします。詳細については、「データ移行タスクの構成を参照する」をご参照ください。

  3. [ソースとターゲットの選択] ページで、関連パラメータを構成します。

    パラメータ

    説明

    移行タスク名

    数字と文字の組み合わせに設定することをお勧めします。スペースを含めることはできず、長さは 64 文字を超えることはできません。

    ソース

    TiDB データソースを作成済みの場合は、ドロップダウンリストから選択します。それ以外の場合は、ドロップダウンリストの [新しいデータソース] をクリックし、右側に表示されるダイアログボックスで作成します。詳細については、「TiDB データソースを作成する」をご参照ください。

    ターゲット

    OceanBase Database の MySQL テナントのデータソースを作成済みの場合は、ドロップダウンリストから選択します。それ以外の場合は、ドロップダウンリストの [新しいデータソース] をクリックし、右側に表示されるダイアログボックスで作成します。パラメータの詳細については、「OceanBase データソースを作成する」をご参照ください。

    タグ(オプション)

    ドロップダウンリストからターゲットタグを選択します。[タグの管理] をクリックして、タグを作成、変更、および削除することもできます。詳細については、「タグを使用してデータ移行タスクを管理する」をご参照ください。

  4. [次へ] をクリックします。[移行タイプの選択] ページで、現在のデータ移行タスクの移行タイプを指定します。

    サポートされている移行タイプは、スキーマ移行、完全移行、増分同期、完全検証、および逆増分同期です。

    image

    移行タイプ

    説明

    スキーマ移行

    スキーマ移行タスクが開始されると、データ伝送サービスは、データベースオブジェクト(テーブル、インデックス、制約、コメント、ビューなど)の定義をソースデータベースからターゲットデータベースに移行し、一時テーブルを自動的に除外します。

    完全移行

    完全移行タスクが開始されると、データ伝送サービスは、ソースデータベースのテーブルからターゲットデータベースの対応するテーブルに既存のデータを移行します。[完全移行] を選択する場合は、データ移行前に ANALYZE 文を使用して TiDB データベースの統計を収集することをお勧めします。

    増分同期

    増分同期タスクが開始されると、データ伝送サービスは、変更されたデータ(追加、変更、または削除されたデータ)をソースデータベースからターゲットデータベースの対応するテーブルに同期します。

    [増分同期] では、[DML 同期] がサポートされています。必要に応じて操作を選択できます。詳細については、「DDL/DML 同期を構成する」をご参照ください。 Kafka データソースにバインドせずに TiDB データソースを作成した場合、[増分同期] を選択できません。

    完全検証

    完全移行タスクと増分同期タスクが完了すると、データ伝送サービスは自動的に完全検証タスクを開始し、ソースデータベースとターゲットデータベースのテーブルを検証します。

    • [完全検証] を選択する場合は、完全検証の前に TiDB データベースと OceanBase Database の MySQL テナントの統計を収集することをお勧めします。

    • [増分同期] を選択したが、[DML 同期] セクションですべての DML 文を選択しなかった場合は、[完全検証] を選択できません。

    逆増分同期

    ビジネスデータベースのスイッチオーバー後にターゲットデータベースで行われたデータ変更は、逆増分同期によってソースデータベースにリアルタイムで同期されます。

    一般に、増分同期の構成は逆増分同期に再利用されます。必要に応じて、逆増分同期の構成をカスタマイズすることもできます。

  5. [次へ] をクリックします。[移行オブジェクトの選択] ページで、データ移行タスクの移行オブジェクトを指定します。

    [オブジェクトの指定] または [一致ルール] を選択して、移行オブジェクトを指定できます。このトピックでは、[オブジェクトの指定] を使用して移行オブジェクトを指定する方法について説明します。一致ルールの詳細については、「一致ルールを構成および変更する」をご参照ください。

    重要
    • 移行するテーブルの名前、およびテーブルの列の名前に中国語の文字を含めることはできません。

    • データベース名またはテーブル名に二重ドル記号($$)が含まれている場合、移行タスクを作成できません。

    image.png

    1. [移行オブジェクトの選択] セクションで、[オブジェクトの指定] を選択します。

    2. [移行範囲の指定] セクションの [ソースオブジェクト] リストで、移行するオブジェクトを選択します。1 つ以上のデータベースのテーブルとビューを選択できます。

    3. > をクリックして、[ターゲットオブジェクト] リストに追加します。

    データ伝送サービスでは、テキストファイルからのオブジェクトのインポート、ターゲットオブジェクトの名前変更、行フィルターの設定、列情報の表示、および単一またはすべての移行オブジェクトの削除が可能です。

    説明

    [一致ルール] を選択して移行オブジェクトを指定する場合、オブジェクトの名前変更は、指定された一致ルールの構文に基づいて実装されます。操作領域では、フィルター条件のみを設定できます。詳細については、「一致ルールを構成および変更する」をご参照ください。

    操作

    説明

    オブジェクトのインポート

    1. 右側のリストで、右上隅にある オブジェクトのインポート をクリックします。

    2. 表示されるダイアログボックスで、[OK] をクリックします。

      重要

      この操作は以前の選択を上書きします。注意して進めてください。

    3. オブジェクトのインポート ダイアログボックスで、移行するオブジェクトをインポートします。

      CSV ファイルをインポートして、データベースまたはテーブルの名前を変更し、行フィルタリング条件を設定できます。詳細については、「移行オブジェクトの設定をダウンロードおよびインポートする」をご参照ください。

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

      移行オブジェクトをインポートした後、それらの有効性を確認します。列フィールドマッピングは現在サポートされていません。

    5. 検証が成功したら、OK をクリックします。

    オブジェクトの名前変更

    データ伝送サービスでは、移行オブジェクトの名前を変更できます。詳細については、「データベーステーブルの名前を変更する」をご参照ください。

    設定の構成

    データ伝送サービスでは、WHERE 条件を使用して行をフィルタリングできます。詳細については、「SQL 条件を使用してデータをフィルタリングする」をご参照ください。

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

    1 つまたはすべてのオブジェクトの削除

    データ伝送サービスでは、データマッピング中に右側のリストに追加された単一のオブジェクトまたはすべての移行オブジェクトを削除できます。

    • 単一の移行オブジェクトを削除する

      右側のリストで、削除するオブジェクトにポインターを移動し、[削除] をクリックして移行オブジェクトを削除します。

    • すべての移行オブジェクトを削除する

      右側のリストで、右上隅にある すべて削除OK をクリックします。表示されるダイアログボックスで、 をクリックしてすべての移行オブジェクトを削除します。

  6. [次へ] をクリックします。[移行オプション] ページで、パラメータを構成します。

    • 完全移行

      次の表では、完全移行のパラメータについて説明します。これらのパラメータは、[移行タイプの選択] ページで [完全移行] を選択した場合にのみ表示されます。

      image

      パラメータ

      説明

      読み取り同時実行性

      完全移行中にソースからデータを読み取るための同時実行性。最大値は 512 です。読み取り同時実行性が高いと、ソースに過度の負荷がかかり、ビジネスに影響を与える可能性があります。

      書き込み同時実行性

      完全移行中にターゲットにデータを書き込むための同時実行性。最大値は 512 です。書き込み同時実行性が高いと、ターゲットに過度の負荷がかかり、ビジネスに影響を与える可能性があります。

      完全移行レート制限

      必要に応じて、完全移行レートを制限するかどうかを選択できます。完全移行レートを制限することを選択した場合は、1 秒あたりのレコード数(RPS)と 1 秒あたりのバイト数(BPS)を指定する必要があります。 RPS は、完全移行中にターゲットに移行されるデータ行の最大数を指定し、BPS は、完全移行中にターゲットに移行されるデータの最大バイト数を指定します。

      説明

      ここで指定された RPS 値と BPS 値は、調整のためだけにあります。実際の完全移行パフォーマンスは、ソースとターゲットの設定やインスタンスの仕様などの要因の影響を受けます。

      ターゲットデータベースの空でないテーブルの処理

      有効な値は、[無視][移行の停止] です。

      • [無視] を選択した場合、挿入されるデータがターゲットテーブルの既存のデータと競合すると、データ伝送サービスは競合するデータをログに記録し、既存のデータを保持します。

        重要

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

      • [移行の停止] を選択し、ターゲットテーブルにレコードが含まれている場合、完全移行中に移行がサポートされていないことを示すエラーが報告されます。この場合、移行を続行する前に、ターゲットテーブルのデータを処理する必要があります。

        重要

        エラーを促すダイアログボックスで [復元] をクリックすると、データ伝送サービスはこのエラーを無視してデータの移行を続行します。注意して進めてください。

      事後インデックス作成

      完全移行の完了後にインデックスを作成するかどうかを指定します。事後インデックス作成により、完全移行に必要な時間を短縮できます。事後インデックス作成に関する考慮事項については、以下の説明を参照してください。

      重要
      • このパラメーターは、[移行タイプの選択] ページで スキーマ移行[フル移行] の両方を選択した場合にのみ表示されます。

      • 移行の完了後に作成できるのは、非一意キーインデックスのみです。

      • インデックスの作成中にターゲット OceanBase データベースが次のエラーを返した場合、データ伝送サービスはエラーを無視し、インデックスが正常に作成されたと判断し、再度作成しません。

        • OceanBase Database の MySQL テナントのエラーメッセージ:Duplicate key name

        • OceanBase Database の Oracle テナントのエラーメッセージ:name is already used by an existing object

      ターゲットが OceanBase データベースであり、このパラメータで [許可] を選択した場合は、次のパラメータを設定する必要があります。

      • 単一インデックス DDL 同時実行構成:単一インデックスで許可される同時 DDL 操作の最大数。値が大きいほど、リソース消費量が多く、データ移行が速くなります。

      • 最大同時インデックス DDL 数量構成:システムが一度に呼び出すことができる事後インデックス作成 DDL 操作の最大数。

      事後インデックス作成が許可されている場合は、OceanBase Database のハードウェア条件と現在のビジネストラフィックに基づいて、CLI クライアントを使用してビジネステナントの次のパラメータを変更することをお勧めします。

      // ファイルメモリバッファサイズの制限を指定します。
      alter system set _temporary_file_io_area_size = '10' tenant = 'xxx'; 
      // OceanBase Database V4.x で調整を無効にします。
      alter system set sys_bkgd_net_percentage = 100;  
    • 増分同期

      次の表では、増分同期のパラメータについて説明します。これらのパラメータは、[移行タイプの選択] ページで [増分同期] を選択した場合にのみ表示されます。

      image

      パラメータ

      説明

      書き込み同時実行性

      増分同期中にターゲットにデータを書き込むための同時実行性。最大値は 512 です。書き込み同時実行性が高いと、ターゲットに過度の負荷がかかり、ビジネスに影響を与える可能性があります。

      増分同期レート制限

      必要に応じて、増分同期レートを制限するかどうかを選択できます。増分同期レートを制限することを選択した場合は、RPS と BPS を指定する必要があります。 RPS は、増分同期中にターゲットに同期されるデータ行の最大数を指定し、BPS は、増分同期中にターゲットに同期されるデータの最大バイト数を指定します。

      説明

      ここで指定された RPS 値と BPS 値は、調整のためだけにあります。実際の増分同期パフォーマンスは、ソースとターゲットの設定やインスタンスの仕様などの要因の影響を受けます。

      増分同期の開始タイムスタンプ

      • このパラメーターは、[移行タイプの選択] ページで [完全移行] を選択した場合、表示されません。

      • [増分同期] を選択したが [完全移行] を選択しなかった場合は、データの同期を開始する時点を指定します。デフォルト値は現在のシステム時刻です。詳細については、「増分同期のタイムスタンプを設定する」をご参照ください。

    • 逆増分同期

      次の表では、逆増分同期のパラメータについて説明します。これらのパラメータは、[移行タイプの選択] ページで [逆増分] を選択した場合にのみ表示されます。デフォルトでは、増分同期の構成は逆増分同期に再利用されます。

      image

      増分同期の構成を再利用せず、必要に応じて逆増分同期を構成することもできます。

      パラメータ

      説明

      書き込み同時実行性

      逆増分同期中にソースにデータを書き込むための同時実行性。最大値は 512 です。同時実行性が高いと、ソースに過度の負荷がかかり、ビジネスに影響を与える可能性があります。

      逆増分レート制限

      必要に応じて、逆増分同期レートを制限するかどうかを選択できます。逆増分同期レートを制限することを選択した場合は、1 秒あたりのリクエスト数(RPS)と 1 秒あたりのバイト数(BPS)を指定する必要があります。 RPS は、逆増分同期中にソースに同期されるデータ行の最大数を指定し、BPS は、逆増分同期中にソースに同期されるデータの最大バイト数を指定します。

      説明

      ここで指定された RPS 値と BPS 値は、調整のためだけにあります。実際の逆増分同期パフォーマンスは、ソースとターゲットの設定やインスタンスの仕様などの要因の影響を受けます。

      増分同期の開始タイムスタンプ

      • このパラメーターは、[移行タイプの選択] ページで [完全移行] を選択した場合、表示されません。

      • [増分同期] を選択したが [完全移行] を選択しなかった場合は、デフォルトで前方スイッチオーバーの開始タイムスタンプ(存在する場合)が使用されます。このパラメータは変更できません。

    • 詳細パラメータ

      このセクションは、ターゲットが OceanBase Database V4.3.0 以降の MySQL テナントであり、[移行タイプの選択] ページで [スキーマ移行] を選択した場合にのみ表示されます。

      image

      このパラメーターは、スキーマ移行中のターゲットテーブルオブジェクトのストレージタイプを指定します。ターゲットテーブルオブジェクトでサポートされているストレージタイプは、[デフォルト][行ストア][列ストア]、および [ハイブリッド列ストア] です。詳細については、「default_table_store_format」をご参照ください。

      説明

      [既定] という値は、ターゲットのパラメーター構成に基づいて他のパラメーターが自動的に設定されることを意味します。スキーマ移行におけるテーブルオブジェクトは、指定されたストレージタイプに基づいて対応するスキーマに書き込まれます。

  7. [事前チェック] をクリックして、データ移行タスクの事前チェックを開始します。

    [事前チェック] 中に、データ伝送サービスは、データベースユーザーの読み取りおよび書き込み権限とデータベースのネットワーク接続を確認します。データ移行タスクは、すべてのチェック項目に合格した後でのみ開始できます。事前チェック中にエラーが返された場合は、次の操作を実行できます。

    • 問題を特定してトラブルシューティングし、再度事前チェックを実行します。

    • 失敗した事前チェック項目の [アクション] 列で [スキップ] をクリックします。操作の結果を尋ねるダイアログボックスで、[OK] をクリックします。

  8. 事前チェックが成功したら、[タスクの開始] をクリックします。

    タスクをすぐに開始する必要がない場合は、[保存] をクリックします。[移行タスク] ページで、またはバッチ操作を実行することで、後でタスクを開始できます。バッチ操作の詳細については、「データ移行タスクのバッチ操作を実行する」をご参照ください。

    データ伝送サービスでは、移行タスクの実行中に、移行オブジェクトとその行フィルタリング条件を変更できます。詳細については、「移行オブジェクトとそのフィルター条件を表示および変更する」をご参照ください。データ移行タスクが開始されると、選択した移行タイプに基づいて実行されます。詳細については、「移行の詳細を表示する」をご参照ください。

関連情報