重要

このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

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

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

既存のデータ、または既存のデータと増分データの両方を移行する方法については、データ移行を使用して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 sschema
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

次の 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 モードは正常に有効化されています。

セルフホスト型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 および VPC ピアリングの場合): データソースのホスト名または IP アドレス。
- サービス名(プライベートリンクの場合): エンドポイントサービス名。
- ポート: データソースのポート。
- ユーザー名: データソースのユーザー名。
- パスワード: ユーザー名のパスワード。
- SSL/TLS : SSL/TLS を有効にする場合は、次のいずれかを含むデータソースの証明書をアップロードする必要があります。
  - CA証明書のみ
  - クライアント証明書とクライアントキー
  - CA証明書、クライアント証明書、クライアントキー
ターゲット接続プロファイルを入力します。
- ユーザー名: TiDB Cloudのターゲットクラスターのユーザー名を入力します。
- パスワード: TiDB Cloudユーザー名のパスワードを入力します。
入力した情報を検証するには、 「接続の検証」と「次へ」をクリックします。
表示されるメッセージに従ってアクションを実行します。
- パブリック IP または VPC ピアリングを使用する場合は、データ移行サービスの IP アドレスをソースデータベースとファイアウォール (存在する場合) の IP アクセスリストに追加する必要があります。
- AWS Private Link を使用する場合は、エンドポイント要求を受け入れるように求められます。 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: 移行の進行状況をビュー

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

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

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

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

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