# Amazon Aurora MySQL DB クラスターへのデータの移行 既存のデータベースから Amazon Aurora MySQL DB クラスターにデータを移行するために、複数のオプションがあります。また、移行オプションは、移行元のデータベースおよび移行するデータのサイズによっても異なります。 移行には物理と論理の 2 つのタイプがあります。物理移行とは、データベースファイルの物理コピーを使用してデータベースを移行することです。論理的な移行とは、挿入、更新、削除などの論理的な変更を適用することでデータベースを移行することです。 物理移行には以下の利点があります。 + 物理移行は、特にデータベースのサイズが大きい場合、論理的な移行よりも高速です。 + 物理移行用にバックアップを作成するとき、データベースのパフォーマンスが低下しません。 + 物理移行では、複雑なデータベースコンポーネントを含め、出典データベースのすべての内容を移行できます。 物理移行には以下の制限があります。 + `innodb_page_size` パラメータは、デフォルト値 (`16KB`) に設定する必要があります。 + `innodb_data_file_path` パラメータは、デフォルトのデータファイル名 `"ibdata1:12M:autoextend"` を使用するデータファイル 1 つのみで設定する必要があります。2 つのデータファイルを持つデータベースや名前が異なるデータファイルを持つデータベースは、この方法では移行できません。 `"innodb_data_file_path=ibdata1:50M; ibdata2:50M:autoextend"` や `"innodb_data_file_path=ibdata01:50M:autoextend"` などのファイル名は使用できません。 + `innodb_log_files_in_group` パラメータは、デフォルト値 (`2`) に設定する必要があります。 論理的な移行には以下の利点があります。 + 特定のテーブルやテーブルの一部など、データベースのサブセットを移行できます。 + データは、物理ストレージ構造に関係なく移行できます。 論理的な移行には以下の制限があります。 + 論理的な移行は通常、物理移行よりも低速です。 + 複雑なデータベースコンポーネントにより、論理的な移行プロセスの速度が遅くなることがあります。場合によっては、複雑なデータベースコンポーネントにより、論理的な移行がブロックされることさえあります。 以下の表に示しているのは、移行のオプションと各オプションで使用する移行のタイプです。 | 移行元 | 移行タイプ | ソリューション | | --- | --- | --- | | RDS for MySQL DB インスタンス | 物理 | まず MySQL DB インスタンスの Aurora MySQL リードレプリカを作成することで、RDS for MySQL DB インスタンスから移行できます。MySQL DB インスタンスと Aurora MySQL リードレプリカとの間のレプリカラグが 0 の場合は、クライアントアプリケーションで Aurora リードレプリカから読み取り、レプリケーションを停止することで、Aurora MySQL リードレプリカを読み取りと書き込み用のスタンドアロンの Aurora MySQL DB クラスターにすることができます。詳細については、「[Aurora リードレプリカを使用した、RDS for MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターへのデータの移行](AuroraMySQL.Migrating.RDSMySQL.Replica.md)」を参照してください。 | | RDS for MySQL DB スナップショット | 物理 | RDS for MySQL DB スナップショットから Amazon Aurora MySQL DB クラスターに直接データを移行できます。詳細については、「[Aurora への RDS for MySQL スナップショットの移行](AuroraMySQL.Migrating.RDSMySQL.Snapshot.md)」を参照してください。 | | Amazon RDS 外部の MySQL データベース | 論理 | `mysqldump` ユーティリティを使用してデータのダンプを作成し、そのデータを既存の Amazon Aurora MySQL DB クラスターにインポートできます。詳細については、「[mysqldump を使用した MySQL から Amazon Aurora MySQL への論理的移行](AuroraMySQL.Migrating.ExtMySQL.mysqldump.md)」を参照してください。 外部 MySQL データベースからの移行中にデータベースユーザーのメタデータをエクスポートするには、`mysqldump` の代わりに MySQL Shell コマンドを使用することもできます。詳細については、「[インスタンスダンプユーティリティ、スキーマダンプユーティリティ、テーブルダンプユーティリティ](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html#mysql-shell-utilities-dump-about)」を参照してください。 MySQL 8.0.34 以降、[mysqlpump](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html) ユーティリティは廃止されました。 | | Amazon RDS 外部の MySQL データベース | 物理 | データベースから Amazon Simple Storage Service (Amazon S3) バケットにバックアップファイルをコピーし、これらのファイルから Amazon Aurora MySQL DB クラスターを復元できます。このオプションは、`mysqldump` を使用したデータの移行よりもかなり高速になる場合があります。詳細については、「[Percona XtraBackup と Amazon S3 を使用した MySQL からの物理的な移行](AuroraMySQL.Migrating.ExtMySQL.S3.md)」を参照してください。 | | Amazon RDS 外部の MySQL データベース | 論理 | データベースのデータをテキストファイルとして保存し、そのファイルを Amazon S3 バケットにコピーできます。次に、`LOAD DATA FROM S3` MySQL コマンドを使用して、そのデータを既存の Aurora MySQL DB クラスター内にロードできます。詳細については、「[Amazon S3 バケットのテキストファイルから Amazon Aurora MySQL DB クラスターへのデータのロード](AuroraMySQL.Integrating.LoadFromS3.md)」を参照してください。 | | MySQL と互換性がないデータベース | 論理 | AWS Database Migration Service (AWS DMS) は、MySQL との互換性がないデータベースからのデータを移行するのに使用できます。AWS DMS の詳細については、「[AWS Database Migration Service とは](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)」を参照してください。 | **注記** 外部の MySQL データベースを Amazon RDS に移行する場合、表で説明している移行のオプションは、データベースが InnoDB または MyISAM テーブルスペースをサポートしている場合にのみサポートされます。 Aurora MySQL に移行中の MySQL データベースで `memcached` が使用されている場合は、移行前に `memcached` を削除します。 8.0.11、8.0.13、8.0.15 などの一部の古い MySQL 8.0 バージョンからは Aurora MySQL バージョン 3.05 以上に移行できません。移行する前に MySQL バージョン 8.0.28 にアップグレードすることをお勧めします。 # 外部の MySQL データベースから Amazon Aurora MySQL DB クラスターへのデータ移行 データベースが InnoDB または MyISAM のテーブルスペースをサポートしている場合、これらのオプションを使用して、データを Amazon Aurora MySQL DB クラスターに移行できます。 + `mysqldump` ユーティリティを使用してデータのダンプを作成し、そのデータを既存の Amazon Aurora MySQL DB クラスターにインポートできます。詳細については、「[mysqldump を使用した MySQL から Amazon Aurora MySQL への論理的移行](AuroraMySQL.Migrating.ExtMySQL.mysqldump.md)」を参照してください。 + これで、データベースから Amazon S3 バケットに完全および増分バックアップファイルをコピーし、これらのファイルから Amazon Aurora MySQL DB クラスターを復元できます。このオプションは、`mysqldump` を使用したデータの移行よりもかなり高速になる場合があります。詳細については、「[Percona XtraBackup と Amazon S3 を使用した MySQL からの物理的な移行](AuroraMySQL.Migrating.ExtMySQL.S3.md)」を参照してください。 **Topics** + [Percona XtraBackup と Amazon S3 を使用した MySQL からの物理的な移行](AuroraMySQL.Migrating.ExtMySQL.S3.md) + [mysqldump を使用した MySQL から Amazon Aurora MySQL への論理的移行](AuroraMySQL.Migrating.ExtMySQL.mysqldump.md) # Percona XtraBackup と Amazon S3 を使用した MySQL からの物理的な移行 完全バックアップファイルと増分バックアップファイルをソース MySQL バージョン 5.7 または 8.0 データベースから AmazonAmazon S3 バケットにコピーします。その後、それらのファイルから同じメジャー DB エンジンバージョンの Amazon Aurora MySQL DB クラスターに復元できます。 このオプションは、`mysqldump` を使用したデータ移行よりもかなり高速になる場合があります。これは、`mysqldump` を使用することですべてのコマンドが再生され、新しい Aurora MySQL DB クラスターの出典データベースからスキーマとデータが再作成されるためです。出典 MySQL データファイルをコピーすることで、Aurora MySQL はこれらのファイルを即座に Aurora MySQL DB クラスター用のデータとして使用できます。 また、移行プロセス中にバイナリログレプリケーションを使用してダウンタイムを最小化できます。バイナリログのレプリケーションを使用すると、Aurora MySQL DB クラスターにデータ移動中に外部 MySQL データベースがオープンのままになります。Aurora MySQL DB クラスターが作成されたら、バイナリログレプリケーションを使用して、Aurora MySQL DB クラスターとバックアップ後のトランザクションを同期します。Aurora MySQL DB クラスターが MySQL データベースに追いついたら、Aurora MySQL DB を新規のトランザクションに完全に切り替えて、移行を終了します。詳細については、「[レプリケーションを使用して、Amazon Aurora MySQL DB クラスターと MySQL データベースを同期する](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync)」を参照してください。 **Contents** + [制約事項と考慮事項](#AuroraMySQL.Migrating.ExtMySQL.S3.Limits) + [開始する前に](#AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs) + [Percona XtraBackup のインストール](#AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs.XtraBackup) + [必要なアクセス許可](#AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs.Permitting) + [IAM サービスロールの作成](#AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs.CreateRole) + [Amazon Aurora MySQL DB クラスターとして復元するファイルのバックアップ](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup) + [Percona XtraBackup での完全バックアップの作成](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Full) + [Percona XtraBackup での増分バックアップの使用](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Incr) + [バックアップに関する考慮事項](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Considerations) + [Amazon S3 バケットからの Amazon Aurora MySQL DB クラスターの復元](#AuroraMySQL.Migrating.ExtMySQL.S3.Restore) + [レプリケーションを使用して、Amazon Aurora MySQL DB クラスターと MySQL データベースを同期する](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) + [暗号化レプリケーション用に外部の MySQL データベースと Aurora MySQL DB クラスターを設定する](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync.ConfigureEncryption) + [Amazon Aurora MySQL DB クラスターと外部の MySQL データベースを同期する](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync.Synchronizing) + [Amazon Aurora MySQL への物理的な移行にかかる時間の短縮](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md) + [サポートされていないテーブルタイプ](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Tables) + [サポートされていない権限を持つユーザーアカウント](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Users) + [Aurora MySQL バージョン 3 に対する動的権限](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Dynamic) + [定義者として 'rdsadmin'@'localhost' を使用して保存されたオブジェクト](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Objects) ## 制約事項と考慮事項 Amazon S3 バケットから Amazon Aurora MySQL DB クラスターに移行する場合は、以下の制限と考慮事項が当てはまります。 + データは既存の DB クラスターではなく、新しい DB クラスターにのみ移行できます。 + Percona XtraBackup を使用してデータを S3 にバックアップする必要があります。詳細については、「[Percona XtraBackup のインストール](#AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs.XtraBackup)」を参照してください。 + Amazon S3 バケットと Aurora MySQL DB クラスターは同じ AWS リージョンに存在する必要があります。 + 以下から復元することはできません。 + DB クラスタースナップショットは、Amazon S3 にスナップショットをエクスポートします。また、DB クラスタースナップショットエクスポートから、S3 にデータを移行することはできません。 + 暗号化されたソースデータベース、しかし移行するデータを暗号化することはできます。移行プロセス中にデータを非暗号化のまま維持することもできます。 + MySQL 5.5 または 5.6 データベース + Percona Server for MySQL は、`mysql` スキーマに `compression_dictionary*` テーブルが含まれる場合があるため、ソースデータベースとしてはサポートされていません。 + Aurora Serverless DB クラスターに復元することはできません。 + 後方移行はメジャーバージョンとマイナーバージョンのどちらでもサポートされていません。例えば、MySQL バージョン 8.0 から Aurora MySQL バージョン 2 (MySQL 5.7 と互換性あり) への移行はできませんし、MySQL バージョン 8.0.32 から MySQL コミュニティバージョン 8.0.26 と互換性のある Aurora MySQL バージョン 3.03 への移行もできません。 + 8.0.11、8.0.13、8.0.15 などの一部の古い MySQL 8.0 バージョンからは Aurora MySQL バージョン 3.05 以上に移行できません。移行する前に MySQL バージョン 8.0.28 にアップグレードすることをお勧めします。 + Amazon S3 からのインポートは、db.t2.micro DB インスタンスクラスでサポートされていません。ただし、1 つの DB インスタンスクラスに復元し、後で別の DB インスタンスクラスを変更できます。DB インスタンスクラスの詳細については、「[Amazon Aurora DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。 + Amazon S3 では、S3 バケットにアップロードするファイルのサイズが 5 TB に制限されます。バックアップファイルが 5 TB を超える場合は、バックアップファイルを小さいファイルに分割する必要があります。 + Amazon RDS では、S3 バケットにアップロードするファイルの数が百万までに制限されます。データベースのバックアップデータ（すべての完全および増分バックアップを含む）が百万ファイルを超える場合は、Gzip (.gz)、tar (.tar.gz)、Percona xbstream (.xbstream) ファイルを使用して完全および増分バックアップファイルを S3 バケットに保存します。Percona XtrabackUp 8.0 は Percona xbstream のみを圧縮用にサポートしています。 + 各 DB クラスターに管理サービスを提供するために、DB インスタンスの作成時に `rdsadmin` ユーザーが作成されます。これは RDS の予約ユーザーであるため、以下の制限が適用されます。 + `'rdsadmin'@'localhost'` が定義子である関数、プロシージャ、ビュー、イベント、トリガーは、インポートされません。詳細については、「[定義者として 'rdsadmin'@'localhost' を使用して保存されたオブジェクト](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Objects)」および「[Amazon Aurora MySQL でのマスターユーザー特権](AuroraMySQL.Security.md#AuroraMySQL.Security.MasterUser)」を参照してください。 + Aurora MySQL DB クラスターを作成すると、サポートされている最大の権限を持つマスターユーザーが作成されます。バックアップから復元する際、インポート中のユーザーに割り当てられたサポートされていない権限は、インポート中に自動的に削除されます。 この影響を受ける可能性のあるユーザーを特定するには、「[サポートされていない権限を持つユーザーアカウント](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Users)」を参照してください。Aurora MySQL でサポートされる権限の詳細については、「[ロールベースの特権モデル](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)」を参照してください。 + Aurora MySQL バージョン 3 の場合、動的権限はインポートされません。Aurora がサポートする動的権限は、移行後にインポートできます。詳細については、「[Aurora MySQL バージョン 3 に対する動的権限](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Dynamic)」を参照してください。 + `mysql` スキーマのユーザー作成のテーブルは移行されません。 + `innodb_data_file_path` パラメータは、デフォルトのデータファイル名 `ibdata1:12M:autoextend` を使用するデータファイル 1 つのみで設定する必要があります。2 つのデータファイルを持つデータベースや名前が異なるデータファイルを持つデータベースは、この方法では移行できません。 `innodb_data_file_path=ibdata1:50M`、`ibdata2:50M:autoextend`、および `innodb_data_file_path=ibdata01:50M:autoextend` などのファイル名は使用できません。 + デフォルトの MySQL データディレクトリ外で定義されたテーブルを含むソースデータベースから移行することはできません。 + この方法を使用した非圧縮バックアップでサポートされる最大サイズは、現在 64 TiB に制限されています。圧縮バックアップの場合、圧縮解除に必要な容量を考慮してこの制限は小さくなります。このような場合、サポートされる最大バックアップサイズは (`64 TiB – compressed backup size`) です。 + Aurora MySQL は MySQL やその他の外部コンポーネントやプラグインのインポートをサポートしていません。 + Aurora MySQL は、データベースからすべてを復元するわけではありません。ソース MySQL データベースからデータベーススキーマと以下の項目の値を保存してから、作成後に復元された Aurora MySQL DB クラスターに追加することをお勧めします。 + ユーザーアカウント + 関数 + ストアドプロシージャ + タイムゾーン情報。タイムゾーン情報は、Aurora MySQL DB クラスターのローカルオペレーティングシステムからロードされます。詳細については、「[Amazon Aurora DB クラスターのローカルタイムゾーン](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.LocalTimeZone)」を参照してください。 ## 開始する前に Amazon S3 バケットにデータをコピーし、それらのファイルから DB クラスターを復元するには、事前に以下の作業を行う必要があります。 + Percona XtraBackup をローカルサーバーにインストールします。 + お客様に代わって Aurora MySQL が Amazon S3 バケットにアクセスすることを許可します。 ### Percona XtraBackup のインストール Amazon Aurora では、Percona XtraBackup を使用して作成されたファイルから DB クラスターを復元できます。Percona XtraBackup は、「[ソフトウェアのダウンロード - Percona](https://www.percona.com/downloads)」からインストールできます。 MySQL 5.7 の移行では、Percona XtraBackup 2.4 を使用します。 MySQL 8.0 の移行では、Percona XtraBackup 8.0 を使用します。Percona XtraBackup バージョンがソースデータベースのエンジンバージョンと互換性があることを確認してください。 ### 必要なアクセス許可 MySQL データを Amazon Aurora MySQL DB クラスターに移行するには、複数のアクセス権限が必要です。 + Amazon S3 バケットから新しいクラスターを作成することを Aurora に要求するユーザーは、AWS アカウントのバケットを一覧表示するためのアクセス許可を必要とします。このアクセス許可は、AWS Identity and Access Management (IAM) ポリシーを使用してユーザーに付与します。 + Aurora は、ユーザーに代わって Amazon Aurora MySQL DB クラスターを作成するために必要なファイルが保存されている Amazon S3 バケットにアクセスするためのアクセス許可を必要とします。必要なアクセス許可を Aurora に付与するには、IAM サービスロールを使用します。 + リクエストを実行するユーザーには、AWS アカウントの IAM ロールをリストするアクセス許可も必要です。 + リクエスト元のユーザーが IAM サービスロールを自分で作成したり、(コンソールから) Aurora にIAM サービスロールを作成することを要求したりする場合、そのユーザーには AWS アカウントの IAM ロールを作成するためのアクセス許可が必要です。 + 移行プロセス中にデータを暗号化する場合には、移行を実行するユーザーの IAM ポリシーを更新して、バックアップの暗号化に使用した AWS KMS keys へのアクセス権限を RDS に付与します。手順については、「[AWS KMS リソースにアクセスするための IAM ポリシーの作成](AuroraMySQL.Integrating.Authorizing.IAM.KMSCreatePolicy.md)」を参照してください。 例えば、次の IAM ポリシーでは、コンソールを使用して IAM ロールの一覧表示、IAM ロールの作成、アカウントの Amazon S3 バケットの一覧表示、および KMS キーの一覧表示を行うために必要な最小限のアクセス許可をユーザーに付与します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:ListRoles", "iam:CreateRole", "iam:CreatePolicy", "iam:AttachRolePolicy", "s3:ListBucket", "kms:ListKeys" ], "Resource": "*" } ] } ``` ------ さらに、ユーザーが IAM ロールを Amazon S3 バケットに関連付けるためには、IAM ユーザーに、その IAM ロールの `iam:PassRole` アクセス権限が必要です。このアクセス権限により、ユーザーが Amazon S3 バケットに関連付けることができる IAM ロールを管理者が制限できます。 例えば、次の IAM ポリシーでは、`S3Access` という名前のロールをユーザーが Amazon S3 バケットに関連付けることができます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"AllowS3AccessRole", "Effect":"Allow", "Action":"iam:PassRole", "Resource":"arn:aws:iam::123456789012:role/S3Access" } ] } ``` ------ IAM ユーザーのアクセス許可の詳細については、「[ポリシーを使用したアクセスの管理](UsingWithRDS.IAM.md#security_iam_access-manage)」を参照してください。 ### IAM サービスロールの作成 [**新規ロールの作成**] オプション (このトピックで後述します) を選択して、AWS マネジメントコンソール でロールを作成することができます。このオプションを選択して新しいロールの名前を指定すると、この指定した名前を使用して Aurora から Amazon S3 バケットにアクセスするために必要な IAM サービスロールが Aurora で作成されます。 または、次の手順を使用して手動でロールを作成できます。 **Aurora から Amazon S3 にアクセスするための IAM ロールを作成するには** 1. 「[Amazon S3 リソースにアクセスするための IAM ポリシーの作成](AuroraMySQL.Integrating.Authorizing.IAM.S3CreatePolicy.md)」の各ステップを実行します。 1. 「[Amazon Aurora が AWS のサービスにアクセスすることを許可する IAM ロールの作成](AuroraMySQL.Integrating.Authorizing.IAM.CreateRole.md)」の各ステップを実行します。 1. 「[IAM ロールと Amazon Aurora MySQL DB クラスターの関連付け](AuroraMySQL.Integrating.Authorizing.IAM.AddRoleToDBCluster.md)」の各ステップを実行します。 ## Amazon Aurora MySQL DB クラスターとして復元するファイルのバックアップ Percona XtraBackup を使用して MySQL データベースファイルの完全バックアップを作成し、そのバックアップファイルを Amazon S3 バケットにアップロードできます。または、Percona XtraBackup を使用して MySQL データベースファイルをバックアップ済みである場合は、既存の完全および増分バックアップディレクトリおよびファイルを Amazon S3 バケットにアップロードできます。 **Topics** + [Percona XtraBackup での完全バックアップの作成](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Full) + [Percona XtraBackup での増分バックアップの使用](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Incr) + [バックアップに関する考慮事項](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Considerations) ### Percona XtraBackup での完全バックアップの作成 Aurora MySQL DB クラスターを作成するために Amazon S3 から復元できる、MySQL データベースファイルのフルバックアップを作成するには、Percona XtraBackup ユーティリティ (`xtrabackup`) を使用してデータベースをバックアップします。 例えば、次のコマンドは MySQL データベースのバックアップを作成し、ファイルを `/on-premises/s3-restore/backup` フォルダに保存します。 ``` xtrabackup --backup --user= --password= --target-dir= ``` バックアップを 1 つのファイル (必要に応じて分割できます) に圧縮する場合、以下のいずれかの形式を使用して `--stream` オプションを使用してバックアップを保存できます。 + Gzip (.gz) + tar (.tar) + Percona xbstream (.xbstream) 次のコマンドでは、複数の Gzip ファイルに分割された MySQL データベースのバックアップを作成します。 ``` xtrabackup --backup --user= --password= --stream=tar \ --target-dir= | gzip - | split -d --bytes=500MB \ - .tar.gz ``` 次のコマンドでは、複数の tar ファイルに分割された MySQL データベースのバックアップを作成します。 ``` xtrabackup --backup --user= --password= --stream=tar \ --target-dir= | split -d --bytes=500MB \ - .tar ``` 例えば、次のコマンドでは、複数の xbstream ファイルに分割された MySQL データベースのバックアップを作成します。 ``` xtrabackup --backup --user= --password= --stream=xbstream \ --target-dir= | split -d --bytes=500MB \ - .xbstream ``` **注記** 次のエラーが表示される場合は、コマンドにファイル形式が混在していることが原因となっている可能性があります。 ``` ERROR:/bin/tar: This does not look like a tar archive ``` Percona XtraBackup ユーティリティを使用して MySQL データベースをバックアップしたら、バックアップディレクトリおよびファイルを Amazon S3 バケットにコピーできます。 ファイルを作成して Amazon S3 バケットにアップロードする方法については、*Amazon S3 入門ガイド*の「[Amazon Simple Storage Service のスタート方法](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html)」を参照してください。 ### Percona XtraBackup での増分バックアップの使用 Amazon Aurora MySQL は、Percona XtraBackup を使用して作成された完全バックアップおよび増分バックアップの両方をサポートしています。Percona XtraBackup を使用して MySQL データベースファイルの完全および増分バックアップを作成済みである場合は、完全バックアップを作成して Amazon S3 にアップロードする必要はありません。代わりに、既存の完全および増分バックアップのディレクトリおよびファイルを Amazon S3 バケットにコピーして、多大な時間を節約できます。詳細については、Percona のウェブサイトで「[インクリメンタルバックアップを作成する](https://docs.percona.com/percona-xtrabackup/8.0/create-incremental-backup.html)」を参照してください。 既存の完全および増分バックアップファイルを Amazon S3 バケットにコピーするときは、ベースディレクトリのコンテンツを再帰的にコピーする必要があります。これらのコンテンツには、完全バックアップと、すべての増分バックアップディレクトリおよびファイルが含まれます。このコピーには、Amazon S3 バケットのディレクトリ構造を維持する必要があります。Aurora は、すべてのファイルとディレクトリを反復処理します。Aurora は、増分バックアップを含む `xtrabackup-checkpoints` ファイルを使用し、ベースディレクトリを識別します。また、ログシーケンス番号 (LSN) の範囲に従って増分バックアップを整列させます。 ファイルを作成して Amazon S3 バケットにアップロードする方法については、*Amazon S3 入門ガイド*の「[Amazon Simple Storage Service のスタート方法](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html)」を参照してください。 ### バックアップに関する考慮事項 Aurora では、Percona XtraBackup を使用して作成された部分バックアップがサポートされていません。データベースの出典ファイルをバックアップするときに、`--tables`、`--tables-exclude`、`--tables-file`、`--databases`、`--databases-exclude`、または `--databases-file` オプションを使用して部分バックアップを作成することはできません。 Percona XtraBackup を使用したデータベースのバックアップの詳細については、Percona ウェブサイトの「[Percona XtraBackup - ドキュメント](https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html)」および「[バイナリログの使用](https://docs.percona.com/percona-xtrabackup/8.0/working-with-binary-logs.html)」を参照してください。 Aurora では、Percona XtraBackup を使用して作成された差分バックアップがサポートされています。詳細については、Percona のウェブサイトで「[インクリメンタルバックアップを作成する](https://docs.percona.com/percona-xtrabackup/8.0/create-incremental-backup.html)」を参照してください。 Aurora では、ファイル名に基づいてバックアップファイルを使用します。ファイル形式に基づいた適切なファイル拡張子でバックアップファイルの名前を付けてください。例えば、Percona xbstream 形式を使用して保存されるファイルでは、`.xbstream` のようにします。 Aurora では、アルファベット順および通常の数値順にバックアップファイルを使用します。バックアップファイルが適切な順序で書き込まれ、名前が付けられるように、`split` コマンドを発行するときは必ず `xtrabackup` オプションを使用します。 Amazon S3 では、Amazon S3 バケットにアップロードするファイルのサイズが 5 TB に制限されます。データベースのバックアップデータが 5 TB を超える場合は、`split` コマンドを使用して、それぞれが 5 TB 未満の複数のファイルにバックアップファイルを分割します。 Aurora から Amazon S3 バケットにアップロードする出典ファイルの数は百万までに制限されています。場合によっては、すべての完全および増分バックアップを含むデータベースのバックアップデータには多数のファイルがあることがあります。この場合、tarball (.tar.gz) ファイルを使用して完全および増分バックアップを Amazon S3 バケットに保存します。 Amazon S3 バケットにファイルをアップロードしたら、サーバー側の暗号化を使用してデータを暗号化します。その後、この暗号化されたファイルから Amazon Aurora MySQL DB クラスターを復元できます。Amazon Aurora MySQL は、以下のタイプのサーバー側の暗号化を使用して、暗号化されたファイルを含む DB クラスターを復元できます。 + Amazon S3 管理キー (SSE-S3) によるサーバー側の暗号化。各オブジェクトは、強力な多要素暗号化を採用した一意のキーで暗号化されています。 + AWS KMS 管理キー (SSE-KMS) によるサーバー側の暗号化 - SSE-S3 に類似していますが、ユーザーによる暗号キーの作成と管理オプションや、その他点で異なります。 Amazon S3 バケットにファイルをアップロードするときにサーバー側の暗号化を使用する方法については、*Amazon S3 デベロッパーガイド*の「[サーバー側の暗号化を使用したデータの保護](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html)」を参照してください。 ## Amazon S3 バケットからの Amazon Aurora MySQL DB クラスターの復元 Amazon RDS コンソールを使用して、Amazon S3 バケットからバックアップファイルを復元して新しい Amazon Aurora MySQL DB クラスターを作成できます。 **Amazon S3 バケットのファイルから Amazon Aurora MySQL DB クラスターを復元するには** 1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。 1. Amazon RDS コンソールの右上で、DB クラスターを作成する AWS リージョンを選択します。データベースバックアップを含む Amazon S3 バケットと同じ AWS リージョンを選択します。 1. ナビゲーションペインで、[**データベース**]、[**S3 から復元**] の順に選択します。 1. [**S3 から復元する**] を選択します。 [**S3 から復元してデータベースを作成する**] ページが表示されます。 ![\[S3 から DB クラスターを復元するための詳細を指定するページ\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/AuroraMigrateS3_01.png) 1. **S3 送信先**で 1. バックアップファイルを含む **S3 バケット**を選択します。 1. (オプション) [**S3 フォルダパスプレフィックス**] で、Amazon S3 バケットに保存されているファイルのファイルパスのプレフィックスを入力します。 プレフィックスを指定しない場合、RDS は S3 バケットのルートフォルダにあるすべてのファイルとフォルダを使用して DB インスタンスを作成します。プレフィックスを指定すると、RDS はファイルのパスが指定されたプレフィックスで始まる S3 バケットのファイルとフォルダを使用して DB インスタンスを作成します。 例えば、複数のバックアップファイルのセットを S3 のサブフォルダ (backup) 内に保存し、各セットは独自のディレクトリ (gzip\$1backup1、gzip\$1backup2 など) 内にあるとします。この場合、プレフィックス backups/gzip\$1backup1 を指定して、gzip\$1backup1 フォルダのファイルから復元することができます。 1. [**エンジンオプション**]で 1. [**エンジンのタイプ**] で [** Amazon Aurora**] を選択します。 1. [**バージョン **] で、復元した DB インスタンスの Aurora MySQL エンジンのバージョンを選択します。 1. **IAM ロール**では、既存の IAM ロールを選択します。 1. (オプション) [**新しいロールを作成する**]を選択して、新しい IAM ロールを持つこともできます。その場合、 1. **IAM ロール名**を入力します。 1. **KMS キーへのアクセスを許可する**かどうかを選択します。 + バックアップファイルを暗号化していない場合には、[**いいえ**] を選択します。 + Amazon S3 にバックアップファイルをアップロードした際に、このファイルを AES-256 (SSE-S3) で暗号化している場合には、[**いいえ**] を選択します。この設定により、データは自動的に復号化されます。 + Amazon S3 にバックアップファイルをアップロードした際に、このファイルで AWS KMS (SSE-KMS) によるサーバー側の暗号化を実行した場合には、[**はい**] を選択します。次に、**AWS KMS key** の適切な KMS キーを選択します。 AWS マネジメントコンソール は、Aurora によるデータの復号を許可する IAM ポリシーを作成します。 詳細については、*Amazon S3 デベロッパーガイド*の「[サーバー側の暗号化を使用したデータの保護](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html)」を参照してください。 1. DB クラスターストレージ設定、DB インスタンスクラス、DB クラスター識別子やログイン認証情報など、DB クラスターの設定を選択します。各設定の詳細については、「[Aurora DB クラスターの設定](Aurora.CreateInstance.md#Aurora.CreateInstance.Settings)」を参照してください。 1. 必要に応じて、Aurora MySQL DB クラスターの追加設定をカスタマイズします。 1. [**データベースの作成**] を選択して Aurora DB インスタンスを起動します。 Amazon RDS コンソールでは、新しい DB インスタンスが DB インスタンスのリストに表示されます。DB インスタンスが作成されて使用できるようになるまで、DB インスタンスのステータスは [**作成中**] となります。ステータスが [**available**] に変わったら、DB クラスターのプライマリインスタンスに接続できます。DB インスタンスクラスと割り当てられたストレージによっては、新しいインスタンスを使用できるようになるまで数分かかることがあります。 新しく作成したクラスターを表示するには、Amazon RDS コンソールで [**データベース**] ビューを選択し、DB クラスターを選択します。詳細については、「[Amazon Aurora DB クラスターの表示](accessing-monitoring.md#Aurora.Viewing)」を参照してください。 ![\[Amazon Aurora DB インスタンスリスト\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/AuroraLaunch04.png) DB クラスターのポートと書き込みエンドポイントをメモします。DB クラスターの書き込みエンドポイントとポートは、書き込みまたは読み取りオペレーションを実行するすべてのアプリケーションの JDBC 接続文字列と ODBC 接続文字列で使用します。 ## レプリケーションを使用して、Amazon Aurora MySQL DB クラスターと MySQL データベースを同期する 移行中のダウンタイムを減少あるいはなくすためには、Aurora MySQL DB クラスターに対して MySQL データベースで行われるトランザクションをレプリケートできます。レプリケーションは、移行中に発生する MySQL データベース上のトランザクションに DB クラスターが追いつくようにします。DB クラスターが完全に追いついたら、レプリケーションを停止し、Aurora MySQL への移行を終了できます。 **Topics** + [暗号化レプリケーション用に外部の MySQL データベースと Aurora MySQL DB クラスターを設定する](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync.ConfigureEncryption) + [Amazon Aurora MySQL DB クラスターと外部の MySQL データベースを同期する](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync.Synchronizing) ### 暗号化レプリケーション用に外部の MySQL データベースと Aurora MySQL DB クラスターを設定する データを安全に複製するには、暗号化されたレプリケーションを使用できます。 **注記** 暗号化レプリケーションを使う必要がない場合、このステップをスキップして、「[Amazon Aurora MySQL DB クラスターと外部の MySQL データベースを同期する](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync.Synchronizing)」のステップに進むことができます。 暗号化レプリケーションを使用するための前提条件は次のとおりです。 + Secure Sockets Layer (SSL) は、外部の MySQL プライマリデータベースで有効になっている必要があります。 + クライアントのキーとクライアントの証明書が Aurora MySQL DB クラスター用に準備されている必要があります。 暗号化のレプリケーション中、Aurora MySQL DB クラスターはクライアントとして MySQL データベースサーバーに動作します。Aurora MySQL 用の証明書およびキーは、.pem 形式のファイルにあります。 **暗号化レプリケーションのために、外部の MySQL データベースおよび Aurora MySQL DB クラスターを設定するには** 1. 暗号化レプリケーションのための準備があることを確認してください。 + 外部の MySQL プライマリデータベースで SSL が有効になっておらず、クライアントキーとクライアント証明書が準備されていない場合、MySQL データベースサーバーで SSL を有効にし、必要なクライアントキーとクライアントの証明書を生成します。 + SSL が外部プライマリで有効になっている場合は、Aurora MySQL DB クラスターにクライアントキーおよび証明書を提供します。これらがない場合は、Aurora MySQL DB クラスター用に新しいキーと証明書を生成します。クライアント証明書に署名するには、外部の MySQL プライマリデータベースで SSL の設定に使用した認証局キーが必要です。 詳細については、MySQL ドキュメントの「[openssl を使って SSL 証明書とキーを作成する](https://dev.mysql.com/doc/refman/5.6/en/creating-ssl-files-using-openssl.html)」を参照してください。 認証局証明書、クライアントキーおよびクライアント証明書が必要となります。 1. SSL を使用して、プライマリユーザーとして Aurora MySQL DB クラスターに接続します。 SSL で Aurora MySQL DB クラスターに接続する詳細については、「[Aurora MySQL DB クラスターへの接続](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL)」を参照してください。 1. [mysql.rds\$1import\$1binlog\$1ssl\$1material](mysql-stored-proc-replicating.md#mysql_rds_import_binlog_ssl_material) ストアドプロシージャを実行して、Aurora MySQL DB クラスターに SSL 情報をインポートします。 `ssl_material_value` パラメータには、正しい JSON ペイロードで Aurora MySQL DB クラスター用の .pem 形式から情報を挿入します。 次の例では、SSL 情報を Aurora MySQL DB クラスターにインポートします。.pem 形式ファイルでは、通常の場合、コード本文に例に示されるコード本文より長くなっています。 ``` call mysql.rds_import_binlog_ssl_material( '{"ssl_ca":"-----BEGIN CERTIFICATE----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END RSA PRIVATE KEY-----\n"}'); ``` 詳細については、「[mysql.rds\$1import\$1binlog\$1ssl\$1material](mysql-stored-proc-replicating.md#mysql_rds_import_binlog_ssl_material)」および「[Aurora MySQL DB クラスターへの接続](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL)」を参照してください。 **注記** 手順を実行したあと、シークレットはファイルに保存されます。ファイルを後で消去するには、[mysql.rds\$1remove\$1binlog\$1ssl\$1material](mysql-stored-proc-replicating.md#mysql_rds_remove_binlog_ssl_material) ストアドプロシージャを実行できます。 ### Amazon Aurora MySQL DB クラスターと外部の MySQL データベースを同期する レプリケーションを使用して、Amazon Aurora MySQL DB クラスターと MySQL データベースを同期できます。 **レプリケーションを使用して、Aurora MySQL DB クラスターと MySQL データベースを同期するには** 1. 外部の MySQL データベース用の /etc/my.cnf ファイルに関連するエントリがあることを確認します。 暗号化レプリケーションが求められない場合、外部 MySQL データベースがバイナリログ (binlogs) が有効化されて、SSL が無効化された状態でスタートすることを確認します。以下に示すのは、非暗号化データ用の /etc/my.cnf ファイルの関連するエントリです。 ``` log-bin=mysql-bin server-id=2133421 innodb_flush_log_at_trx_commit=1 sync_binlog=1 ``` 暗号化レプリケーションが求められる場合、外部 MySQL データベースが SSL およびバイナリログ有効化された状態でスタートすることを確認します。/etc/my.cnf ファイルのエントリには、MySQL データベースサーバーのための .pem ファイルの場所が含まれます。 ``` log-bin=mysql-bin server-id=2133421 innodb_flush_log_at_trx_commit=1 sync_binlog=1 # Setup SSL. ssl-ca=/home/sslcerts/ca.pem ssl-cert=/home/sslcerts/server-cert.pem ssl-key=/home/sslcerts/server-key.pem ``` 次のコマンドを使って、SSL が有効であることを確認できます。 ``` mysql> show variables like 'have_ssl'; ``` 出力は次のようになります。 ``` +~-~-~-~-~-~-~-~-~-~-~-~-~-~--+~-~-~-~-~-~--+ | Variable_name | Value | +~-~-~-~-~-~-~-~-~-~-~-~-~-~--+~-~-~-~-~-~--+ | have_ssl | YES | +~-~-~-~-~-~-~-~-~-~-~-~-~-~--+~-~-~-~-~-~--+ 1 row in set (0.00 sec) ``` 1. レプリケーションをスタートするバイナリログの位置を決定します。レプリケーションをスタートする位置は後のステップで指定します。 ** の使用AWS マネジメントコンソール** 1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。 1. ナビゲーションペインの [**Events**] を選択します。 1. [**イベント**] リストで、[**Recovered from Binary log filename** (バイナリログのファイル名から復旧済み)] イベントの位置をメモします。 ![\[MySQL プライマリを表示\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-mysql-rep-binary-log-position.png) ** の使用AWS CLI** [describe-events](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-events.html) AWS CLI コマンドを使用sるうことにより、binlog ファイルの名前と場所を取得することもできます。`describe-events` コマンドの例を以下に示します。 ``` PROMPT> aws rds describe-events ``` 出力で、バイナリログの位置を示すイベントを特定します。 1. 外部の MySQL データベースに接続したら、レプリケーションに使用するユーザーを作成します。このアカウントはレプリケーション専用に使用され、セキュリティを強化するためにドメインに制限する必要があります。次に例を示します。 ``` mysql> CREATE USER ''@'' IDENTIFIED BY ''; ``` ユーザーには `REPLICATION CLIENT` および `REPLICATION SLAVE` 権限が必要です。ユーザーのこれらの権限を付与します。 ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO ''@''; ``` 暗号化レプリケーションを使用する必要がある場合は、レプリケーションのユーザーに対して SSL 接続を要求します。例えば、以下のステートメントを使用して、ユーザーアカウント `` に SSL 接続を要求できます。 ``` GRANT USAGE ON *.* TO ''@'' REQUIRE SSL; ``` **注記** `REQUIRE SSL` が含まれていない場合には、レプリケーション接続がメッセージの表示なしで非暗号化接続に戻る場合があります。 1. Amazon RDS コンソールで、外部 MySQL データベースをホストするサーバーの IP アドレスを、Aurora MySQL DB クラスターの VPC セキュリティグループに追加します。VPC セキュリティグループの変更方法の詳細については、*Amazon Virtual Private Cloudユーザーガイド*の「[VPC のセキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)」を参照してください。 外部の MySQL データベースと通信できるようにするために、Aurora MySQL DB クラスターの IP アドレスからの接続を許可するようにローカルネットワークを設定することも必要になる場合があります。Aurora MySQL DB クラスターの IP アドレスを確認するには、`host` コマンドを使用します。 ``` host ``` このホスト名は、Aurora MySQL DB クラスターのエンドポイントからの DNS 名です。 1. [mysql.rds\$1reset\$1external\$1master (Aurora MySQL バージョン 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) または [mysql.rds\$1reset\$1external\$1source (Aurora MySQL バージョン 3)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) ストアプロシージャを実行して、バイナリログレプリケーションを有効化します。このストアプロシージャの構文は次のとおりです。 ``` CALL mysql.rds_set_external_master ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption ); CALL mysql.rds_set_external_source ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption ); ``` パラメータの詳細については、「[mysql.rds\$1reset\$1external\$1master (Aurora MySQL バージョン 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master)」および「[mysql.rds\$1reset\$1external\$1source (Aurora MySQL バージョン 3)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source)」を参照してください。 `mysql_binary_log_file_name` および `mysql_binary_log_file_location` には、前のステップでメモした [**Recovered from Binary log filename** (バイナリログのファイル名から復旧済み)] イベントの位置を使用します。 Aurora MySQL DB クラスターのデータが暗号化されていない場合には、`ssl_encryption` パラメータを `0` に設定する必要があります。このデータが暗号化されている場合、`ssl_encryption` パラメータを `1` に設定する必要があります。 次の例では、暗号化されたデータがある Aurora MySQL DB クラスターの手順を実行します。 ``` CALL mysql.rds_set_external_master( 'Externaldb.some.com', 3306, 'repl_user'@'mydomain.com', 'password', 'mysql-bin.000010', 120, 1); CALL mysql.rds_set_external_source( 'Externaldb.some.com', 3306, 'repl_user'@'mydomain.com', 'password', 'mysql-bin.000010', 120, 1); ``` このストアプロシージャは、外部の MySQL データベースに接続し、そのバイナリログを読み取るために Aurora MySQL DB クラスターが使用するパラメータを設定します。データが暗号化されている場合には、SSL 認証局証明書、クライアント証明書およびクライアントキーもローカルディスクにダウンロードされます。 1. [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) ストアプロシージャを実行して、バイナリログレプリケーションをスタートします。 ``` CALL mysql.rds_start_replication; ``` 1. Aurora MySQL DB クラスターが MySQL レプリケーションプライマリーデータベースよりどれだけ遅れているかをモニタリングします。そのためには、Aurora MySQL DB クラスターに接続し、次のコマンドを実行します。 ``` Aurora MySQL version 2: SHOW SLAVE STATUS; Aurora MySQL version 3: SHOW REPLICA STATUS; ``` このコマンドの出力の `Seconds Behind Master` フィールドには、Aurora MySQL DB クラスターがどれだけ MySQL プライマリより遅れているかが示されます。この値が `0` (ゼロ) の場合、Aurora MySQL DB クラスターがMySQL プライマリに追いついたことを示し、レプリケーションを停止するための次のステップに進むことができます。 1. MySQL レプリケーションのMySQL プライマリデータベースに接続して、レプリケーションを停止します。これを行うには、[mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) ストアドプロシージャを実行します。 ``` CALL mysql.rds_stop_replication; ``` # Amazon Aurora MySQL への物理的な移行にかかる時間の短縮 Amazon Aurora MySQL へのデータベース移行プロセスをスピードアップするために、以下のデータベース修正を行うことができます。 **重要** これらのアップデートは、本稼働データベースではなく、そのコピーに対して実行するようにしてください。このコピーをバックアップし、Aurora MySQL DB クラスターに復元することで、本稼働データベースのサービス停止を回避できます。 ## サポートされていないテーブルタイプ Aurora MySQL はデータベーステーブル用の InnoDB エンジンのみをサポートしています。データベース内に MyISAM テーブルがある場合は、Aurora MySQL に移行する前にそれらのテーブルを変換する必要があります。移行中の MyISAM から InnoDB への変換プロセスには、追加領域が必要です。 領域不足が発生する可能性を低く抑えて移行プロセスを高速化するには、すべての MyISAM テーブルを移行前に InnoDB テーブルに変換しておきます。処理後の InnoDB テーブルのサイズは、Aurora MySQL がそのテーブルに対して必要とするサイズと同じになります。MyISAM テーブルを InnoDB に変換するには、次のコマンドを実行します。 ``` ALTER TABLE schema.table_name engine=innodb, algorithm=copy; ``` Aurora MySQL では、圧縮テーブルまたはページ (`ROW_FORMAT=COMPRESSED` または `COMPRESSION = {"zlib"|"lz4"}` を使用して作成されたテーブル) をサポートしていません。 スペースが不足する可能性を減らしたり、移行処理を高速化するには、`ROW_FORMAT` を `DEFAULT`、`COMPACT`、`DYNAMIC` または `REDUNDANT` に設定して圧縮テーブルを展開します。圧縮ページの場合は、`COMPRESSION="none"` を設定します。 詳細については、MySQL ドキュメントの「[InnoDB 行形式](https://dev.mysql.com/doc/refman/8.0/en/innodb-row-format.html)」および「[InnoDB テーブルおよびページ圧縮](https://dev.mysql.com/doc/refman/8.0/en/innodb-compression.html)」を参照してください。 既存の MySQL DB インスタンスで以下の SQL スクリプトを使用して、データベースの MyISAM テーブルまたは圧縮テーブルのリストを表示できます。 ``` -- This script examines a MySQL database for conditions that block -- migrating the database into Aurora MySQL. -- It must be run from an account that has read permission for the -- INFORMATION_SCHEMA database. -- Verify that this is a supported version of MySQL. select msg as `==> Checking current version of MySQL.` from ( select 'This script should be run on MySQL version 5.6 or higher. ' + 'Earlier versions are not supported.' as msg, cast(substring_index(version(), '.', 1) as unsigned) * 100 + cast(substring_index(substring_index(version(), '.', 2), '.', -1) as unsigned) as major_minor ) as T where major_minor <> 506; -- List MyISAM and compressed tables. Include the table size. select concat(TABLE_SCHEMA, '.', TABLE_NAME) as `==> MyISAM or Compressed Tables`, round(((data_length + index_length) / 1024 / 1024), 2) "Approx size (MB)" from INFORMATION_SCHEMA.TABLES where ENGINE <> 'InnoDB' and ( -- User tables TABLE_SCHEMA not in ('mysql', 'performance_schema', 'information_schema') or -- Non-standard system tables ( TABLE_SCHEMA = 'mysql' and TABLE_NAME not in ( 'columns_priv', 'db', 'event', 'func', 'general_log', 'help_category', 'help_keyword', 'help_relation', 'help_topic', 'host', 'ndb_binlog_index', 'plugin', 'proc', 'procs_priv', 'proxies_priv', 'servers', 'slow_log', 'tables_priv', 'time_zone', 'time_zone_leap_second', 'time_zone_name', 'time_zone_transition', 'time_zone_transition_type', 'user' ) ) ) or ( -- Compressed tables ROW_FORMAT = 'Compressed' ); ``` ## サポートされていない権限を持つユーザーアカウント Aurora MySQL でサポートされていない権限を持つユーザーアカウントは、サポートされていない権限なしでもインポートされます。サポートされている権限のリストについては、「[ロールベースの特権モデル](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)」を参照してください。 ソースデータベースで次の SQL クエリを実行すると、サポートされていない権限を持つユーザーアカウントを一覧表示できます。 ``` SELECT user, host FROM mysql.user WHERE Shutdown_priv = 'y' OR File_priv = 'y' OR Super_priv = 'y' OR Create_tablespace_priv = 'y'; ``` ## Aurora MySQL バージョン 3 に対する動的権限 動的権限はインポートされません。Aurora MySQL バージョン 3 は、以下の動的権限をサポートしています。 ``` 'APPLICATION_PASSWORD_ADMIN', 'CONNECTION_ADMIN', 'REPLICATION_APPLIER', 'ROLE_ADMIN', 'SESSION_VARIABLES_ADMIN', 'SET_USER_ID', 'XA_RECOVER_ADMIN' ``` 次のサンプルスクリプトは、サポートされている動的権限を Aurora MySQL DB クラスターのユーザーアカウントに付与します。 ``` -- This script finds the user accounts that have Aurora MySQL supported dynamic privileges -- and grants them to corresponding user accounts in the Aurora MySQL DB cluster. /home/ec2-user/opt/mysql/8.0.26/bin/mysql -uusername -pxxxxx -P8026 -h127.0.0.1 -BNe "SELECT CONCAT('GRANT ', GRANTS, ' ON *.* TO ', GRANTEE ,';') AS grant_statement FROM (select GRANTEE, group_concat(privilege_type) AS GRANTS FROM information_schema.user_privileges WHERE privilege_type IN ( 'APPLICATION_PASSWORD_ADMIN', 'CONNECTION_ADMIN', 'REPLICATION_APPLIER', 'ROLE_ADMIN', 'SESSION_VARIABLES_ADMIN', 'SET_USER_ID', 'XA_RECOVER_ADMIN') AND GRANTEE NOT IN (\"'mysql.session'@'localhost'\",\"'mysql.infoschema'@'localhost'\",\"'mysql.sys'@'localhost'\") GROUP BY GRANTEE) AS PRIVGRANTS; " | /home/ec2-user/opt/mysql/8.0.26/bin/mysql -u master_username -p master_password -h DB_cluster_endpoint ``` ## 定義者として 'rdsadmin'@'localhost' を使用して保存されたオブジェクト `'rdsadmin'@'localhost'` が定義子である関数、プロシージャ、ビュー、イベント、トリガーは、インポートされません。 ソース MySQL データベースで以下の SQL スクリプトを使用すると、サポートされていない定義子を持つストアド オブジェクトを一覧表示できます。 ``` -- This SQL query lists routines with `rdsadmin`@`localhost` as the definer. SELECT ROUTINE_SCHEMA, ROUTINE_NAME FROM information_schema.routines WHERE definer = 'rdsadmin@localhost'; -- This SQL query lists triggers with `rdsadmin`@`localhost` as the definer. SELECT TRIGGER_SCHEMA, TRIGGER_NAME, DEFINER FROM information_schema.triggers WHERE DEFINER = 'rdsadmin@localhost'; -- This SQL query lists events with `rdsadmin`@`localhost` as the definer. SELECT EVENT_SCHEMA, EVENT_NAME FROM information_schema.events WHERE DEFINER = 'rdsadmin@localhost'; -- This SQL query lists views with `rdsadmin`@`localhost` as the definer. SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.views WHERE DEFINER = 'rdsadmin@localhost'; ``` # mysqldump を使用した MySQL から Amazon Aurora MySQL への論理的移行 Amazon Aurora MySQL は MySQL と互換性があるデータベースであるため、`mysqldump` ユーティリティを使用して MySQL データベースからデータをコピーしたり、`mariadb-dump` ユーティリティを使用して MariaDB データベースから既存の Aurora MySQL DB クラスターにデータをコピーしたりできます。 非常に大規模な MySQL または MariaDB データベースでこれを行う方法については、「*Amazon Relational Database Service ユーザーガイド*」の以下のトピックを参照してください。 + MySQL – [Importing data to an Amazon RDS for MySQL database with reduced downtime](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-reduced-downtime.html) + MariaDB – [Importing data to an Amazon RDS for MariaDB database with reduced downtime](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mariadb-importing-data-reduced-downtime.html) データ量が少ない MySQL または MariaDB データベースについては、「*Amazon Relational Database Service ユーザーガイド*」の以下のトピックを参照してください。 + MySQL – [Importing data from an external MySQL database to an Amazon RDS for MySQL DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-external-database.html) + MariaDB – [Importing data from an external MariaDB database to an Amazon RDS for MariaDB DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mariadb-importing-data-external-database.html) # RDS for MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターへのデータの移行 RDS for MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターにデータを移行 (コピー) できます。 **Topics** + [Aurora への RDS for MySQL スナップショットの移行](AuroraMySQL.Migrating.RDSMySQL.Snapshot.md) + [Aurora リードレプリカを使用した、RDS for MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターへのデータの移行](AuroraMySQL.Migrating.RDSMySQL.Replica.md) **注記** Amazon Aurora MySQL は MySQL と互換性があるため、MySQL データベースと Amazon Aurora MySQL DB クラスターの間でレプリケーションをセットアップすることによって、MySQL データベースのデータを移行できます。詳細については、「[Amazon Aurora でのレプリケーション](Aurora.Replication.md)」を参照してください。 # Aurora への RDS for MySQL スナップショットの移行 RDS for MySQL DB インスタンスの DB スナップショットを移行して、Aurora MySQL DB クラスターを作成することができます。新しい Aurora MySQL DB クラスターには、元の RDS for MySQL DB インスタンスのデータが入力されます。DB スナップショットは、Aurora MySQL と互換性がある MySQL バージョンを実行している Amazon RDS DB インスタンスから作成されたものである必要があります。 手動で作成された DB スナップショットと自動的に作成された DB スナップショットのどちらも移行できます。DB クラスターが作成された後、オプションの Aurora レプリカを作成できます。 **注記** ソース RDS for MySQL DB インスタンスの Aurora リードレプリカを作成することにより、RDS for MySQL DB インスタンスを Aurora MySQL DB クラスターに移行することもできます。詳細については、「[Aurora リードレプリカを使用した、RDS for MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターへのデータの移行](AuroraMySQL.Migrating.RDSMySQL.Replica.md)」を参照してください。 8.0.11、8.0.13、8.0.15 などの一部の古い MySQL 8.0 バージョンからは Aurora MySQL バージョン 3.05 以上に移行できません。移行する前に MySQL バージョン 8.0.28 にアップグレードすることをお勧めします。 実行する必要がある一般的なステップは次のとおりです。 1. Aurora MySQL DB クラスターをプロビジョニングするための容量を決定します。詳細については、「[必要な容量](#AuroraMySQL.Migrating.RDSMySQL.Space)」を参照してください。 1. コンソールを使用して、Amazon RDS MySQL インスタンスが置かれている AWS リージョン内にスナップショットを作成します。DB スナップショットの作成については、「[DB スナップショットの作成](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)」を参照してください。 1. DB スナップショットが DB クラスターと同じ AWS リージョン内にない場合は、Amazon RDS コンソールを使用して DB スナップショットをその AWS リージョンにコピーします。DB スナップショットのコピーについては、「[DB スナップショットのコピー](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html)」を参照してください。 1. コンソールを使用して DB スナップショットを移行し、元の MySQL DB インスタンスと同じデータベースを持つ Aurora MySQL DB クラスターを作成します。 **警告** Amazon RDS では、各 AWS アカウントによる各 AWS リージョンへのスナップショットのコピーは 1 度に 1 つに制限されています。 ## 必要な容量 MySQL DB インスタンスのスナップショットを Aurora MySQL DB クラスターに移行するとき、Aurora は、スナップショットのデータを移行する前に Amazon Elastic Block Store (Amazon EBS) ボリュームを使用してそのデータの書式を設定します。移行するデータの書式を設定するために追加容量が必要になる場合があります。 MyISAM テーブルではないテーブルおよび圧縮されていないテーブルのサイズは、最大 16 TB が可能です。MyISAM テーブルの場合、Aurora では、Aurora MySQL と互換性のあるテーブルに変換するために、ボリュームに追加のスペースが必要になります。圧縮されたテーブルの場合、Aurora では、圧縮されたテーブルを Aurora クラスターボリュームに保存する前に展開するため、ボリュームに追加のスペースが必要になります。追加のスペースが必要になるため、MySQL DB インスタンスから移行される MyISAM テーブルおよび圧縮テーブルのサイズが 8 TB を超えていないことを確認する必要があります。 ## Amazon Aurora MySQL にデータを移行するために必要な容量の削減 Amazon Aurora に移行する前にデータベーススキーマを変更することもできます。このような変更は、次のような場合に便利です。 + 移行プロセスを迅速化したい。 + プロビジョニングするために必要な領域の量がわからない場合。 + データを移行しようとしたが、プロビジョニング済み領域の不足で移行が失敗した場合。 以下の変更を行うことで、データベースを Amazon Aurora に移行するプロセスを改善できます。 **重要** これらの更新は、本稼働インスタンスではなく、本稼働データベースのスナップショットから復元された新しい DB インスタンスに対して実行します。その後、新しい DB インスタンスのスナップショットからデータを Aurora DB クラスターに移行することで、本稼働データベースに対するサービスの中断を回避できます。 | テーブルタイプ | 制限またはガイドライン | | --- | --- | | MyISAM テーブル | Aurora MySQL は InnoDB テーブルのみをサポートします。データベース内に MyISAM テーブルがある場合は、Aurora MySQL に移行する前にそれらのテーブルを変換する必要があります。移行中の MyISAM から InnoDB への変換プロセスには、追加領域が必要です。 領域不足が発生する可能性を低く抑えて移行プロセスを高速化するには、すべての MyISAM テーブルを移行前に InnoDB テーブルに変換しておきます。処理後の InnoDB テーブルのサイズは、Aurora MySQL がそのテーブルに対して必要とするサイズと同じになります。MyISAM テーブルを InnoDB に変換するには、次のコマンドを実行します。 `alter table . engine=innodb, algorithm=copy;` | | 圧縮テーブル | Aurora MySQL では、圧縮テーブル (`ROW_FORMAT=COMPRESSED` を使用して作成されたテーブル) をサポートしていません。 スペースが不足する可能性を減らしたり、移行処理を高速化するには、`ROW_FORMAT` を `DEFAULT`、`COMPACT`、`DYNAMIC` または `REDUNDANT` に設定して圧縮テーブルを展開します。詳細については、MySQL ドキュメントの「[InnoDB 行形式](https://dev.mysql.com/doc/refman/8.0/en/innodb-row-format.html)」を参照してください。 | 既存の MySQL DB インスタンスで以下の SQL スクリプトを使用して、データベースの MyISAM テーブルまたは圧縮テーブルのリストを表示できます。 ``` -- This script examines a MySQL database for conditions that block -- migrating the database into Amazon Aurora. -- It needs to be run from an account that has read permission for the -- INFORMATION_SCHEMA database. -- Verify that this is a supported version of MySQL. select msg as `==> Checking current version of MySQL.` from ( select 'This script should be run on MySQL version 5.6 or higher. ' + 'Earlier versions are not supported.' as msg, cast(substring_index(version(), '.', 1) as unsigned) * 100 + cast(substring_index(substring_index(version(), '.', 2), '.', -1) as unsigned) as major_minor ) as T where major_minor <> 506; -- List MyISAM and compressed tables. Include the table size. select concat(TABLE_SCHEMA, '.', TABLE_NAME) as `==> MyISAM or Compressed Tables`, round(((data_length + index_length) / 1024 / 1024), 2) "Approx size (MB)" from INFORMATION_SCHEMA.TABLES where ENGINE <> 'InnoDB' and ( -- User tables TABLE_SCHEMA not in ('mysql', 'performance_schema', 'information_schema') or -- Non-standard system tables ( TABLE_SCHEMA = 'mysql' and TABLE_NAME not in ( 'columns_priv', 'db', 'event', 'func', 'general_log', 'help_category', 'help_keyword', 'help_relation', 'help_topic', 'host', 'ndb_binlog_index', 'plugin', 'proc', 'procs_priv', 'proxies_priv', 'servers', 'slow_log', 'tables_priv', 'time_zone', 'time_zone_leap_second', 'time_zone_name', 'time_zone_transition', 'time_zone_transition_type', 'user' ) ) ) or ( -- Compressed tables ROW_FORMAT = 'Compressed' ); ``` スクリプトでは、次の例のような出力が作成されます。この例では、MyISAM から InnoDB に変換する必要のある 2 つのテーブルを示しています。出力には、メガバイト (MB) 単位で示した各テーブルのおおよそのサイズも含まれています。 ``` +---------------------------------+------------------+ | ==> MyISAM or Compressed Tables | Approx size (MB) | +---------------------------------+------------------+ | test.name_table | 2102.25 | | test.my_table | 65.25 | +---------------------------------+------------------+ 2 rows in set (0.01 sec) ``` ## RDS for MySQL DB スナップショットを Aurora MySQL DB クラスターに移行する RDS for MySQL DB インスタンスの DB スナップショットを移行して、AWS マネジメントコンソール または AWS CLI を使って、Aurora MySQL DB クラスターを作成することができます。新しい Aurora MySQL DB クラスターには、元の RDS for MySQL DB インスタンスのデータが入力されます。DB スナップショットの作成については、「[DB スナップショットの作成](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)」を参照してください。 DB スナップショットがデータを検索する AWS リージョン内にない場合は、DB スナップショットをその AWS リージョンにコピーします。DB スナップショットのコピーについては、「[DB スナップショットのコピー](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html)」を参照してください。 ### コンソール AWS マネジメントコンソール を使用して DB スナップショットを移行すると、コンソールは DB クラスターのみの作成に必要なアクションを実行します。 新しい Aurora MySQL DB クラスターが、AWS KMS key を使用して保管中に暗号化されるよう選択することもできます。 **AWS マネジメントコンソール を使用して MySQL DB スナップショットを移行するには** 1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。 1. MySQL DB インスタンスまたはスナップショットから移行をスタートします。 DB インスタンスから移行をスタートするには: 1. ナビゲーションペインで、[**データベース**] を選択し、MySQL DB インスタンスを選択します。 1. [**アクション**]、[**最新のスナップショットの移行**] の順に選択します。 スナップショットから移行をスタートするには: 1. [**スナップショット**] を選択します。 1. [**スナップショット**] ページで、Aurora MySQL DB クラスターに移行するスナップショットを選択します。 1. [**スナップショットのアクション**]、[**スナップショットの移行**] の順に選択します。 [**データベースの移行**] ページが表示されます。 1. [**データベースの移行**] ページで以下の値を設定します。 + [**DB エンジンへの移行**] : `aurora` を選択します。 + [**DB エンジンのバージョン**]: Aurora MySQL DB クラスターの DB エンジンのバージョンを選択します。 + **DB インスタンスクラス**: データベースに必要なストレージと容量を持つ DB インスタンスクラス (`db.r3.large` など) を選択します。Aurora クラスターボリュームは、データベースのデータ量が増えるにつれて自動的に増加します。Aurora クラスターボリュームは、最大 128 tebibytes (TiB) のサイズまで増やすことができます。そのため、現在のストレージ要件を満たしている DB インスタンスクラスを選択する必要があります。詳細については、「[Amazon Aurora ストレージの概要](Aurora.Overview.StorageReliability.md#Aurora.Overview.Storage)」を参照してください。 + **DB インスタンス識別子**: DB クラスター名を入力します。選択した AWS リージョン内で、自分のアカウントに対して一意であることが必要です。この識別子は、DB クラスター内のインスタンスのエンドポイントアドレスで使用されます。名前には、選択した AWS リージョンと DB エンジンなどを含めると理解しやすくなります (**aurora-cluster1** など)。 DB インスタンス識別子には次の制約があります。 + 1 ～ 63 文字の英数字またはハイフンを使用する必要があります。 + 1 字目は文字である必要があります。 + ハイフンを、文字列の最後に使用したり、2 つ続けて使用したりすることはできません。 + 1 つの AWS アカウント、1 つの AWS リージョンにつき、すべての DB インスタンスにおいて一意である必要があります。 + [**Virtual Private Cloud (VPC)**]: 既存の VPC がある場合は、その VPC 識別子 (`vpc-a464d1c1` など) を選択することで、その VPC を Aurora MySQL DB クラスターで使用できます。VPC の作成方法の詳細については、「[チュートリアル: DB クラスターで使用する VPC を作成する (IPv4 専用)](CHAP_Tutorials.WebServerDB.CreateVPC.md)」を参照してください。 または、[**新しい VPC の作成**] を選択し、Aurora で自動的に VPC を作成します。 + **DB サブネットグループ**: 既存のサブネットグループがある場合は、そのサブネットグループ識別子 (`gs-subnet-group1` など) を選択して、サブネットグループを Aurora MySQL DB クラスターで使用できます。 または、[**新しいサブネットグループを作成**] を選択し、Aurora で自動的にサブネットグループを作成します。 + **Public accessibility**: DB クラスターのインスタンスが VPC 内のリソースからのみアクセスできることを指定するには、[**いいえ**] を選択します。DB クラスターのインスタンスがパブリックネットワーク上のリソースからアクセスできることを指定するには、[**はい**] を選択します。デフォルトは [**はい**] です。 **注記** 本番稼働用の DB クラスターは、お客様のアプリケーションサーバーのみがアクセスするため、パブリックサブネット内に配置する必要がない場合があります。DB クラスターをパブリックサブネットに配置する必要がない場合は、[**パブリックアクセス可能**] を [**いいえ**] に設定します。 + [**アベイラビリティーゾーン**]: Aurora MySQL DB クラスターのプライマリインスタンスをホストするアベイラビリティーゾーンを選択します。Aurora で自動的にアベイラビリティーゾーンを選択するには、[**指定なし**] を選択します。 + [**データベースのポート**]: Aurora MySQL DB クラスターのインスタンスへの接続に使用されるデフォルトのポートを入力します。デフォルトは `3306` です。 **注記** 会社のファイアウォールで MySQL のデフォルトポートである 3306 などのデフォルトポートへのアクセスが許可されない場合があります。この場合は、会社のファイアウォールによって許可されるポート値を指定します。そのポート値を覚えておいてください。後で Aurora MySQL DB クラスターに接続するときに使用します。 + [**暗号化**]: 新しい Aurora MySQL DB クラスターを保管時に暗号化するには、[**暗号を有効化**] を選択します。[**Enable Encryption**] (暗号化を有効化) を選択する場合、KMS キーを **AWS KMS key** 値として選択する必要があります。 DB スナップショットが暗号化されていない場合は、暗号化キーを指定して保管時の DB クラスターを暗号化します。 DB スナップショットが暗号化されている場合は、暗号化キーを指定し、その指定された暗号化キーを使用して保管時の DB クラスターを暗号化します。DB スナップショットで使用される暗号化キー、または別のキーを指定できます。暗号化された DB スナップショットから 非暗号化の DB クラスターを作成することはできません。 + [**マイナーバージョン自動アップグレード**]: この設定は Aurora MySQL DB クラスターに適用されません。 Aurora MySQL のエンジンに関する更新の詳細については、「[Amazon Aurora MySQL のデータベースエンジンの更新Amazon Aurora MySQL の長期サポート (LTS) とベータリリース](AuroraMySQL.Updates.md)」を参照してください。 1. [**移行**] を選択して、DB スナップショットを移行します。 1. [**インスタンス**] を選択して、矢印アイコンを選択して DB クラスターの詳細を表示し、移行の進行状況をモニタリングします。詳細ページで、DB クラスターのプライマリインスタンスへの接続に使用されているクラスターエンドポイントがわかります。Aurora MySQL DB クラスターとの接続の詳細については、「[Amazon Aurora DB クラスターへの接続](Aurora.Connecting.md)」を参照してください。 ### AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-snapshot.html) コマンドを次のパラメータで使用することで、RDS for MySQL DB インスタンスの DB スナップショットから Aurora DB クラスターを作成できます。 + `--db-cluster-identifier` - 作成する DB クラスターの名前。 + `--engine aurora-mysql` — MySQL 5.7 互換または 8.0 互換 DB クラスターの場合 + `--kms-key-id` - DB スナップショットが暗号化されるかどうかに応じて、オプションで DB クラスターを暗号化するための AWS KMS key。 + DB スナップショットが暗号化されていない場合は、暗号化キーを指定して保管時の DB クラスターを暗号化します。これを実行しない場合、DB クラスターは暗号化されません。 + DB スナップショットが暗号化されている場合は、暗号化キーを指定し、その指定された暗号化キーを使用して保管時の DB クラスターを暗号化します。これを実行しない場合、保管時の DB クラスターは DB スナップショットの暗号化キーを使用して暗号化されます。 **注記** 暗号化された DB スナップショットから 非暗号化の DB クラスターを作成することはできません。 + `--snapshot-identifier` – 移行する DB スナップショットの Amazon リソースネーム (ARN)。Amazon RDS ARN の詳細については、「[Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-rds)」を参照してください。 `RestoreDBClusterFromSnapshot` コマンドを使用して DB スナップショットを移行すると、DB クラスターとプライマリインスタンスの両方がこのコマンドによって作成されます。 この例では、*mydbcluster* という名前の MySQL 5.7 互換 DB クラスターを ARN が *mydbsnapshotARN* に設定されている DB スナップショットから作成します。 Linux、macOS、Unix の場合: ``` aws rds restore-db-cluster-from-snapshot \ --db-cluster-identifier mydbcluster \ --snapshot-identifier mydbsnapshotARN \ --engine aurora-mysql ``` Windows の場合: ``` aws rds restore-db-cluster-from-snapshot ^ --db-cluster-identifier mydbcluster ^ --snapshot-identifier mydbsnapshotARN ^ --engine aurora-mysql ``` この例では、*mydbcluster* という名前の MySQL 5.7 互換 DB クラスターを ARN が *mydbsnapshotARN* に設定されている DB スナップショットから作成します。 Linux、macOS、Unix の場合: ``` aws rds restore-db-cluster-from-snapshot \ --db-cluster-identifier mydbcluster \ --snapshot-identifier mydbsnapshotARN \ --engine aurora-mysql ``` Windows の場合: ``` aws rds restore-db-cluster-from-snapshot ^ --db-cluster-identifier mydbcluster ^ --snapshot-identifier mydbsnapshotARN ^ --engine aurora-mysql ``` # Aurora リードレプリカを使用した、RDS for MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターへのデータの移行 Aurora は、MySQL DB エンジンのバイナリログレプリケーション機能を使用して、ソース RDS for MySQL DB インスタンスの Aurora リードレプリカと呼ばれる特殊なタイプの DB クラスターを作成します。ソース RDS for MySQL DB インスタンスに加えられた更新は、Aurora リードレプリカに非同期的にレプリケートされます。 ソース RDS for MySQL DB インスタンスの Aurora リードレプリカを作成して RDS for MySQL DB インスタンスから Aurora MySQL DB クラスターに移行する場合は、この機能を使用することをお勧めします。RDS for MySQL DB インスタンスと Aurora リードレプリカとの間のレプリカラグが 0 の場合は、クライアントアプリケーションを Aurora リードレプリカに誘導してからレプリケーションを停止することで、Aurora リードレプリカをスタンドアロンの Aurora MySQL DB クラスターにすることができます。移行では、データの 1 テビバイト (TiB) ごとに数時間程度の時間がかかります。 Aurora を使用できるリージョンの一覧は、*AWS 全般のリファレンス* の「[Amazon Aurora](https://docs.aws.amazon.com/general/latest/gr/rande.html#aurora)」を参照してください。 RDS for MySQL DB インスタンスの Aurora リードレプリカを作成すると、Amazon RDS により、ソース RDS for MySQL DB インスタンスの DB スナップショットが作成されます (このスナップショットは Amazon RDS に対してプライベートで、料金はかかりません)。その後 Amazon RDS は、DB スナップショットから Aurora リードレプリカにデータを移行します。DB スナップショットのデータが新しい Aurora MySQL DB クラスターに移行された後、Amazon RDS は、RDS for MySQL DB インスタンスと Aurora MySQL DB クラスターとの間でレプリケーションをスタートします。RDS for MySQL DB インスタンスに、InnoDB 以外のストレージエンジンを使用するテーブルまたは圧縮行形式を使用するテーブルが含まれている場合は、Aurora リードレプリカを作成する前に InnoDB ストレージエンジンと動的行形式が使用されるようにテーブルを変更することで、Aurora リードレプリカの作成プロセスをスピードアップできます。MySQL DB スナップショットを Aurora MySQL DB クラスターにコピーするプロセスの詳細については、「[RDS for MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターへのデータの移行](AuroraMySQL.Migrating.RDSMySQL.md)」を参照してください。 1 つの RDS for MySQL DB インスタンスに対して作成できる Aurora リードレプリカは、1 つだけです。 **注記** レプリケーションプライマリである RDS for MySQL DB インスタンスの MySQL データベースエンジンバージョンと Aurora MySQL との間に存在する特性の相違が原因で、レプリケーションの問題が発生することがあります。エラーが発生した場合のサポートについては、[Amazon RDS コミュニティフォーラム](https://forums.aws.amazon.com/forum.jspa?forumID=60)を参照するか、AWS サポートまでお問い合わせください。 RDS for MySQL DB インスタンスに既に Aurora リードレプリカのソースがある場合は、Aurora リードレプリカを作成できません。 8.0.11、8.0.13、8.0.15 などの一部の古い RDS for MySQL 8.0 バージョンからは Aurora MySQL バージョン 3.05 以上に移行できません。移行する前に RDS for MySQL バージョン 8.0.28 にアップグレードすることをお勧めします。 MySQL リードレプリカの詳細については、「[MariaDB、MySQL、PostgreSQL DB インスタンスのリードレプリカの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)」を参照してください。 ## Aurora リードレプリカの作成 コンソール、AWS CLI、または RDS API を使用して、RDS for MySQL DB インスタンスの Aurora リードレプリカを作成できます。 ### コンソール **ソース RDS for MySQL DB インスタンスから Aurora リードレプリカを作成するには** 1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。 1. ナビゲーションペインで、[**データベース**] を選択します。 1. Aurora リードレプリカの出典として使用する MySQL DB インスタンスを選択します。 1. [**アクション**] で [**Aurora リードレプリカの作成**] を選択します。 1. 次の表の説明に従って、Aurora リードレプリカに使用する DB クラスターの仕様を選択します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.RDSMySQL.Replica.html) 1. [**Create read replica**] を選択します。 ### AWS CLI ソース RDS for MySQL DB インスタンスから Aurora リードレプリカを作成するには、AWS CLI コマンドの [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) と [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) を使用して、新しい Aurora MySQL DB クラスターを作成します。`create-db-cluster` コマンドを呼び出すときは、`--replication-source-identifier` パラメータを含めて、出典 MySQL DB インスタンスの Amazon リソースネーム (ARN) を指定します。Amazon RDS ARN の詳細については、「[Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-rds)」を参照してください。 出典 MySQL DB インスタンスと同じマスターユーザーネーム、マスターパスワード、またはデータベース名を Aurora リードレプリカで指定しないでください。 Linux、macOS、Unix の場合: ``` aws rds create-db-cluster --db-cluster-identifier sample-replica-cluster --engine aurora \ --db-subnet-group-name mysubnetgroup --vpc-security-group-ids sg-c7e5b0d2 \ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:db:primary-mysql-instance ``` Windows の場合: ``` aws rds create-db-cluster --db-cluster-identifier sample-replica-cluster --engine aurora ^ --db-subnet-group-name mysubnetgroup --vpc-security-group-ids sg-c7e5b0d2 ^ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:db:primary-mysql-instance ``` コンソールを使用して Aurora リードレプリカを作成すると、DB クラスターの Aurora リードレプリカのプライマリインスタンスが Aurora によって自動的に作成されます。AWS CLI を使用して Aurora リードレプリカを作成する場合、使用する DB クラスターのプライマリインスタンスを明示的に作成する必要があります。プライマリ インスタンスは、DB クラスターで作成される初期の DB インスタンスです。 以下のパラメータを指定して [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) AWS CLI コマンドを使用することで、DB クラスターにプライマリインスタンスを作成できます。 + `--db-cluster-identifier` DB クラスターの名前。 + `--db-instance-class` プライマリインスタンスに使用するための DB インスタンス名。 + `--db-instance-identifier` プライマリインスタンスの名前。 + `--engine aurora` この例では、*myinstanceclass* で指定される DB インスタンスクラスを使用して、*myreadreplicacluster* という名前の DB クラスターに *myreadreplicainstance* という名前のプライマリインスタンスを作成します。 **Example** Linux、macOS、Unix の場合: ``` aws rds create-db-instance \ --db-cluster-identifier myreadreplicacluster \ --db-instance-class myinstanceclass \ --db-instance-identifier myreadreplicainstance \ --engine aurora ``` Windows の場合: ``` aws rds create-db-instance ^ --db-cluster-identifier myreadreplicacluster ^ --db-instance-class myinstanceclass ^ --db-instance-identifier myreadreplicainstance ^ --engine aurora ``` ### RDS API ソース RDS for MySQL DB インスタンスから Aurora リードレプリカを作成するには、[https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) と [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) Amazon RDS API コマンドを使用して新しい Aurora DB クラスターとプライマリインスタンスを作成します。ソース RDS for MySQL DB インスタンスと同じマスターユーザーネーム、マスターパスワード、またはデータベース名と同じユーザーネーム、マスターパスワード、またはデータベース名を Aurora リードレプリカに指定しないでください。 以下のパラメータを指定して [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) Amazon RDS API コマンドを使用することで、RDS for MySQL DB インスタンスから Aurora リードレプリカに新しい Aurora DB クラスターを作成できます。 + `DBClusterIdentifier` 作成する DB クラスターの名前。 + `DBSubnetGroupName` この DB クラスターに関連付ける DB サブネットグループの名前。 + `Engine=aurora` + `KmsKeyId` MySQL DB インスタンスが暗号化されているかどうかによって、オプションで DB クラスターを暗号化する AWS KMS key。 + MySQL DB インスタンスが暗号化されていない場合は、暗号化キーを指定して保管時の DB クラスターを暗号化します。これを実行しない場合、保管時の DB クラスターはデフォルトでアカウントの暗号化キーを使用して暗号化されます。 + MySQL DB インスタンスが暗号化されている場合は、暗号化キーを指定し、その指定された暗号化キーを使用して保管時の DB クラスターを暗号化します。これを実行しない場合、保管時の DB クラスターは MySQL DB インスタンスの暗号化キーを使用して暗号化されます。 **注記** 暗号化された MySQL DB インスタンスから 非暗号化の DB クラスターを作成することはできません。 + `ReplicationSourceIdentifier` 送信元の MySQL DB インスタンスの Amazon リソースネーム (ARN)。Amazon RDS ARN の詳細については、「[Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-rds)」を参照してください。 + `VpcSecurityGroupIds` この DB クラスターに関連付ける EC2 VPC セキュリティグループのリスト。 この例では、ARN が *mysqlprimaryARN* に設定された元の MySQL DB インスタンスから、*mysubnetgroup* という名前の DB サブネットグループと *mysecuritygroup* という名前の VPC セキュリティグループに関連付けられる *myreadreplicacluster* という名前の DB クラスターを作成します。 **Example** ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBCluster &DBClusterIdentifier=myreadreplicacluster &DBSubnetGroupName=mysubnetgroup &Engine=aurora &ReplicationSourceIdentifier=mysqlprimaryARN &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &VpcSecurityGroupIds=mysecuritygroup &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20150927/us-east-1/rds/aws4_request &X-Amz-Date=20150927T164851Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=6a8f4bd6a98f649c75ea04a6b3929ecc75ac09739588391cd7250f5280e716db ``` コンソールを使用して Aurora リードレプリカを作成すると、DB クラスターの Aurora リードレプリカのプライマリインスタンスが Aurora によって自動的に作成されます。AWS CLI を使用して Aurora リードレプリカを作成する場合、使用する DB クラスターのプライマリインスタンスを明示的に作成する必要があります。プライマリ インスタンスは、DB クラスターで作成される初期の DB インスタンスです。 以下のパラメータを指定して [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) Amazon RDS API コマンドを使用することで、DB クラスターにプライマリインスタンスを作成できます。 + `DBClusterIdentifier` DB クラスターの名前。 + `DBInstanceClass` プライマリインスタンスに使用するための DB インスタンス名。 + `DBInstanceIdentifier` プライマリインスタンスの名前。 + `Engine=aurora` この例では、*myinstanceclass* で指定される DB インスタンスクラスを使用して、*myreadreplicacluster* という名前の DB クラスターに *myreadreplicainstance* という名前のプライマリインスタンスを作成します。 **Example** ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBInstance &DBClusterIdentifier=myreadreplicacluster &DBInstanceClass=myinstanceclass &DBInstanceIdentifier=myreadreplicainstance &Engine=aurora &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-09-01 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20140424/us-east-1/rds/aws4_request &X-Amz-Date=20140424T194844Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=bee4aabc750bf7dad0cd9e22b952bd6089d91e2a16592c2293e532eeaab8bc77 ``` ## Aurora リードレプリカの表示 AWS マネジメントコンソール または AWS CLI を使用すると、Aurora MySQL DB クラスターでの、MySQL から Aurora MySQL へのレプリケーション関係を確認できます。 ### コンソール **Aurora リードレプリカのプライマリ MySQL DB インスタンスを表示するには** 1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。 1. ナビゲーションペインで、[**データベース**] を選択します。 1. Aurora リードレプリカの DB クラスターを選択して、その詳細を表示します。プライマリの MySQL DB インスタンスの情報は、[**レプリケーション出典**] フィールドに表示されます。 ![\[MySQL プライマリを表示\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-repl6.png) ### AWS CLI AWS CLI により、Aurora MySQL DB クラスターでの Aurora MySQL レプリケーションと MySQL の関係性を確認するには、[https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) および [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) コマンドを使用します。 どの MySQL DB インスタンスがプライマリかを判別するには、[https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) を使用して、Aurora リードレプリカのクラスター識別子を `--db-cluster-identifier` オプションに指定します。レプリケーションのプライマリである DB インスタンスの ARN については、出力の `ReplicationSourceIdentifier` 要素を参照してください。 どの DB クラスターが Aurora リードレプリカであるかを判別するには、[https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) を使用して、MySQL DB インスタンスのインスタンス識別子を `--db-instance-identifier` オプションに指定します。Aurora リードレプリカの DB クラスター識別子については、出力の `ReadReplicaDBClusterIdentifiers` 要素を参照してください。 **Example** Linux、macOS、Unix の場合: ``` aws rds describe-db-clusters \ --db-cluster-identifier myreadreplicacluster ``` ``` aws rds describe-db-instances \ --db-instance-identifier mysqlprimary ``` Windows の場合: ``` aws rds describe-db-clusters ^ --db-cluster-identifier myreadreplicacluster ``` ``` aws rds describe-db-instances ^ --db-instance-identifier mysqlprimary ``` ## Aurora リードレプリカの昇格 移行が完了したら、AWS マネジメントコンソール または AWS CLI を使って、Aurora リードレプリカをスタンドアロンの DB クラスターに昇格することができます。 次に、Aurora リードレプリカのエンドポイントにクライアントアプリケーションを誘導できます。Aurora エンドポイントの詳細については、「[Amazon Aurora エンドポイント接続](Aurora.Overview.Endpoints.md)」を参照してください。昇格はすばやく完了し、昇格中も Aurora リードレプリカに対する読み取り/書き込みを行うことができます。ただし昇格中に、プライマリ MySQL DB インスタンスを削除したり、DB インスタンスと Aurora リードレプリカのリンクを解除する操作は行うことができません。 Aurora リードレプリカを昇格する前に、出典 MySQL DB インスタンスに対するトランザクションの書き込みをすべて停止し、Aurora リードレプリカのレプリカラグが 0 になるまで待ちます。Aurora リードレプリカのレプリカラグを確認するには、`SHOW SLAVE STATUS` (Aurora MySQL バージョン 2) または `SHOW REPLICA STATUS` (Aurora MySQL バージョン 3) コマンドを Aurora リードレプリカに対して呼び出します。[**マスターから数秒遅れ**] 値をチェックします。 プライマリへの書き込みトランザクションが停止し、レプリカラグが 0 になったら、Aurora リードレプリカへの書き込みがスタートできるようになります。それより前に Aurora リードレプリカへの書き込みを行い、MySQL プライマリでも変更されているテーブルを変更した場合、Aurora へのレプリケーションが失われるおそれがあります。その場合は、Aurora リードレプリカを削除して再作成する必要があります。 ### コンソール **Aurora リードレプリカを Aurora DB クラスターに昇格させるには** 1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。 1. ナビゲーションペインで、[**データベース**] を選択します。 1. Aurora リードレプリカの DB クラスターを選択します。 1. [**アクション**] で、[**Promote (昇格)**] を選択します。 1. [**リードレプリカの昇格**] を選択します。 昇格したら、以下の手順を実行して昇格が完了したことを確認します。 **Aurora リードレプリカが昇格したことを確認するには** 1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。 1. ナビゲーションペインの [**Events**] を選択します。 1. [**イベント**] ページで、昇格したクラスターの `Promoted Read Replica cluster to a stand-alone database cluster` イベントがあることを確認します。 昇格が完了したら、プライマリ MySQL DB インスタンスと Aurora リードレプリカのリンクは解除され、DB インスタンスは必要に応じて安全に削除できるようになります。 ### AWS CLI Aurora リードレプリカをスタンドアロン DB クラスターに昇格させるには、AWS CLI の [https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html) コマンドを使用します。 **Example** Linux、macOS、Unix の場合: ``` aws rds promote-read-replica-db-cluster \ --db-cluster-identifier myreadreplicacluster ``` Windows の場合: ``` aws rds promote-read-replica-db-cluster ^ --db-cluster-identifier myreadreplicacluster ```