RDS for MySQL インスタンスから PolarDB for MySQL クラスターへのデータをワンクリックでクローン作成する方法 - PolarDB

ワンクリッククローン機能では、既存の ApsaraDB RDS for MySQL インスタンスから PolarDB for MySQL クラスターを作成し、アカウント、データベース、IP ホワイトリスト、および主要なパラメーターをコピーします。クローン作成開始後にソースインスタンスに書き込まれた増分データは、新しいクラスターに同期されません。

移行中の増分データ同期については、「ApsaraDB RDS for MySQL インスタンスをアップグレードして PolarDB for MySQL クラスターを作成」をご参照ください。

クローン作成機能は無料で利用でき、クローン作成プロセス中にデータ損失は発生しません。

移行方法の選択

ワンクリッククローンでは、物理移行と論理移行（Data Transmission Service (DTS) 経由）の 2 つの方法がサポートされています。適用される方法は、ソースインスタンスの MySQL バージョン、エディション、およびストレージタイプによって異なります。

ソースインスタンスが次のいずれかの場合...	移行方法
RDS MySQL 5.6 または 5.7、High-availability Edition、ローカル SSD、かつクローン先の MySQL バージョンが同一の場合	物理移行
その他の組み合わせ（MySQL 8.0、クラウドディスク、異なるターゲットバージョンなど）	論理移行

物理移行では、DTS を介さずにソースインスタンスから完全データを直接コピーします。処理が高速であり、ソースインスタンスの運用に影響を与えません。

論理移行では、DTS のデータ同期タスクを作成してスキーマおよび完全データを移行します。より広範なソース構成に対応し、クロスバージョンのクローン作成も可能ですが、DTS 固有の制限が適用されます。

いずれの方法でも、増分データの同期およびクロスリージョン移行はサポートされていません。

対応バージョンおよびストレージタイプ

以下の表は、RDS エディションおよび MySQL バージョンごとに利用可能なストレージタイプを示しています。物理移行は、RDS MySQL 5.6 または 5.7、High-availability Edition、ローカル SSD、かつクローン先の MySQL バージョンが同一の場合のみ適用されます。その他のすべての組み合わせでは論理移行が使用されます。

RDS エディション	MySQL 5.6	MySQL 5.7	MySQL 8.0
Basic Edition	該当なし	クラウドディスク	クラウドディスク
High-availability Edition	ローカル SSD	ローカル SSD およびクラウドディスク	ローカル SSD およびクラウドディスク
Cluster Edition	該当なし	クラウドディスク	クラウドディスク
Enterprise Edition	ローカル SSD	ローカル SSD	ローカル SSD

課金

物理移行：データ移行には課金されません。PolarDB クラスターのみが課金対象となります。「課金対象項目の概要」をご参照ください。
論理移行：DTS 同期タスクは、作成後最初の 30 日間は無料です。30 日を経過すると、タスクは自動的にキャンセルされます。この無料トライアルは、仮想ネットワーク事業者（VNO）アカウントおよび Resource Access Management (RAM) ユーザーには適用されません。

前提条件

開始前に、以下の条件を確認してください。

ターゲットの PolarDB クラスターは、ソースインスタンスと同じまたはそれより後の MySQL バージョンを実行している必要があります。バージョンダウンはサポートされていません（例：RDS MySQL 5.7 インスタンスを PolarDB for MySQL 5.6 クラスターにクローン作成することはできません）。

物理移行の場合のみ：

ソースインスタンスが最低マイナーバージョンを満たしている必要があります。マイナーバージョンを確認するには、ソースインスタンスで次の文を実行します。
- RDS MySQL 5.6：マイナーバージョン 20190815 以降
- RDS MySQL 5.7：マイナーバージョン 20200331 以降
```
SHOW VARIABLES LIKE '%rds_release_date%';
```
マイナーバージョンが要件を満たしていない場合は、続行前にアップグレードしてください。「マイナーエンジンバージョンの更新」をご参照ください。
テーブルストレージエンジンが InnoDB または X-Engine である必要があります。他のエンジンを使用しているテーブルを特定するには、次の文を実行します。
```
SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'performance_schema', 'sys')
  AND ENGINE NOT IN ('InnoDB', 'X-Engine');
```
クローニングする前に、返されるテーブルを変換します。
ソースインスタンスで透過的データ暗号化（TDE）および SSL が無効化されている必要があります。「TDE」および「SSL」をご参照ください。TDE または SSL が有効化されており、無効化できない場合は、代わりに DTS を使用してデータを手動で移行してください。「ApsaraDB RDS for MySQL インスタンスから PolarDB for MySQL クラスターへのデータ移行」をご参照ください。
データベースプロキシ（セーフモード）が有効化されている場合、特権アカウントを作成するか、ネットワーク接続モードを高性能モードに切り替えてください。「アカウントの作成」および「ApsaraDB RDS インスタンスのネットワーク接続モードのアップグレード」をご参照ください。

論理移行の場合のみ：

移行を開始する前に、以下の事前チェックを両方とも完了してください。

事前チェック 1：サービスタイプリンクロールの確認

論理移行では、アカウント内に AliyunServiceRoleForPolarDB サービスタイプリンクロールが存在する必要があります。存在しない場合は、続行前に作成してください。

Resource Access Management (RAM) コンソールにログインし、ロール ページを開きます。
AliyunServiceRoleForPolarDB が一覧に表示されているか確認します。ロールが存在する場合は、「事前チェック 2」に進んでください。
ロールの作成 をクリックします。ロールタイプの選択 ステップで、Alibaba Cloud サービス を選択し、次へをクリックします。
ロールの設定 ステップで、ロールタイプ を サービスリンクロール に設定し、サービスの選択 リストから ApsaraDB for PolarDB を選択します。
OK をクリックし、ロールが一覧に表示されることを確認します。

事前チェック 2：ソースインスタンスからの不要なシステムアカウントの削除

各 RDS MySQL バージョンには指定されたシステムアカウントがあります。ソースインスタンスに root と aliyun_root の両方が同時に存在する場合、クローン作成時に送信先の PolarDB クラスターのシステムアカウントが上書きされる可能性があります。開始前に、不要なシステムアカウントをすべて削除してください。

RDS MySQL バージョン	正しいシステムアカウント
RDS MySQL 5.6	`root`
RDS MySQL 5.7	`aliyun_root`
RDS MySQL 8.0	`aliyun_root`

不要なシステムアカウントは、手動で作成されたものや、以前のバージョンアップから継承されたものである可能性があります。一部のアカウントはコンソール上には表示されない場合があります。

例：RDS MySQL 5.6 からの不要なアカウントの削除

MySQL 5.6 の正しいアカウントは root です。aliyun_root も存在する場合、これを削除します。

特権アカウントでデータベースに接続します。

存在するシステムアカウントを確認します。

SELECT * FROM mysql.user WHERE `user` IN ('root', 'aliyun_root');

不要なアカウントを削除します。続行前に、そのアカウントがワークロードで使用されていないことを確認してください。
```
DELETE FROM mysql.user WHERE `user` = 'aliyun_root' LIMIT n;
```

論理移行のソースインスタンスに関する制限事項：

テーブルには PRIMARY KEY または一意制約（UNIQUE constraint）が必要であり、すべてのフィールドが一意である必要があります。これらの制約がないテーブルは、送信先クラスターで重複データを生成する可能性があります。
個別のテーブル（データベース全体ではなく）を同期オブジェクトとして選択し、テーブル名またはカラム名を変更する必要がある場合、1 つのタスクで最大 1,000 個のテーブルをサポートします。1,000 個を超えるテーブルを同期する場合は、複数のタスクを使用するか、データベース全体を同期してください。
バイナリロギングが有効化されている必要があります。また、binlog_row_image は full に設定する必要があります。「インスタンスパラメーターの変更」をご参照ください。
非ピーク時間帯に移行をスケジュールしてください。初期完全同期では、ソースおよび送信先の読み取り／書き込みリソースが使用されるため、データベース負荷が増加する可能性があります。
初期完全同期が完了した後、送信先の表領域は、同時 INSERT 操作による断片化の影響で、ソースよりも大きくなる場合があります。
同期中のテーブルに対して DDL 操作を実行する際、gh-ost や pt-online-schema-change を使用しないでください。オンライン DDL が必要な場合は、「Data Management (DMS)」をご利用ください。
DTS では、送信先の FOREIGN KEY 制約がデフォルトで無効化されます。ソースからの CASCADE および DELETE 操作はレプリケーションされません。
同期中は、DTS を通じてのみ送信先にデータを書き込んでください。他のソースからの書き込みは、データの不整合または損失を引き起こす可能性があります。

ステップ 1：クローン作成によるクラスターの作成

PolarDB コンソールにログインします。
左上隅で、ソース RDS インスタンスがデプロイされているリージョンを選択します。
クラスターの作成 をクリックします。

課金方法 を サブスクリプション、従量課金、または サーバーレス に設定します。

課金方法	動作の仕組み
サブスクリプション	コンピュートノードの料金を前払いします。ストレージは、実際の使用量に基づき時間単位で課金されます。
従量課金	前払いは不要です。コンピュートノードおよびストレージは、実際の使用量に基づき時間単位で課金されます。
サーバーレス	前払いは不要です。コンピュートノード、ストレージ、および PolarProxy が自動的にスケールします。実際のリソース使用量に基づき課金されます。

以下のパラメーターを設定します。ここに記載されていないパラメーターについては、「クラスターの購入」をご参照ください。

パラメーター	説明
作成方法	RDS からのクローン作成を選択します。
リージョン	ソース RDS インスタンスがデプロイされているリージョン。送信先の PolarDB クラスターは、同じリージョンに配置する必要があります。
ソース RDS バージョン	ソース RDS インスタンスの MySQL バージョン：5.6、5.7、または 8.0。
ソース RDS インスタンス	ソース RDS インスタンス。読み取り専用インスタンスは一覧に表示されません。
データベースエンジン	送信先の PolarDB クラスターの MySQL バージョン。ソースと同一でも、異なるものでも構いません。
ノードスペック	コンピュートノードのスペック。ソースインスタンスと同等またはそれ以上のスペックを選択してください。「PolarDB for MySQL Enterprise Edition のコンピュートノードスペック」をご参照ください。

右上隅でクラスター設定を確認します。サブスクリプションクラスターの場合は、期間、数量、および 自動更新 を設定します。
利用規約を読み、同意した上で、注文の確定 をクリックします。
購入ページで注文内容および支払方法を確認し、購入をクリックします。
10～15 分待ち、その後 クラスター ページで新しいクラスターを確認します。クラスターのステータスが 作成中 から 実行中 に変わると、準備完了です。正しいリージョンが選択されていることを確認してください。

ステップ 2：移行ステータスの確認

クラスターが作成された後、移行が正常に完了したかを確認します。

PolarDB コンソールにログインし、クラスター ページに移動します。
新しいクラスターの ID をクリックして、基本情報 ページを開きます。
RDS 移行 セクションを確認します。例：ソースインスタンスにトリガーが存在する場合、事前チェックは「RDS インスタンスにトリガーが存在します」というエラーで失敗します。トリガーを削除して 移行の続行 をクリックするか、「トリガーを含むソースデータベース向けのデータ同期タスクの設定」をご参照ください。
- ステータスが 実行中 の場合、移行は正常に進行しています。
- ステータスが 事前チェック失敗 の場合、エラーメッセージに従って問題を修正し、移行の続行 をクリックします。あるいは、移行のキャンセル をクリックして、手動で DTS 同期タスクを作成することもできます。

ステップ 3：DTS タスクの詳細表示（論理移行の場合のみ）

論理移行が使用されており、事前チェック失敗や高レプリケーション遅延などのエラーを調査する必要がある場合、DTS タスクの詳細を表示します。

PolarDB コンソールにログインし、クラスター ID をクリックします。
基本情報 ページで RDS 移行 セクションを見つけ、DTS データ同期タスク をクリックします。
DTS コンソールでデータ同期タスクを見つけます。このページから、事前チェック失敗の詳細、タスクステータス、およびタスクログを確認できます。

よくある質問

RDS インスタンスのクローン作成と PolarDB へのアップグレードの違いは何ですか？

	RDS を PolarDB にアップグレード	RDS を PolarDB にクローン作成
増分データ同期	はい	なし
ソースインスタンスへの影響	なし	なし
クロスバージョン移行	はい	はい

クローン作成では、ソースインスタンスとの同期を維持せず、ソースデータの独立したコピーを作成します。一方、アップグレードでは、移行中にソースと送信先を同期したままにするため、データ損失を最小限に抑えて切り替えが可能です。

クローン作成はソース RDS インスタンスに影響を与えますか？

いいえ。クローン作成はソースインスタンスの中断を引き起こしませんが、プロセス中に一部のリソースを消費します。

移行をキャンセルするとどうなりますか？

移行をキャンセルすると、以下の影響があります。

ソースインスタンスと送信先クラスター間の同期リンクが切断されます。
送信先クラスターは読み取り／書き込み可能になりますが、自動的にリリースされません。今後使用しない場合は、課金を避けるためにクラスターを手動でリリースしてください。
手動でキャンセルする際に、クラスターのバイナリロギングを無効化するかどうかを選択できます。自動キャンセル時には、バイナリロギングは無効化されません。

バイナリロギングを無効化すると、書き込みパフォーマンスがわずかに向上します。無効化後も、既存のバイナリログは保持されます。これらを削除するには、保持期間を短縮してログが自動削除されるのを待った後、バイナリロギングを無効化してください。バイナリロギングを無効化すると、クラスターは自動的に再起動します。再起動は 5 分以内に完了し、サービス中断は約 40 秒間発生します。正確な所要時間は、データ量およびテーブル数によって異なります。バイナリロギングの無効化は、非ピーク時間帯に行い、アプリケーションが自動的に再接続できるよう設定してください。

API リファレンス

API	操作
CreateDBCluster	PolarDB クラスターを作成します。RDS インスタンスからクローン作成するには、`CreationOption` を `CloneFromRDS` に設定します。

次のステップ

アプリケーションのデータベース接続エンドポイントを、PolarDB クラスターのエンドポイントに更新します。「クラスターのエンドポイントの管理」をご参照ください。