Amazon Aurora
Aurora のユーザーガイド

外部の MySQL データベースから Amazon Aurora MySQL DB クラスターへのデータ移行

データベースが InnoDB または MyISAM のテーブルスペースをサポートしている場合、これらのオプションを使用して、データを Amazon Aurora MySQL DB クラスターに移行できます。

  • mysqldump ユーティリティを使用してデータのダンプを作成し、そのデータを既存の Amazon Aurora MySQL DB クラスターにインポートできます。詳細については、「mysqldump を使用した MySQL から Amazon Aurora への移行」を参照してください。

  • これで、データベースから Amazon S3 バケットに完全および増分バックアップファイルをコピーし、これらのファイルから Amazon Aurora MySQL DB クラスターを復元できます。このオプションは、mysqldump を使用したデータの移行よりもかなり高速になる場合があります。詳細については、「Amazon S3 バケットを使用した MySQL からのデータ移行」を参照してください。

Amazon S3 バケットを使用した MySQL からのデータ移行

完全バックアップファイルと増分バックアップファイルをソースの MySQL バージョン 5.5、5.6、または 5.7 データベースから Amazon S3 バケットにコピーし、これらのファイルから Amazon Aurora MySQL DB クラスターを復元できます。

このオプションは、mysqldump を使用したデータ移行よりもかなり高速になる場合があります。これは、mysqldump を使用することですべてのコマンドが再生され、新しい Aurora MySQL DB クラスターのソースデータベースからスキーマとデータが再作成されるためです。ソース MySQL データファイルをコピーすることで、Aurora MySQL はこれらのファイルを即座に Aurora MySQL DB クラスター用のデータとして使用できます。

注記

Amazon S3 バケットと Amazon Aurora MySQL DB クラスターは同じ AWS リージョンに存在する必要があります。

Aurora MySQL は、データベースからすべてを復元するわけではありません。ソース MySQL データベースからデータベーススキーマと以下の項目の値を保存し、作成後に復元された Aurora MySQL DB クラスターに追加する必要があります。

  • ユーザーアカウント

  • 関数

  • ストアドプロシージャ

  • タイムゾーン情報。タイムゾーン情報は、Amazon Aurora MySQL DB クラスターのローカルオペレーティングシステムからロードされます。詳細については、「Amazon Aurora DB クラスターのローカルタイムゾーン」を参照してください。

暗号化されたソースデータベースから復元することはできませんが、移行するデータを暗号化することはできます。移行プロセス中にデータを非暗号化のまま維持することもできます。

また、移行プロセス中にバイナリログレプリケーションを使用してダウンタイムを最小化するかどうかを決定します。バイナリログのレプリケーションを使用すると、Aurora MySQL DB クラスターにデータ移動中に外部 MySQL データベースがオープンのままになります。Aurora MySQL DB クラスターが作成されたら、バイナリログレプリケーションを使用して、Aurora MySQL DB クラスターとバックアップ後のトランザクションを同期します。Aurora MySQL DB クラスターが MySQL データベースに追いついたら、Aurora MySQL DB を新規のトランザクションに完全に切り替えて、移行を終了します。

開始する前に

Amazon S3 バケットにデータをコピーし、それらのファイルから DB クラスターを復元するには、事前に以下の作業を行う必要があります。

  • Percona XtraBackup をローカルサーバーにインストールします。

  • お客様に代わって Aurora MySQL が Amazon S3 バケットにアクセスすることを許可します。

Percona XtraBackup のインストール

Amazon Aurora では、Percona XtraBackup を使用して作成されたファイルから DB クラスターを復元できます。Percona XtraBackup は、「Download Percona XtraBackup」からインストールできます。

注記

MySQL 5.7 の移行では、Percona XtraBackup 2.4 を使用する必要があります。これより前の MySQL バージョンでは、Percona XtraBackup 2.3 または 2.4 を使用します。

必要なアクセス許可

MySQL データを Amazon Aurora MySQL DB クラスターに移行するには、複数のアクセス権限が必要です。

  • Amazon RDS による Amazon S3 バケットからの新しいクラスターの作成をリクエストするユーザーには、AWS アカウントのバケットを一覧表示するアクセス権限が必要です。このアクセス権限は、AWS Identity and Access Management (IAM) ポリシーを使用してユーザーに付与します。

  • Amazon RDS は、Amazon Aurora MySQL DB クラスターの作成に使用されるファイルを保存する Amazon S3 バケットに、お客様に代わってアクセスすることが許可されている必要があります。IAM サービスロールを使用して、Amazon RDS に必要なアクセス権限を付与します。

  • リクエストを実行するユーザーには、AWS アカウントの IAM ロールをリストするアクセス権限も必要です。

  • リクエストを実行するユーザーが IAM サービスロールを作成するか、Amazon RDS が IAM サービスロールを作成することをリクエストする場合 (コンソールを使用)、ユーザーには AWS アカウントの IAM ロールを作成するアクセス権限が必要です。

  • 移行プロセス中にデータを暗号化する場合には、移行を実行するユーザーの IAM ポリシーを更新して、バックアップの暗号化に使用した KMS キーへの RDS アクセス許可を付与します。手順については、「AWS KMS リソースにアクセスするための IAM ポリシーの作成」を参照してください。

たとえば、次の IAM ポリシーでは、コンソールを使用して IAM ロールのリスト、IAM ロールの作成、アカウントの Amazon S3 バケットのリスト、および KMS キーのリストを行うために必要な最小限のアクセス権限をユーザーに付与します。

{ "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 バケットに関連付けることができます。

{ "Version":"2012-10-17", "Statement":[ { "Sid":"AllowS3AccessRole", "Effect":"Allow", "Action":"iam:PassRole", "Resource":"arn:aws:iam::123456789012:role/S3Access" } ] }

IAM ユーザーのアクセス許可の詳細については、「ポリシーを使用したアクセスの管理」を参照してください。

IAM サービスロールの作成

[新規ロールの作成] オプション (このトピックで後述します) を選択して、AWS マネジメントコンソール でロールを作成することができます。このオプションを選択して新しいロールの名前を指定すると、この指定した名前を使用して Amazon RDS から Amazon S3 バケットにアクセスするために必要な IAM サービスロールが Amazon RDS で作成されます。

または、次の手順を使用して手動でロールを作成できます。

Amazon RDS が Amazon S3 にアクセスするための IAM ロールを作成するには

  1. Amazon S3 リソースにアクセスするための IAM ポリシーの作成」の各ステップを実行します。

  2. Amazon Aurora から AWS のサービスにアクセスすることを許可する IAM ロールの作成」の各ステップを実行します。

  3. IAM ロールと Amazon Aurora MySQL DB クラスターの関連付け」の各ステップを実行します。

Amazon Aurora MySQL DB クラスターとして復元するためのファイルのバックアップ

Percona XtraBackup を使用して MySQL データベースファイルの完全バックアップを作成し、そのバックアップファイルを Amazon S3 バケットにアップロードできます。または、Percona XtraBackup を使用して MySQL データベースファイルをバックアップ済みである場合は、既存の完全および増分バックアップディレクトリおよびファイルを Amazon S3 バケットにアップロードできます。

Percona XtraBackup での完全バックアップの作成

Amazon Aurora MySQL DB クラスターを作成するために Amazon S3 から復元できる、MySQL データベースファイルのフルバックアップを作成するには、Percona XtraBackup ユーティリティ (xtrabackup) を使用してデータベースをバックアップします。

たとえば、次のコマンドは MySQL データベースのバックアップを作成し、ファイルを /on-premises/s3-restore/backup フォルダに保存します。

xtrabackup --backup --user=<myuser> --password=<password> --target-dir=</on-premises/s3-restore/backup>

バックアップを 1 つのファイル (必要に応じて分割できます) に圧縮する場合、以下のいずれかの形式を使用して --stream オプションを使用してバックアップを保存できます。

  • Gzip (.gz)

  • tar (.tar)

  • Percona xbstream (.xbstream)

次のコマンドでは、複数の Gzip ファイルに分割された MySQL データベースのバックアップを作成します。

xtrabackup --backup --user=<myuser> --password=<password> --stream=tar \ --target-dir=</on-premises/s3-restore/backup> | gzip - | split -d --bytes=500MB \ - </on-premises/s3-restore/backup/backup>.tar.gz

次のコマンドでは、複数の tar ファイルに分割された MySQL データベースのバックアップを作成します。

xtrabackup --backup --user=<myuser> --password=<password> --stream=tar \ --target-dir=</on-premises/s3-restore/backup> | split -d --bytes=500MB \ - </on-premises/s3-restore/backup/backup>.tar

たとえば、次のコマンドでは、複数の xbstream ファイルに分割された MySQL データベースのバックアップを作成します。

xtrabackup --backup --user=<myuser> --password=<password> --stream=xbstream \ --target-dir=</on-premises/s3-restore/backup> | split -d --bytes=500MB \ - </on-premises/s3-restore/backup/backup>.xbstream

Percona XtraBackup ユーティリティを使用して MySQL データベースをバックアップしたら、バックアップディレクトリおよびファイルを Amazon S3 バケットにコピーできます。

ファイルを作成して Amazon S3 バケットにアップロードする方法については、Amazon S3 入門ガイドの「Amazon Simple Storage Service の開始方法」を参照してください。

Percona XtraBackup での増分バックアップの使用

Amazon Aurora MySQL は、Percona XtraBackup を使用して作成された完全バックアップおよび増分バックアップの両方をサポートしています。Percona XtraBackup を使用して MySQL データベースファイルの完全および増分バックアップを作成済みである場合は、完全バックアップを作成して Amazon S3 にアップロードする必要はありません。代わりに、既存の完全および増分バックアップのディレクトリおよびファイルを Amazon S3 バケットにコピーして、多大な時間を節約できます。Percona XtraBackup を使用した増分バックアップの作成の詳細については、「Incremental Backup」を参照してください。

既存の完全および増分バックアップファイルを Amazon S3 バケットにコピーするときは、ベースディレクトリのコンテンツを再帰的にコピーする必要があります。これらのコンテンツには、完全バックアップと、すべての増分バックアップディレクトリおよびファイルが含まれます。このコピーは、Amazon S3 バケットのディレクトリ構造を維持する必要があります。Aurora は、すべてのファイルとディレクトリを反復処理します。Aurora では、各増分バックアップに含まれている xtrabackup-checkpoints ファイルを使用してベースディレクトリを識別し、ログシーケンス番号 (LSN) の範囲に従って増分バックアップの順番を整理します。

ファイルを作成して Amazon S3 バケットにアップロードする方法については、Amazon S3 入門ガイドの「Amazon Simple Storage Service の開始方法」を参照してください。

バックアップに関する考慮事項

Amazon S3 バケットにファイルをアップロードしたら、サーバー側の暗号化を使用してデータを暗号化します。その後、この暗号化ファイルから Amazon Aurora MySQL DB クラスターを復元できます。Amazon Aurora MySQL は、以下のタイプのサーバー側の暗号化を使用してファイルが暗号化された DB クラスターを復元できます。

  • Amazon S3 管理キー (SSE-S3) によるサーバー側の暗号化。各オブジェクトは、強力な多要素暗号化を採用した一意のキーで暗号化されています。

  • AWS KMS 管理キー (SSE-KMS) によるサーバー側の暗号化。SSE-S3 に類似していますが、ユーザーによる暗号キーの作成と管理オプション、およびそのほかの違いがあります。

Amazon S3 バケットにファイルをアップロードするときにサーバー側の暗号化を使用する方法については、Amazon S3 開発者ガイドの「サーバー側の暗号化を使用したデータの保護」を参照してください。

Amazon S3 では、Amazon S3 バケットにアップロードするファイルのサイズが 5 テラバイト (TB) に制限されます。データベースのバックアップデータが 5 TB を超える場合は、split コマンドを使用して、それぞれが 5 TB 未満の複数のファイルにバックアップファイルを分割します。

Amazon RDS では、Amazon S3 バケットにアップロードするソースファイルの数が百万までに制限されます。場合によっては、すべての完全および増分バックアップを含むデータベースのバックアップデータには多数のファイルがあることがあります。この場合、tarball (.tar.gz) ファイルを使用して完全および増分バックアップを Amazon S3 バケットに保存します。

Aurora では、ファイル名に基づいてバックアップファイルを使用します。ファイル形式に基づいた適切なファイル拡張子でバックアップファイルの名前を付けてください。たとえば、Percona xbstream 形式を使用して保存されるファイルでは、.xbstream のようにします。

Aurora では、アルファベット順および通常の数値順にバックアップファイルを使用します。バックアップファイルが適切な順序で書き込まれ、名前が付けられるように、split コマンドを発行するときは必ず xtrabackup オプションを使用します。

Aurora では、Percona XtraBackup を使用して作成された部分バックアップがサポートされていません。データベースのソースファイルをバックアップするときに、--tables--tables-exclude--tables-file--databases--databases-exclude、または --databases-file オプションを使用して部分バックアップを作成することはできません。

Percona XtraBackup を使用したデータベースのバックアップの詳細については、Percona ウェブサイトの「Percona XtraBackup - Documentation」および「The xtrabackup Binary」を参照してください。

Aurora では、Percona XtraBackup を使用して作成された差分バックアップがサポートされています。Percona XtraBackup を使用した増分バックアップの作成の詳細については、「Incremental Backup」を参照してください。

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/) を開きます。

  2. Amazon RDS コンソールの右上で、DB インスタンスを作成する AWS リージョンを選択します。データベース バックアップを含む Amazon S3 バケットと同じ AWS リージョンを選択します。

  3. ナビゲーションペインで、[データベース]、[S3 から復元] の順に選択します。

  4. [エンジンの選択] ページで、[Amazon Aurora] を選択し、MySQL 互換エディションを選択して、[次へ] を選択します。

    [Specify source backup details] ページが表示されます。

    
                                Amazon S3 バケットからの Amazon Aurora の移行
  5. [Specify source backup details (ソースバックアップの詳細を指定)] で、以下を指定します。

    使用するオプション 操作

    Source engine

    現在、Aurora MySQL は mysql データベースエンジン用のバックアップファイルからの復元のみをサポートしています。

    ソースエンジンのバージョン

    ソースデータベースの MySQL バージョンを選択します。

    S3 バケット

    バックアップファイルを含む Amazon S3 バケットを選択します。

    S3 folder path prefix (optional)

    Amazon S3 バケットに保存されているファイルのファイルパスプレフィックスを指定します。[S3 バケットプレフィックス] はオプションです。プレフィックスを指定しない場合、Aurora MySQL は Amazon S3 バケットのルートフォルダにあるすべてのファイルとフォルダを使用して DB クラスターを作成します。プレフィックスを指定すると、Aurora MySQL はファイルのフルパスが指定されたプレフィックスで始まる Amazon S3 バケットのファイルとフォルダを使用して DB クラスターを作成します。

    Aurora は、Amazon S3 バケットの他のサブフォルダを走査してバックアップファイルを探しません。[S3 バケットプレフィックス] により識別されるフォルダのファイルのみ使用されます。バックアップファイルを Amazon S3 バケットのサブフォルダに保存する場合、ファイルが保存されるフォルダのフルパスを識別するプレフィックスを指定します。

    たとえば、バックアップファイルを Amazon S3 バケットの backups という名前のサブフォルダーに保管しているとします。そして、複数のバックアップファイルがそれぞれ独自のディレクトリ (gzip_backup1gzip_backup2 など) にあるとします。この場合、プレフィックス backups/gzip_backup1 を指定して、gzip_backup1 フォルダのファイルから復元することができます。

    新規ロールの作成

    [はい] を選択して新しい IAM ロールを作成するか、[いいえ] を選択して既存の IAM ロールから選択し、Aurora がユーザーに代わって Amazon S3 にアクセスすることを許可します。詳細については、「必要なアクセス許可」を参照してください。

    IAM ロール名

    このオプションは、[Create a new role] が [Yes] に設定されている場合にのみ使用できます。

    作成される新しい IAM ロールの名前を入力します。新しいロールは、ユーザーに代わって Amazon Aurora が Amazon S3 にアクセスすることを承認するために使用されます。詳細については、「必要なアクセス許可」を参照してください。

    IAM ロール

    このオプションは、[新規ロールの作成] が [いいえ] に設定されている場合にのみ使用できます。

    お客様に代わって Amazon S3 にアクセスすることを Aurora に許可するために作成した IAM ロールを選択します。IAM ロールを作成していない場合は、代わりに [新しいロールの作成] を [はい] に設定して作成できます。詳細については、「必要なアクセス許可」を参照してください。

    KMS キーへのアクセスを許可する

    このオプションは、[Create a new role] が [Yes] に設定されている場合にのみ使用できます。

    バックアップファイルを暗号化していない場合には、[いいえ] を選択します。

    Amazon S3 にバックアップファイルをアップロードするときにこのファイルを AES-256 (SSE-S3) で暗号化した場合には、[いいえ] を選択します。この場合、このデータは自動的に復号されます。

    Amazon S3 にバックアップファイルをアップロードするときにこのファイルを AWS-KMS (SSE-KMS) サーバー側の暗号化を実行した場合には、[はい] を選択します。次に、マスターキーに適切な [マスターキー] を選択します。AWS マネジメントコンソール は、Amazon RDS がデータを復号できるように IAM ポリシーを作成します。

    詳細については、Amazon S3 開発者ガイドの「サーバー側の暗号化を使用したデータの保護」を参照してください。

  6. [次へ] を選択します。

  7. [DB 詳細の指定] ページで、DB クラスターの情報を指定します。

    一般的な [Specify DB details] ページは以下のようになります。

    
                                Amazon Aurora の詳細

    次の表は、DB インスタンスの設定を示しています。

    使用するオプション 操作

    キャパシティータイプ

    DB インスタンスのキャパシティーを手動で管理するには、[プロビジョニング済み] を選択します。ワークロードの変動に応じてインスタンスの DB インスタンスクラスの変更が必要になる場合があります。

    DB インスタンスのキャパシティーを手動で管理するには、[Provisioned with Aurora parallel query enabled (Aurora 並列クエリを有効にしてプロビジョニング済み)] を選択します。このオプションにより、Aurora は、Aurora ストレージレイヤー (現在 Aurora MySQL 5.6 で使用可能) に処理をプッシュダウンすることで、分析クエリのパフォーマンスを改善します。詳細については、「Amazon Aurora MySQL の並列クエリの操作」を参照してください。

    DB インスタンスに使用できるキャパシティーを自動的に管理するには、Aurora の [サーバーレス] を選択します。詳細については、「Amazon Aurora サーバーレスの使用」を参照してください。

    DB エンジンバージョン

    プロビジョニング済みのキャパシティータイプにのみ適用されます。DB エンジンのバージョン番号を選択します。

    DB インスタンスクラス

    DB クラスターの各インスタンスに対する処理要件やメモリ要件を定義する DB インスタンスクラスを選択します。DB インスタンスクラスの詳細については、「DB インスタンスクラスの選択」を参照してください。

    マルチ AZ 配置

    フェイルオーバーのサポート用に他のアベイラビリティーゾーンで Aurora レプリカを作成するかどうかを決めます。[Create Replica in Different Zone (別のゾーンにレプリカを作成)] を選択した場合、Amazon RDS は使用している DB クラスターのプライマリインスタンスではなく、別のアベイラビリティーゾーンの DB クラスターの Aurora レプリカを作成します。複数のアベイラビリティーゾーンの詳細については、「リージョンとアベイラビリティーゾーンの選択」を参照してください。

    DB インスタンス識別子

    DB クラスターのプライマリインスタンスの名前を入力します。この識別子は、DB クラスターのプライマリインスタンスのエンドポイントアドレスで使用されます。

    DB インスタンス識別子には次の制約があります。

    • 1 ~ 63 文字の英数字またはハイフンを使用する必要があります。

    • 1 字目は文字である必要があります。

    • ハイフンを、文字列の最後に使用したり、2 つ続けて使用したりすることはできません。

    • 各 AWS リージョンの各 AWS アカウントのすべての DB インスタンスの中で一意である必要があります。

    マスターユーザー名

    DB クラスターにログオンするためのマスターユーザー名を英数字で入力します。

    マスターパスワード

    マスターユーザーのパスワードを 8 ~ 41 文字で入力します。使用できるのは印刷可能な ASCII 文字 (/、"、@ を除く) です。

  8. [次へ] を選択します。

  9. [詳細設定の構成] ページで、Aurora MySQL DB クラスターのその他の設定をカスタマイズできます。次の表は、DB クラスターの詳細設定を示しています。

    使用するオプション 操作

    Virtual Private Cloud (VPC)

    DB クラスターをホストする VPC を選択します。[Create a New VPC] を選択して、Amazon RDS で VPC を作成します。詳細については、このトピックで前述した「DB クラスターの前提条件」を参照してください。

    サブネットグループ

    DB クラスターで使用する DB サブネットグループを選択します。詳細については、このトピックで前述した「DB クラスターの前提条件」を参照してください。

    パブリックアクセシビリティ

    DB クラスターにパブリック IP アドレスを指定するには [Yes] を選択します。それ以外の場合は [No] を選択します。DB クラスターのインスタンスでは、パブリック DB インスタンスとプライベート DB インスタンスの両方を混在させることができます。パブリックアクセスからインスタンスを隠す方法については、「VPC の DB インスタンスをインターネットから隠す」を参照してください。

    アベイラビリティーゾーン

    特定のアベイラビリティーゾーンを指定するかどうかを指定します。利用可能ゾーンについての詳細は、リージョンとアベイラビリティーゾーンの選択 を参照してください。

    VPC セキュリティグループ

    [Create new VPC security group (新しい VPC セキュリティグループの作成)] を選択すると、Amazon RDS によって VPC セキュリティグループが作成されます。または、[Select existing VPC security groups] を選択し、DB クラスターへのネットワークアクセスの保護用に 1 つ以上の VPC セキュリティグループを指定します。詳細については、このトピックで前述した「DB クラスターの前提条件」を参照してください。

    DB クラスター識別子

    DB クラスターの名前を入力します。この名前は選択した AWS リージョン内で、アカウントに対して一意である必要があります。この識別子は、DB クラスターのクラスターエンドポイントアドレスで使用されます。クラスターエンドポイントの詳細については、「Amazon Aurora 接続管理」を参照してください。

    DB クラスター識別子には以下の制約があります。

    • 1 ~ 63 文字の英数字またはハイフンを使用する必要があります。

    • 1 字目は文字である必要があります。

    • ハイフンを、文字列の最後に使用したり、2 つ続けて使用したりすることはできません。

    • 各 AWS リージョンのそれぞれの AWS アカウントのすべての DB クラスターの中で一意である必要があります。

    データベース名

    デフォルトデータベースの名前を英数字 64 文字以内で入力します。名前の指定がない場合、Amazon RDS は作成中の DB クラスターにデータベースを作成しません。

    追加のデータベースを作成するには、DB クラスターに接続し、SQL コマンド CREATE DATABASE を使用します。DB クラスターへの接続の詳細については、「Amazon Aurora DB クラスターへの接続」を参照してください。

    データベースポート

    データベースのアクセスに使用するために、アプリケーションやユーティリティのポートを指定します。デフォルトでは、Aurora MySQL DB クラスターはデフォルトの MySQL ポート 3306 に設定され、Aurora PostgreSQL DB クラスターはデフォルトの PostgreSQL である 5432 に設定されます。会社のファイアウォールによっては、これらのデフォルトポートへの接続がブロックされます。会社のファイアウォールがデフォルトのポートをブロックする場合は、新しい DB クラスター用に別のポートを選択します。

    DB パラメータグループ

    パラメータグループを選択します。Aurora にはデフォルトのパラメータグループが用意されています。また、独自のパラメータグループを作成することもできます。パラメータグループの詳細については、「DB パラメータグループおよび DB クラスターパラメータグループを使用する」を参照してください。

    DB クラスターのパラメータグループ

    DB クラスターパラメータグループを選択します。Aurora にはデフォルトの DB クラスターパラメータグループが用意されています。また、独自の DB クラスターパラメータグループを作成することもできます。DB クラスターパラメータグループの詳細については、「DB パラメータグループおよび DB クラスターパラメータグループを使用する」を参照してください。

    オプショングループ

    Aurora にはデフォルトのオプショングループがあります。

    暗号化

    この DB クラスターを保管時に暗号化するには、[Enable Encryption] を選択します。詳細については、「Amazon Aurora リソースの暗号化」を参照してください。

    マスターキー

    [Encryption] が [Enable Encryption] に設定されている場合にのみ使用できます。この DB クラスターの暗号化に使用するにマスターキーを選択します。詳細については、「Amazon Aurora リソースの暗号化」を参照してください。

    優先度

    インスタンスのフェイルオーバー優先度を選択します。値を選択しない場合、デフォルト値は tier-1 になります。この優先度により、プライマリインスタンスの障害からの復旧時に、Aurora レプリカを昇格する順序が決まります。詳細については、「Aurora DB クラスターの耐障害性」を参照してください。

    バックアップ保持期間

    Aurora がデータベースのバックアップコピーを保持する期間 (1〜35 日) を選択します。バックアップコピーは、2 番目のデータベースに対するポイントインタイム復元 (PITR) で使用できます。

    バックトラック

    バックトラックを有効にするには [バックトラックを有効にする] を選択し、バックトラックを無効にするには [バックトラックを無効にする] を選択します。バックトラックを使用して、新しい DB クラスターを作成せずに、特定時点に DB クラスターを巻き戻すことができます。デフォルトでは無効となっています。バックトラッキングを有効にする場合は、DB クラスターをバックトラックできる時間 (ターゲットのバックトラックウィンドウ) も指定します。詳細については、「Aurora DB クラスターのバックトラック」を参照してください。

    拡張モニタリング

    DB クラスターが実行されているオペレーティングシステムに対してリアルタイムでのメトリクスの収集を有効にするには、[Enable enhanced monitoring] を選択します。詳細については、「拡張モニタリング」を参照してください。

    モニタリングロール

    [Enhanced Monitoring] が [Enable enhanced monitoring] に設定されている場合にのみ使用できます。Amazon CloudWatch Logs との通信を Amazon RDS に許可するために作成した IAM ロールを選択するか、[デフォルト] を選択して、RDS によって rds-monitoring-role という名前のロールが作成されるようにします。詳細については、「拡張モニタリング」を参照してください。

    詳細度

    [Enhanced Monitoring] が [Enable enhanced monitoring] に設定されている場合にのみ使用できます。DB クラスターのメトリクスを収集する間隔を秒単位で設定します。

    ログのエクスポート

    Amazon CloudWatch Logs に発行するログを選択します。CloudWatch Logs への発行の詳細については、「Amazon Aurora MySQL への Amazon CloudWatch Logs ログの発行」を参照してください。

    マイナーバージョン自動アップグレード

    この設定は Aurora MySQL DB クラスターには適用されません。

    Aurora MySQL のエンジンに関する更新の詳細については、「Amazon Aurora MySQL のデータベースエンジンの更新」を参照してください。

    Maintenance window

    [Select window] を選択し、システムメンテナンスが実行される期間を週単位で指定します。または、[指定なし] を選択して、Amazon RDS によって期間がランダムに割り当てられるようにします。

    削除保護の有効化 DB クラスターが削除されないようにするには [Enable deletion protection (削除保護の有効化)] を選択します。コンソールで本稼働 DB クラスターを作成する場合、デフォルトで削除保護は有効です。
  10. [Create database (データベースの作成)] を選択して Aurora DB インスタンスを起動し、[閉じる] を選択してウィザードを閉じます。

Amazon RDS コンソールでは、新しい DB インスタンスが DB インスタンスのリストに表示されます。DB インスタンスが作成されて使用できるようになるまで、DB インスタンスのステータスは creating となります。ステータスが [available] に変わったら、DB クラスターのプライマリインスタンスに接続できます。DB インスタンスクラスと割り当てられたストレージによっては、新しいインスタンスを使用できるようになるまで数分かかることがあります。

新しく作成したクラスターを表示するには、Amazon RDS コンソールで [データベース] ビューを選択し、DB クラスターを選択します。詳細については、「Amazon Aurora DB クラスターの表示」を参照してください。


                        Amazon Aurora DB インスタンスリスト

DB クラスターのポートと書き込みエンドポイントをメモします。DB クラスターの書き込みエンドポイントとポートは、書き込みまたは読み取りオペレーションを実行するすべてのアプリケーションの JDBC 接続文字列と ODBC 接続文字列で使用します。

レプリケーションを使用して、Amazon Aurora MySQL DB クラスターと MySQL データベースを同期する

移行中のダウンタイムを減少あるいはなくすためには、Aurora MySQL DB クラスターに対して MySQL データベースで行われるトランザクションをレプリケートできます。レプリケーションは、移行中に発生する MySQL データベース上のトランザクションに DB クラスターが追いつくようにします。DB クラスターが完全に追いついたら、レプリケーションを停止し、Aurora MySQL への移行を終了できます。

暗号化レプリケーションのために、外部の MySQL データベースおよび Aurora MySQL DB クラスターを設定する

データを安全に複製するには、暗号化されたレプリケーションを使用できます。

注記

暗号化レプリケーションを使う必要がない場合、このステップをスキップして、「Amazon Aurora MySQL DB クラスターと外部の MySQL データベースを同期する」の手順に進むことができます。

暗号化レプリケーションを使用するための前提条件は次のとおりです。

  • Secure Sockets Layer (SSL) は、外部の MySQL マスターデータベースで有効化されている必要があります。

  • クライアントのキーとクライアントの証明書が Aurora MySQL DB クラスター用に準備されている必要があります。

暗号化のレプリケーション中、Aurora MySQL DB クラスターはクライアントとして MySQL データベースサーバーに動作します。Aurora MySQL 用の証明書およびキーは、.pem 形式のファイルにあります。

注記

現在、外部の MySQL データベースからの暗号化されたレプリケーションは Aurora MySQL バージョン 5.6 でのみサポートされています。

暗号化レプリケーションのために、外部の MySQL データベースおよび Aurora MySQL DB クラスターを設定するには

  1. 暗号化レプリケーションのための準備があることを確認してください。

    • 外部の MySQL マスターデータベースで有効化された SSL がなく、またクライアントキーおよびクライアント証明書が準備されていない場合、MySQL データベースサーバーで SSL を有効にし、必要なクライアントキーおよびクライアントの証明書を生成します。

    • SSL が外部マスターで有効化されている場合には、Aurora MySQL DB クラスターにクライアントキーおよび証明書を提供します。これらがない場合は、Aurora MySQL DB クラスター用に新しいキーと証明書を生成します。クライアント証明書に署名するには、外部の MySQL マスターデータベースで SSL を設定した際に使用した認証機関キーがあることが必要です。

    詳細については、MySQL のドキュメントの「Creating SSL Certificates and Keys Using openssl (openssl を使用した SSL 証明書およびキーの作成)」を参照してください。

    認証機関証明書、クライアントキーおよびクライアント証明書が必要となります。

  2. SSL を使用して、マスターユーザーとして Aurora MySQL DB クラスターに接続します。

    SSL で Aurora MySQL DB クラスターに接続する詳細については、「Aurora MySQL DB クラスターでの SSL の使用」を参照してください。

  3. 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_import_binlog_ssl_material」、「Aurora MySQL DB クラスターでの SSL の使用」を参照してください。

    注記

    手順を実行したあと、シークレットはファイルに保存されます。ファイルを削除するには、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)
  2. レプリケーションで開始するバイナリログの位置を決定します。

    1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

    2. ナビゲーションペインの [Events] を選択します。

    3. [イベント] リストで、[Recovered from Binary log filename (バイナリログのファイル名から復旧済み)] イベントの位置をメモします。

      
                                        MySQL マスターの表示

      レプリケーションを開始する位置は後の手順で指定します。

  3. 外部の MySQL データベースに接続したら、レプリケーションに使用するユーザーを作成します。このアカウントはレプリケーション専用に使用され、セキュリティを強化するためにドメインに制限する必要があります。次に例を示します。

    mysql> CREATE USER '<user_name>'@'<domain_name>' IDENTIFIED BY '<password>';

    ユーザーには REPLICATION CLIENT および REPLICATION SLAVE 権限が必要です。ユーザーのこれらの権限を付与します。

    GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO '<user_name>'@'<domain_name>';

    暗号化レプリケーションを使用する必要がある場合は、レプリケーションのユーザーに対して SSL 接続を要求します。たとえば、以下のステートメントを使用して、ユーザーアカウント <user_name> に SSL 接続を要求できます。

    GRANT USAGE ON *.* TO '<user_name>'@'<domain_name>' REQUIRE SSL;

    注記

    REQUIRE SSL が含まれていない場合には、レプリケーション接続がメッセージの表示なしで非暗号化接続に戻る場合があります。

  4. Amazon RDS マネジメントコンソールで、外部 MySQL データベースをホストするサーバーの IP アドレスを、Aurora MySQL DB クラスターの VPC セキュリティグループに追加します。VPC セキュリティグループの変更方法の詳細については、Amazon Virtual Private Cloud ユーザーガイドの「VPC のセキュリティグループ」を参照してください。

    外部の MySQL データベースと通信できるようにするために、Aurora MySQL DB クラスターの IP アドレスからの接続を許可するようにローカルネットワークを設定することも必要になる場合があります。Aurora MySQL DB クラスターの IP アドレスを確認するには、host コマンドを使用します。

    host RDS_MySQL_DB_<host_name>

    このホスト名は、Aurora MySQL DB クラスターのエンドポイントからの DNS 名です。

  5. mysql.rds_set_external_master ストアプロシージャを実行して、バイナリログレプリケーションを有効化します。このストアプロシージャの構文は次のとおりです。

    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 );

    パラメータについては、「mysql_rds_set_external_master」を参照してください。

    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);

    このストアプロシージャは、外部の MySQL データベースに接続し、そのバイナリログを読み取るために Aurora MySQL DB クラスターが使用するパラメータを設定します。データが暗号化されている場合には、SSL 認証機関証明書、クライアント証明書およびクライアントキーもローカルディスクにダウンロードされます。

  6. mysql.rds_start_replication ストアプロシージャを実行して、バイナリログレプリケーションを開始します。

    CALL mysql.rds_start_replication;
  7. Aurora MySQL DB クラスターが MySQL レプリケーションマスターデータベースよりどれだけ遅れているかをモニタリングします。そのためには、Aurora MySQL DB クラスターに接続し、次のコマンドを実行します。

    SHOW SLAVE STATUS;

    このコマンドの出力の Seconds Behind Master フィールドには、Aurora MySQL DB クラスターがどれだけ MySQL マスターより遅れているかが示されます。この値が 0 (ゼロ) の場合、Aurora MySQL DB クラスターがマスターに追いついたことを示し、レプリケーションを停止するための次のステップに進むことができます。

  8. MySQL レプリケーションのマスターデータベースに接続して、レプリケーションを停止します。そうするには、以下のコマンドを実行します。

    CALL mysql.rds_stop_replication;

mysqldump を使用した MySQL から Amazon Aurora への移行

Amazon Aurora MySQL は MySQL と互換性があるデータベースであるため、mysqldump ユーティリティを使用して MySQL または MariaDB データベースから既存の Aurora MySQL DB クラスターにデータをコピーできます。

巨大な MySQL データベースを使用する方法については、「わずかなダウンタイムでの Amazon RDS MySQL または MariaDB DB インスタンスへのデータのインポート」を参照してくださいデータ量の少ない MySQL データベースについては、「MySQL DB または MariaDB DB から Amazon RDS MySQL または MariaDB DB インスタンスへのデータのインポート」を参照してください。