📣
TiDB Cloud Essential はパブリックプレビュー中です。このページは自動翻訳されたものです。原文はこちらからご覧ください。
AI
開発者向け
ベストプラクティス
API

データ移行を使用して、MySQL互換データベースからTiDB Cloudへ増分データのみを移行する

このドキュメントでは、TiDB Cloud コンソールのデータ移行機能を使用して、クラウド プロバイダー (Amazon Aurora MySQL、Amazon Relational Database Service (RDS)、Google Cloud SQL for MySQL、Azure Database for MySQL、または Alibaba Cloud RDS) またはセルフホストのソース データベース上の MySQL 互換データベースから、増分データをTiDB Cloud TiDB Cloud Dedicated に移行する方法について説明します。

既存のデータ、または既存のデータと増分データの両方を移行する方法については、 データ移行を使用してMySQL互換データベースをTiDB Cloudに移行する参照してください。

制限事項

注記：

このセクションでは、増分データ移行に関する制限事項のみを記載しています。一般的な制限事項も併せてお読みになることをお勧めします。 制限事項をご覧ください。

  • 対象データベースにターゲットテーブルがまだ作成されていない場合、移行ジョブは以下のようなエラーを報告して失敗します。この場合、ターゲットテーブルを手動で作成してから、移行ジョブを再試行する必要があります。

    startLocation: [position: (mysql_bin.000016, 5122), gtid-set:
00000000-0000-0000-0000-00000000000000000], endLocation:
[position: (mysql_bin.000016, 5162), gtid-set: 0000000-0000-0000
0000-0000000000000:0]: cannot fetch downstream table schema of
zm`.'table1' to initialize upstream schema 'zm'.'table1' in schema
tracker Raw Cause: Error 1146: Table 'zm.table1' doesn't exist

  • アップストリームで一部の行が削除または更新され、ダウンストリームに対応する行がない場合、移行ジョブは、アップストリームからDELETEおよびUPDATE DML 操作を複製する際に、削除または更新可能な行がないことを検知します。

増分データの移行開始位置としてGTIDを指定する場合、以下の制限事項に注意してください。

  • ソースデータベースでGTIDモードが有効になっていることを確認してください。
  • ソースデータベースがMySQLの場合、MySQLのバージョンは5.6以降である必要があり、storageエンジンはInnoDBである必要があります。
  • 移行ジョブがアップストリームのセカンダリデータベースに接続する場合、 REPLICATE CREATE TABLE ... SELECTイベントは移行できません。これは、ステートメントが同じ GTID が割り当てられた 2 つのトランザクション ( CREATE TABLEとINSERT ) に分割されるためです。その結果、 INSERTステートメントはセカンダリデータベースによって無視されます。

前提条件

注記：

このセクションには、増分データ移行に関する前提条件のみが含まれています。 一般的な前提条件も併せて読むことをお勧めします。

開始位置を指定するためにGTIDを使用する場合は、ソースデータベースでGTIDが有効になっていることを確認してください。操作方法はデータベースの種類によって異なります。

Amazon RDS および Amazon Aurora MySQL の場合

Amazon RDS および Amazon Aurora MySQL の場合、新しい変更可能なパラメータ グループ (デフォルトのパラメータ グループではない) を作成し、そのパラメータ グループ内の以下のパラメータを変更してから、インスタンスを再起動して変更を適用する必要があります。

  • gtid_mode
  • enforce_gtid_consistency

GTIDモードが正常に有効化されたかどうかは、以下のSQL文を実行することで確認できます。

SHOW VARIABLES LIKE 'gtid_mode';

結果がONまたはON_PERMISSIVEの場合、GTID モードは正常に有効化されています。

詳細については、 GTIDベースの複製のためのパラメータを参照してください。

Google Cloud SQL for MySQL の場合

Google Cloud SQL for MySQL では、GTID モードがデフォルトで有効になっています。GTID モードが正常に有効になっているかどうかは、次の SQL ステートメントを実行することで確認できます。

SHOW VARIABLES LIKE 'gtid_mode';

結果がONまたはON_PERMISSIVEの場合、GTID モードは正常に有効化されています。

Azure Database for MySQL の場合

Azure Database for MySQL（バージョン5.7以降）では、GTIDモードはデフォルトで有効になっており、GTIDモードを無効にすることはできません。

さらに、 binlog_row_imageサーバーパラメーターがFULLに設定されていることを確認してください。これは、次の SQL ステートメントを実行することで確認できます。

SHOW VARIABLES LIKE 'binlog_row_image';

結果がFULLでない場合は、 AzureポータルまたはAzure CLIを使用して、Azure Database for MySQL インスタンスのこのパラメーターを構成する必要があります。

Alibaba Cloud RDS MySQL 用

Alibaba Cloud RDS MySQLでは、GTIDモードはデフォルトで有効になっています。GTIDモードが正常に有効になっているかどうかは、次のSQL文を実行することで確認できます。

SHOW VARIABLES LIKE 'gtid_mode';

結果がONまたはON_PERMISSIVEの場合、GTID モードは正常に有効化されています。

さらに、 binlog_row_imageサーバーパラメーターがFULLに設定されていることを確認してください。これは、次の SQL ステートメントを実行することで確認できます。

SHOW VARIABLES LIKE 'binlog_row_image';

結果がFULLでない場合は、 RDSコンソールを使用して Alibaba Cloud RDS MySQL インスタンスのこのパラメータを設定する必要があります。 。

自己ホスト型のMySQLインスタンスの場合

注記：

具体的な手順やコマンドは、MySQLのバージョンや構成によって異なる場合があります。GTIDを有効にすることによる影響を十分に理解し、本番環境以外の環境で適切にテストおよび検証してから、この操作を実行してください。

自己ホスト型のMySQLインスタンスでGTIDモードを有効にするには、以下の手順に従ってください。

  1. 適切な権限を持つMySQLクライアントを使用してMySQLサーバーに接続します。

  2. GTIDモードを有効にするには、以下のSQL文を実行してください。

    -- Enable the GTID mode
SET GLOBAL gtid_mode = ON;

-- Enable `enforce_gtid_consistency`
SET GLOBAL enforce_gtid_consistency = ON;

-- Reload the GTID configuration
RESET MASTER;

  3. 設定変更を有効にするには、MySQLサーバーを再起動してください。

  4. 次のSQL文を実行して、GTIDモードが正常に有効化されているかどうかを確認してください。

    SHOW VARIABLES LIKE 'gtid_mode';

    結果がONまたはON_PERMISSIVEの場合、GTID モードは正常に有効化されています。

ステップ1：データ移行ページに移動します

  1. TiDB Cloudコンソールにログインし、私のTiDBページに移動します。

    ヒント：

    複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。

  2. ターゲットのTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで[データ] > [データ移行]をクリックします。

  3. データ移行ページで、右上隅にある「移行ジョブの作成」をクリックします。移行ジョブの作成ページが表示されます。

ステップ2：ソース接続とターゲット接続を設定する

「移行ジョブの作成」ページで、ソースとターゲットの接続を設定します。

  1. 職名を入力してください。職名は文字で始まり、60文字以内である必要があります。文字（AZ、az）、数字（0～9）、アンダースコア（_）、ハイフン（-）が使用可能です。

  2. ソース接続プロファイルを入力してください。

    • データソース：データソースの種類。
    • リージョン：データソースのリージョン。クラウドデータベースの場合のみ必要です。
    • 接続方法: データ ソースの接続方法。現在、接続方法に応じて、パブリックIP、VPCピアリング、またはプライベートリンクを選択できます。
    • ホスト名またはIPアドレス（パブリックIPおよびVPCピアリングの場合）：データソースのホスト名またはIPアドレス。
    • サービス名（プライベートリンクの場合）：エンドポイントのサービス名。
    • ポート：データソースのポート番号。
    • ユーザー名：データソースのユーザー名。
    • パスワード：ユーザー名のパスワード。
    • SSL/TLS ：SSL/TLSを有効にする場合は、以下のいずれかの証明書を含む、データソースの証明書をアップロードする必要があります。
      • CA証明書のみ
      • クライアント証明書とクライアントキー
      • CA証明書、クライアント証明書、およびクライアントキー

  3. ターゲット接続プロファイルを入力してください。

    • ユーザー名: ターゲットのTiDB Cloud Dedicatedクラスターのユーザー名を入力します。
    • パスワード： TiDB Cloudのユーザー名のパスワードを入力してください。

  4. 入力した情報を検証するには、 「接続を検証」をクリックし、「次へ」をクリックしてください。

  5. 表示されたメッセージに従って行動してください。

    • パブリックIPまたはVPCピアリングを使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。
    • AWS Private Link を使用する場合、エンドポイント要求を承認するよう求められます。AWS AWS VPCコンソールに移動し、エンドポイント サービスをクリックしてエンドポイント要求を承認してください。

ステップ3：移行ジョブの種類を選択する

ソースデータベースの増分データのみをTiDB Cloudに移行するには、 「増分データ移行」を選択し、 「既存データ移行」は選択しないでください。こうすることで、移行ジョブはソースデータベースの進行中の変更のみをTiDB Cloudに移行します。

「開始位置」領域では、増分データ移行の開始位置として、以下のいずれかのタイプを指定できます。

  • 増分移行ジョブが開始される時間
  • GTID
  • Binlogファイル名と位置

移行ジョブが開始されると、開始位置を変更することはできません。

増分移行ジョブが開始される時間

このオプションを選択すると、移行ジョブは、移行ジョブの開始後にソースデータベースで生成された増分データのみを移行します。

GTIDを指定してください

このオプションを選択すると、ソースデータベースの GTID を指定できます（例: 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-23 。移行ジョブは、指定された GTID セットを除いたトランザクションを複製し、ソースデータベースの進行中の変更をTiDB Cloudに移行します。

ソースデータベースのGTIDを確認するには、以下のコマンドを実行してください。

SHOW MASTER STATUS;

GTID を有効にする方法については、前提条件を参照してください。

binlogファイル名と位置を指定してください。

このオプションを選択すると、ソースデータベースのbinlogファイル名（例： binlog.000001 ）とbinlogの位置（例： 1307 ）を指定できます。移行ジョブは、指定されたbinlogファイル名と位置から開始され、ソースデータベースの進行中の変更をTiDB Cloudに移行します。

以下のコマンドを実行すると、ソースデータベースのbinlogファイル名と位置を確認できます。

SHOW MASTER STATUS;

対象データベースにデータが存在する場合は、binlogの位置が正しいことを確認してください。そうでない場合、既存データと増分データの間で競合が発生する可能性があります。競合が発生すると、移行ジョブは失敗します。競合したレコードをソースデータベースのデータで置き換える場合は、移行ジョブを再開できます。

ステップ4：移行するオブジェクトを選択する

  1. 「移行するオブジェクトの選択」ページで、移行するオブジェクトを選択します。 「すべて」をクリックするとすべてのオブジェクトを選択できます。 「カスタマイズ」をクリックしてから、オブジェクト名の横にあるチェックボックスをクリックしてオブジェクトを選択することもできます。

  2. 「次へ」をクリックしてください。

ステップ5：事前チェック

事前チェックページでは、事前チェックの結果を確認できます。事前チェックが失敗した場合は、 「失敗」または「警告」の詳細に従って操作を行い、再度「チェック」をクリックして再チェックしてください。

チェック項目の一部にのみ警告が表示されている場合は、リスクを評価し、警告を無視するかどうかを検討できます。すべての警告を無視した場合、移行ジョブは自動的に次のステップに進みます。

エラーと解決策の詳細については、 事前チェックのエラーと解決策を参照してください。

事前チェック項目の詳細については、 移行タスクの事前チェック参照してください。

すべてのチェック項目が「合格」と表示されたら、 「次へ」をクリックしてください。

ステップ6：仕様を選択して移行を開始する

「仕様を選択して移行を開始」ページで、パフォーマンス要件に応じて適切な移行仕様を選択します。仕様の詳細については、 データ移行の仕様参照してください。

仕様を選択したら、 「ジョブの作成」をクリックし、「開始」をクリックして移行を開始します。

ステップ7：移行の進捗状況をビュー

移行ジョブが作成されると、移行ジョブの詳細ページで移行の進行状況を確認できます。移行の進行状況は、 「ステージ」と「ステータス」の領域に表示されます。

移行ジョブは、実行中でも一時停止または削除できます。

移行ジョブが失敗した場合は、問題を解決した後で再開できます。

移行ジョブはどのステータスでも削除できます。

移行中に問題が発生した場合は、 移行エラーとその解決策参照してください。

このページは役に立ちましたか？