Amazon Aurora MySQL ソースまたは SUPERUSER 権限を許可しないソースを使用して移行ジョブを作成して実行する場合、移行に追加の手順が必要になることがあります。
Amazon Aurora MySQL 移行ジョブを作成する
次の要件を考慮して、移行プロセスを調整してください。
MySQL では、送信元ホスト名の定義が 60 文字に制限されています。Amazon Aurora データベースのホスト名は通常、60 文字を超えます。移行するデータベースがこれに該当する場合は、DNS リダイレクトを構成して、ドメイン名を Amazon Aurora データベース インスタンスのドメイン名に関連付ける CNAME レコードを作成します。DNS CNAME の設定の詳細については、Cloud DNS のドキュメントまたは AWS Route53 のドキュメントをご覧ください。
バイナリログは標準のブロック ストレージに保存する必要があり、Amazon S3 に保存することはできません。
手動ダンプを指定して継続的な移行ジョブを作成するには、
GTIDを有効にする必要があります。GTID_MODEは、ON、OFF、または OFF_PERMISSIVE のいずれかにする必要があります。ON_PERMISSIVE のGTID_MODE値はサポートされていません。最初の完全ダンプを取得するには、移行元データベースで MySQL Amazon Aurora の書き込みを約 20 秒間停止します。
バイナリログファイルをインスタンスから取得できないため、Database Migration Service は MySQL データベース クラスタの Amazon Aurora 読み取り専用レプリカ インスタンスからデータを移行できません。詳細については、 Aurora MySQL バイナリログの構成に関する Amazon のドキュメントをご覧ください。
移行ジョブを実行する
最初の完全ダンプを取得するには、移行元データベースで MySQL Amazon Aurora の書き込みを約 20 秒間停止します。 書き込みアクティビティを検索するスクリプトを使用して、ソース データベースへのすべての書き込みが停止したことを確認できます。
書き込みを停止して再開するタイミングは、移行ジョブのステータスとサブステータスに示されます。ステータスの変更は、API、コンソール、または Cloud Monitoring で直接追跡できます。
ステータスが [Starting | Waiting for source writes to stop] に変わったら、移行元データベースへの書き込みを停止する必要があります。Database Migration Service は書き込みが停止したことを検出し、ステータスが [実行中 | ダンプの準備中] に変わります。
ステータスが [実行中 | 完全なダンプの処理中] に変わったら、移行元データベースへの書き込みを再開しても安全です。
Database Migration Service は、約 20 分間、初期ダンプの取得を試行し続けます。書き込みが停止されていない場合、またはステータスの更新前に書き込みが再開された場合、プロセスは失敗し、失敗の原因を説明するエラーが返されます。