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 読み取り専用レプリカ インスタンスからデータを移行できません。
移行ジョブを実行する
最初の完全ダンプを取得するには、MySQL Amazon Aurora の書き込みを移行元データベースで約 20 秒間停止する必要があります。 スクリプトを使用して、ソース データベースへの書き込みがすべて停止されていることを確認できます。
書き込みを停止および再開するタイミングは、移行ジョブのステータスとサブステータスに示されます。ステータスの変更は、API、コンソール、または Cloud Monitoring で直接追跡できます。
ステータスが Starting | Waiting for source writes to stop に変更されたら、移行元データベースへの書き込みを停止する必要があります。Database Migration Service は書き込みが停止したことを検出し、ステータスが [実行中 | ダンプ準備中] に変わります。
ステータスが [実行中 | 完全なダンプの処理中] に変わったら、移行元データベースへの書き込みを再開できます。
Database Migration Service は、約 20 分間、初期ダンプを取ろうとし続けます。書き込みが停止されていない場合、またはステータスの更新前に書き込みが再開された場合、プロセスは失敗し、失敗の原因を示すエラーが返されます。