データ移行を使用して、MySQL 互換データベースから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エッセンシャルTiDB Cloudコンソールのデータ移行機能を使用します。

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

制限事項

注記：
このセクションでは、増分データ移行に関する制限事項のみを説明します。一般的な制限事項も併せてご確認いただくことをお勧めします。1 制限事項参照してください。

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

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ステートメントはセカンダリデータベースによって無視されます。

前提条件

注記：
このセクションでは、増分データ移行に関する前提条件のみを説明します。1 一般的な前提条件併せてお読みいただくことをお勧めします。

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

Amazon RDS および Amazon Aurora MySQL の場合

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

gtid_mode
enforce_gtid_consistency

次の SQL ステートメントを実行すると、GTID モードが正常に有効化されているかどうかを確認できます。

SHOW VARIABLES LIKE 'gtid_mode';

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

詳細についてはGTIDベースのレプリケーションのパラメータ参照してください。

Google Cloud SQL for MySQLの場合

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

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モードがデフォルトで有効になっています。次のSQL文を実行することで、GTIDモードが正常に有効化されているかどうかを確認できます。

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 モードを有効にするには、次の手順に従います。

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

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;

設定の変更を有効にするには、MySQLサーバーを再起動します。
次の SQL ステートメントを実行して、GTID モードが正常に有効化されているかどうかを確認します。
```
SHOW VARIABLES LIKE 'gtid_mode';
```
結果がONまたはON_PERMISSIVEの場合、 GTID モードは正常に有効化されています。

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

TiDB Cloudコンソールにログインし、プロジェクトのクラスターページに移動します。
ヒント：
左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。
ターゲットクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで[データ] > [データ移行]をクリックします。
「データ移行」ページで、右上隅の「移行ジョブの作成」をクリックします。 「移行ジョブの作成」ページが表示されます。

ステップ2: ソースとターゲットの接続を構成する

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

ジョブ名を入力してください。ジョブ名は文字で始まり、60文字未満である必要があります。文字（AZ、az）、数字（0-9）、アンダースコア（_）、ハイフン（-）が使用できます。
ソース接続プロファイルを入力します。
- データソース: データソースの種類。
- リージョン: データソースのリージョン。クラウドデータベースにのみ必要です。
- 接続方法: データソースの接続方法。現在、接続方法に応じて、パブリック IP、VPC ピアリング、またはプライベートリンクを選択できます。接続方法に応じて、パブリック IP またはプライベートリンクを選択できます。
- ホスト名または IP アドレス(パブリック IP および VPC ピアリングの場合): データソースのホスト名または IP アドレス。
- サービス名(Private Link の場合): エンドポイントサービス名。
- ポート: データソースのポート。
- ユーザー名: データソースのユーザー名。
- パスワード: ユーザー名のパスワード。
- SSL/TLS : SSL/TLS を有効にする場合は、次のいずれかを含むデータソースの証明書をアップロードする必要があります。
  - CA証明書のみ
  - クライアント証明書とクライアントキー
  - CA証明書、クライアント証明書、クライアントキー
ターゲット接続プロファイルを入力します。
- ユーザー名: TiDB Cloudのターゲットクラスターのユーザー名を入力します。
- パスワード: TiDB Cloudユーザー名のパスワードを入力します。
入力した情報を検証するには、 「接続の検証」と「次へ」をクリックします。
表示されるメッセージに従ってアクションを実行します。
- パブリック IP または VPC ピアリングを使用する場合は、データ移行サービスの IP アドレスをソースデータベースとファイアウォール (存在する場合) の IP アクセスリストに追加する必要があります。
- AWS Private Link を使用する場合は、エンドポイントリクエストを承認するように求められます。1 に移動し、 「エンドポイントサービス」 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: 移行するオブジェクトを選択する

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

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

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

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

エラーと解決策の詳細については、エラーと解決策を事前に確認する参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

制限事項

前提条件

Amazon RDS および Amazon Aurora MySQL の場合

Google Cloud SQL for MySQLの場合

Azure Database for MySQLの場合

Alibaba Cloud RDS MySQLの場合

セルフホスト型MySQLインスタンスの場合

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

ステップ2: ソースとターゲットの接続を構成する

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

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

GTIDを指定する

binlogファイルの名前と位置を指定する

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

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

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

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

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