Data Transmission Service (DTS) を使用して、PolarDB-X 1.0 インスタンスから PolarDB for MySQL クラスターへ増分データをリアルタイムで同期します。
前提条件
開始する前に、以下の点を確認してください。
PolarDB-X 1.0 インスタンスが作成されます。 詳細については、「PolarDB-X 1.0 インスタンスを作成する」および「データベースを作成する」をご参照ください。PolarDB-X 1.0PolarDB-X 1.0PolarDB-X 1.0PolarDB-X 1.0PolarDB-X 1.0PolarDB-X 1.0 インスタンスを作成するデータベースを作成する
PolarDB-X 1.0 インスタンスのストレージタイプは、ApsaraDB RDS for MySQL(カスタムインスタンスおよび購入済みインスタンスを含む)である必要があります。PolarDB for MySQL はストレージタイプとして使用できません。
宛先となる PolarDB for MySQL クラスターが作成済みである。詳細については、「Enterprise Edition クラスターの購入」および「サブスクリプションクラスターの購入」をご参照ください。
宛先クラスターの利用可能なストレージ容量が、ソースインスタンス内の全データサイズより大きいこと。
課金
| 同期タイプ | 料金 |
|---|---|
| スキーマ同期および初期完全同期 | 無料 |
| 増分同期 | 課金済み。詳細については、「課金概要」をご参照ください。 |
サポートされる同期トポロジ
単方向・一対一同期
単方向・一対多同期
単方向・カスケード同期
単方向・多対一同期
詳細については、「同期トポロジ」をご参照ください。
同期可能な SQL 操作
| 操作タイプ | SQL ステートメント |
|---|---|
| DML | INSERT、UPDATE、DELETE |
必要なデータベースアカウント権限
| データベース | 必要な権限 | 参考情報 |
|---|---|---|
| ソース PolarDB-X 1.0 インスタンス | 同期対象オブジェクトに対する読み取り権限 | アカウントの管理 |
| 宛先 PolarDB for MySQL クラスター | 同期対象オブジェクトの宛先クラスターに対する読み取りおよび書き込み権限 | データベースアカウントの作成と管理 |
制限事項
テーブル構造に関する要件
テーブルには、すべてのフィールドが一意である PRIMARY KEY 制約または UNIQUE 制約が必要です。これらの制約がない場合、宛先データベースに重複レコードが発生する可能性があります。
UNIQUE 制約のみを持つテーブルは、スキーマ同期をサポートしません。代わりに、PRIMARY KEY 制約を持つテーブルを使用してください。
セカンダリインデックスを持つテーブルは同期できません。
テーブルを同期対象として選択し、宛先でテーブル名またはカラム名を変更する場合は、1 つのタスクで最大 5,000 テーブルまでサポートされます。5,000 テーブルを超える場合は、複数のタスクに分割するか、データベース全体を同期してください。
接続された ApsaraDB RDS for MySQL インスタンスのバイナリログ要件
| パラメーターまたは要件 | 必須値 | 備考 |
|---|---|---|
| バイナリログ記録 | 有効 | DTS はバイナリログから変更を読み取ります。 |
binlog_row_image | full | その他の値では事前チェックが失敗します。 |
| バイナリログ保持期間(増分同期のみ) | 最低 24 時間 | 初期完全同期が完了した後は、この期間を 24 時間より長く設定できます。 |
| バイナリログ保持期間(完全+増分同期) | 最低 7 日間 | DTS は初期の完全同期フェーズで古いバイナリログを必要とします。 |
バイナリログが DTS による読み取り前にパージされると、タスクが失敗し、データの不整合や損失が発生する可能性があります。これらの最小保持期間を下回る設定は行わないでください。これらの要件を満たすことは、DTS サービスレベルアグリーメント(SLA)で定められた信頼性およびパフォーマンスを維持するために不可欠です。
サポートされていない構成
垂直分割はサポートされていません。PolarDB-X 1.0 のストレージリソースは、水平分割(データベースおよびテーブル単位)のみ可能です。PolarDB-X 1.0
PolarDB-X 1.0 のコンピュートレイヤーにおける読み取り専用インスタンスはサポートされていません。PolarDB-X 1.0
PolarDB-X 1.0 インスタンスのストレージタイプは、ApsaraDB RDS for MySQL である必要があります。PolarDB for MySQL はストレージタイプとして使用できません。PolarDB-X 1.0PolarDB-X 1.0
同期中の運用制限
同期タスク実行中に、以下の操作は行わないでください。
PolarDB-X 1.0 インスタンスのネットワークタイプを変更します。変更する必要がある場合は、変更後に DTS タスクのネットワーク接続情報を更新してください。PolarDB-X 1.0
ソースインスタンスまたはアタッチされた ApsaraDB RDS for MySQL インスタンスをスケールしてください。
アタッチされた ApsaraDB RDS for MySQL インスタンスに設定された論理データベースまたは論理テーブルの物理データベースのディストリビューションを変更します。
ホットテーブルを移行する、シャードキーを変更する、またはソースインスタンスでオンライン DDL 操作を実行する。
これらの操作は、同期タスクの失敗またはデータの不整合を引き起こす可能性があります。
その他の制限事項
データは接続された ApsaraDB RDS for MySQL インスタンスに分散されています。DTS は各 ApsaraDB RDS for MySQL インスタンスに対して個別のサブタスクを実行します。サブタスクのステータスは、PolarDB-X 1.0タスクトポロジで確認できます。
初期完全同期では、ソースおよび宛先データベースの読み取りおよび書き込みリソースが使用され、負荷が増加します。ピーク時を避けて同期を実行してください。
初期完全同期中の並列 INSERT 操作により、宛先テーブルで断片化が発生します。完全同期完了後、宛先の表領域はソースよりも大きくなります。
同期対象オブジェクトに対する DDL 操作で gh-ost や pt-online-schema-change を使用しないでください。これによりタスクが失敗する可能性があります。
宛先データベースへの書き込みは、DTS を通じてのみ行ってください。Data Management (DMS) によるオンライン DDL 操作実行中に、他のツールが宛先に書き込むと、宛先でデータ損失が発生する可能性があります。
外部キーの動作
スキーマ同期中、DTS はソースデータベースから宛先データベースへ外部キーを同期します。
完全同期および増分同期中、DTS はセッションレベルで外部キー制約チェックおよびカスケード操作を一時的に無効化します。同期中にソースデータベースでカスケード更新または削除操作を実行すると、データの不整合が発生する可能性があります。
データ同期タスクの作成
概要手順は以下のとおりです。
ソースおよび宛先データベースを構成します。
同期対象オブジェクトを選択し、高度な設定を構成します。
事前チェックを実行します。
データ同期インスタンスを購入します。
ステップ 1:データ同期タスクページへ移動
Data Management (DMS) コンソールにログインします。
上部ナビゲーションバーで、Data + AI をクリックします。
左側ナビゲーションウィンドウで、DTS (DTS) > データ同期 を選択します。
ナビゲーションオプションは、コンソールモードとレイアウトによって異なる場合があります。 詳細については「シンプルモード」を、レイアウトを変更するには「DMS コンソールのレイアウトとスタイルをカスタマイズする」をご参照ください。 または、「新しい DTS コンソールのデータ同期タスクページ」に直接移動することもできます。
ステップ 2:ソースおよび宛先データベースの構成
データ同期インスタンスが配置されるリージョンを選択します。
新 DTS コンソールでは、上部ナビゲーションバーでリージョンを選択します。
タスクの作成 をクリックします。表示される データ同期タスクの作成 ウィザードで、以下の表に示すパラメーターを構成します。
警告ソースおよび宛先データベースの構成後は、次に進む前に画面上に表示される 使用制限 を必ずご確認ください。これらの制限を無視すると、タスクの失敗やデータの不整合が発生する可能性があります。
ソースデータベース
パラメーター 説明 タスク名 DTS タスクの名前です。DTS が自動的に生成しますが、タスクを識別しやすくするために、意味のある名前を指定することを推奨します。名前は一意である必要はありません。 データベースタイプ PolarDB-X 1.0 を選択します。 アクセス方法 Alibaba Cloud インスタンス を選択します。 インスタンスリージョン ソース PolarDB-X 1.0 インスタンスが配置されているリージョンです。 インスタンス ID ソース PolarDB-X 1.0 インスタンスの ID です。 データベースアカウント ソースインスタンスのデータベースアカウントです。必要な権限については、「必要なデータベースアカウント権限」をご参照ください。 データベースパスワード データベースアカウントのパスワードです。 宛先データベース
パラメーター 説明 データベースタイプ PolarDB for MySQL を選択します。 アクセス方法 Alibaba Cloud インスタンス を選択します。 インスタンスリージョン 宛先 PolarDB for MySQL クラスターが配置されているリージョンです。 PolarDB クラスター ID 宛先 PolarDB for MySQL クラスターの ID です。 データベースアカウント 宛先クラスターのデータベースアカウントです。必要な権限については、「必要なデータベースアカウント権限」をご参照ください。 データベースパスワード データベースアカウントのパスワードです。 「[接続性のテストと続行]」をクリックします。DTS は、自動的にそのサーバーの CIDR ブロックを、Alibaba Cloud データベースインスタンス(例:ApsaraDB RDS for MySQL)のホワイトリストおよび Elastic Compute Service (ECS) でホストされるデータベースのセキュリティグループルールに追加します。データセンターまたはサードパーティクラウド上の自己管理データベースの場合は、CIDR ブロックを手動で追加してください。詳細については、「DTS サーバーの CIDR ブロック」セクションをご参照ください。
警告DTS サーバーの CIDR ブロックをホワイトリストまたはセキュリティグループルールに追加することは、セキュリティリスクを伴います。続行する前に、以下の予防措置を講じてください:- 強力で一意なユーザー名およびパスワードを使用する。- 公開ポートを最小限に抑える。- API 呼び出しを認証する。- ホワイトリストおよびセキュリティグループルールを定期的に確認し、不正な CIDR ブロックをブロックする。- Express Connect、VPN Gateway、または Smart Access Gateway を使用して、データベースと DTS を接続する。
ステップ 3:オブジェクトの選択および高度な設定の構成
同期設定を構成します。
パラメータ 説明 同期タイプ 増分同期 はデフォルトで選択されています。また、スキーマ同期 と 全データ同期 を選択します。DTS は、まずソースから宛先へ既存データを同期し、増分同期のベースラインとします。 競合するテーブルの処理モード 事前チェックとエラー報告 (デフォルト): DTS は、宛先にソースと同じ名前のテーブルがないかチェックします。同じ名前が存在する場合、事前チェックは失敗し、タスクを開始できません。宛先テーブルを削除または名前変更せずに名前解決の競合を解決するには、オブジェクト名マッピングを使用します。詳細については、「オブジェクト名マッピング」をご参照ください。エラーを無視して続行: 同一名のチェックをスキップします。このオプションは注意して使用してください。データの不整合が発生する可能性があります。このオプションでは、全同期中、宛先レコードがソースレコードと同じプライマリキーまたは一意キー値を持つ場合、宛先レコードは保持されます。増分同期中、宛先レコードは上書きされます。スキーマが異なる場合、初期化が失敗する可能性があり、または一部のカラムのみが同期されます。 宛先インスタンスのオブジェクト名の大文字/小文字 DTS デフォルトポリシー はデフォルトで選択されています。これを、ご利用のソースまたはターゲットデータベースの大文字/小文字に一致するように変更します。詳細については、「宛先インスタンスのオブジェクト名の大文字/小文字の指定」をご参照ください。 ソースオブジェクト セクションで同期対象オブジェクトを選択し、
をクリックして 選択済みオブジェクト セクションに移動します。同期対象として、データベース全体ではなくテーブルを選択することを推奨します。データベース全体を選択した場合、DTS はソースから宛先への CREATE TABLE および DROP TABLE 変更を同期しません。
(任意)選択済みオブジェクト セクションで、以下の操作を行えます。
送信先で単一のオブジェクトの名前を変更するには、そのオブジェクトを右クリックします。詳細については、「単一のオブジェクトの名前をマップする」セクションをご参照ください。
複数のオブジェクトを一度に名前変更するには、右上隅の [一括編集] をクリックします。詳細については、「複数のオブジェクト名を一度にマップする」をご参照ください。
テーブルに対して特定の SQL 操作を選択するには、該当オブジェクトを右クリックし、操作を選択します。サポートされる操作については、「同期可能な SQL 操作」をご参照ください。
条件に基づいて行をフィルターするには、該当オブジェクトを右クリックし、WHERE 句を指定します。詳細については、「フィルター条件の指定」をご参照ください。
次へ:高度な設定 をクリックし、以下のパラメーターを構成します。
パラメーター 説明 モニタリングとアラート 有効な値: いいえ(アラート機能を有効にしません)または [はい](アラート機能を設定します)。タスクが失敗した場合や同期遅延がしきい値を超えた場合に通知を受信するには、[はい] を選択してください。アラートのしきい値と通知先連絡先を設定します。詳細については、「DTS タスクを作成するときにモニタリングとアラートを設定する」セクションをご参照ください。 失敗した接続の再試行時間 タスク開始後の失敗した接続に対する DTS の再試行期間です。有効値:10~1440 分。デフォルト値:720 分。30 分より大きい値を設定してください。この期間内に DTS が再接続できた場合、タスクは再開されます。それ以外の場合、タスクは失敗します。 説明複数のタスクが同じソースまたは宛先データベースを共有する場合、最も短い再試行期間設定がすべてのタスクに適用されます。再試行試行中は DTS インスタンスの課金が発生します。再試行時間は、ビジネス要件に基づいて設定することを推奨します。また、ソースおよび宛先インスタンスが解放された直後に、DTS インスタンスをできるだけ早期に解放することもできます。
ETL の構成 ETL (抽出・変換・書き出し) 機能を有効にするには、[はい] を選択し、コードエディタにデータ処理ステートメントを入力します。この機能の概要については、「ETL とは」をご参照ください。構成手順については、「データ移行またはデータ同期タスクで ETL を構成する」をご参照ください。
ステップ 4:事前チェックの実行
次へ:タスク設定の保存と事前チェック をクリックします。この構成の API パラメーターを表示するには、ボタンにカーソルを合わせて、保存前に OpenAPI パラメーターのプレビュー をクリックします。
事前チェックに合格するまで、タスクは開始できません。
事前チェック結果を確認します。
項目が失敗した場合、詳細の表示 をクリックして原因を確認し、問題を修正した後、再チェック をクリックします。
無視可能な項目でアラートがトリガーされた場合、アラート詳細の確認 > 無視 > OK をクリックし、その後 再チェック をクリックします。アラートを無視すると、データの不整合が発生する可能性があります。
成功率 が 100% になるまで待機し、次へ:インスタンスの購入 をクリックします。
ステップ 5:データ同期インスタンスの購入
購入ページで、以下のパラメーターを構成します。
パラメーター 説明 課金方法 サブスクリプション:一定期間の前払い。長期利用にコスト効率的です。従量課金:時間単位で課金されます。短期利用に適しています。不要になった時点でインスタンスを解放することで、課金を停止できます。 リソースグループ設定 データ同期インスタンスのリソースグループです。デフォルト: default resource groupResource Management とは インスタンスクラス インスタンスクラスは同期速度を決定します。スループット要件に基づいてクラスを選択してください。詳細については、「データ同期インスタンスのインスタンスクラス」をご参照ください。 サブスクリプション期間 サブスクリプション 課金方法でのみ利用可能です。選択肢:1~9 ヶ月、1 年、2 年、3 年、または 5 年です。 お読みのうえ、[Data Transmission Service(従量課金)サービス利用規約] を選択してください。
購入して開始 をクリックします。表示されるダイアログボックスで、OK をクリックします。
タスクはタスクリストに表示されます。そこで進行状況を監視できます。