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 データベースを同期する」を参照してください。
目次
制約事項と考慮事項
Amazon S3 バケットから Amazon Aurora MySQL DB クラスターに移行する場合は、以下の制限と考慮事項が当てはまります。
-
データは既存の DB クラスターではなく、新しい DB クラスターにのみ移行できます。
-
Percona XtraBackup を使用してデータを S3 にバックアップする必要があります。詳細については、「Percona 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 インスタンスクラス」を参照してください。
-
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' を使用して保存されたオブジェクトおよびAmazon Aurora MySQL でのマスターユーザー特権を参照してください。 -
Aurora MySQL DB クラスターを作成すると、サポートされている最大の権限を持つマスターユーザーが作成されます。バックアップから復元する際、インポート中のユーザーに割り当てられたサポートされていない権限は、インポート中に自動的に削除されます。
この影響を受ける可能性のあるユーザーを特定するには、「サポートされていない権限を持つユーザーアカウント」を参照してください。Aurora MySQL でサポートされる権限の詳細については、「ロールベースの特権モデル」を参照してください。
-
-
Aurora MySQL バージョン 3 の場合、動的権限はインポートされません。Aurora がサポートする動的権限は、移行後にインポートできます。詳細については、「Aurora MySQL バージョン 3 に対する動的権限」を参照してください。
-
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 クラスターのローカルタイムゾーン」を参照してください。
-
開始する前に
Amazon S3 バケットにデータをコピーし、それらのファイルから DB クラスターを復元するには、事前に以下の作業を行う必要があります。
-
Percona XtraBackup をローカルサーバーにインストールします。
-
お客様に代わって Aurora MySQL が Amazon S3 バケットにアクセスすることを許可します。
Percona XtraBackup のインストール
Amazon Aurora では、Percona XtraBackup を使用して作成されたファイルから DB クラスターを復元できます。Percona XtraBackup は、「ソフトウェアのダウンロード - Percona
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 ポリシーの作成 を参照してください。
例えば、次の 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 Management Console でロールを作成することができます。このオプションを選択して新しいロールの名前を指定すると、この指定した名前を使用して Aurora から Amazon S3 バケットにアクセスするために必要な IAM サービスロールが Aurora で作成されます。
または、次の手順を使用して手動でロールを作成できます。
Aurora から Amazon S3 にアクセスするための IAM ロールを作成するには
-
「Amazon S3 リソースにアクセスするための IAM ポリシーの作成」の各ステップを実行します。
-
「Amazon Aurora が AWS のサービスにアクセスすることを許可する IAM ロールの作成」の各ステップを実行します。
-
「IAM ロールと Amazon Aurora MySQL DB クラスターの関連付け」の各ステップを実行します。
Amazon Aurora MySQL DB クラスターとして復元するファイルのバックアップ
Percona XtraBackup を使用して MySQL データベースファイルの完全バックアップを作成し、そのバックアップファイルを Amazon S3 バケットにアップロードできます。または、Percona XtraBackup を使用して MySQL データベースファイルをバックアップ済みである場合は、既存の完全および増分バックアップディレクトリおよびファイルを Amazon S3 バケットにアップロードできます。
Percona XtraBackup での完全バックアップの作成
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
注記
次のエラーが表示される場合は、コマンドにファイル形式が混在していることが原因となっている可能性があります。
ERROR:/bin/tar: This does not look like a tar archive
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 のウェブサイトで「インクリメンタルバックアップを作成する
既存の完全および増分バックアップファイルを Amazon S3 バケットにコピーするときは、ベースディレクトリのコンテンツを再帰的にコピーする必要があります。これらのコンテンツには、完全バックアップと、すべての増分バックアップディレクトリおよびファイルが含まれます。このコピーには、Amazon S3 バケットのディレクトリ構造を維持する必要があります。Aurora は、すべてのファイルとディレクトリを反復処理します。Aurora は、増分バックアップを含む xtrabackup-checkpoints
ファイルを使用し、ベースディレクトリを識別します。また、ログシーケンス番号 (LSN) の範囲に従って増分バックアップを整列させます。
ファイルを作成して Amazon S3 バケットにアップロードする方法については、Amazon S3 入門ガイドの「Amazon Simple Storage Service のスタート方法」を参照してください。
バックアップに関する考慮事項
Aurora では、Percona XtraBackup を使用して作成された部分バックアップがサポートされていません。データベースの出典ファイルをバックアップするときに、--tables
、--tables-exclude
、--tables-file
、--databases
、--databases-exclude
、または --databases-file
オプションを使用して部分バックアップを作成することはできません。
Percona XtraBackup を使用したデータベースのバックアップの詳細については、Percona ウェブサイトの「Percona XtraBackup - ドキュメント
Aurora では、Percona XtraBackup を使用して作成された差分バックアップがサポートされています。詳細については、Percona のウェブサイトで「インクリメンタルバックアップを作成する
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 デベロッパーガイドの「サーバー側の暗号化を使用したデータの保護」を参照してください。
Amazon S3 バケットからの Amazon Aurora MySQL DB クラスターの復元
Amazon RDS コンソールを使用して、Amazon S3 バケットからバックアップファイルを復元して新しい Amazon Aurora MySQL DB クラスターを作成できます。
Amazon S3 バケットのファイルから Amazon Aurora MySQL DB クラスターを復元するには
AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/
) を開きます。 -
Amazon RDS コンソールの右上で、DB クラスターを作成する AWS リージョンを選択します。データベースバックアップを含む Amazon S3 バケットと同じ AWS リージョンを選択します。
-
ナビゲーションペインで、[データベース]、[S3 から復元] の順に選択します。
-
[S3 から復元する] を選択します。
[S3 から復元してデータベースを作成する] ページが表示されます。
-
S3 送信先で
-
バックアップファイルを含む S3 バケットを選択します。
-
(オプション) [S3 フォルダパスプレフィックス] で、Amazon S3 バケットに保存されているファイルのファイルパスのプレフィックスを入力します。
プレフィックスを指定しない場合、RDS は S3 バケットのルートフォルダにあるすべてのファイルとフォルダを使用して DB インスタンスを作成します。プレフィックスを指定すると、RDS はファイルのパスが指定されたプレフィックスで始まる S3 バケットのファイルとフォルダを使用して DB インスタンスを作成します。
例えば、複数のバックアップファイルのセットを S3 のサブフォルダ (backup) 内に保存し、各セットは独自のディレクトリ (gzip_backup1、gzip_backup2 など) 内にあるとします。この場合、プレフィックス backups/gzip_backup1 を指定して、gzip_backup1 フォルダのファイルから復元することができます。
-
-
[エンジンオプション]で
-
[エンジンのタイプ] で [ Amazon Aurora] を選択します。
-
[バージョン ] で、復元した DB インスタンスの Aurora MySQL エンジンのバージョンを選択します。
-
-
IAM ロールでは、既存の IAM ロールを選択します。
-
(オプション) [新しいロールを作成する]を選択して、新しい IAM ロールを持つこともできます。その場合、
-
IAM ロール名を入力します。
-
KMS キーへのアクセスを許可するかどうかを選択します。
-
バックアップファイルを暗号化していない場合には、[いいえ] を選択します。
-
Amazon S3 にバックアップファイルをアップロードした際に、このファイルを AES-256 (SSE-S3) で暗号化している場合には、[いいえ] を選択します。この設定により、データは自動的に復号化されます。
-
Amazon S3 にバックアップファイルをアップロードした際に、このファイルで AWS KMS (SSE-KMS) によるサーバー側の暗号化を実行した場合には、[はい] を選択します。次に、AWS KMS key の適切な KMS キーを選択します。
AWS Management Console は、Aurora によるデータの復号を許可する IAM ポリシーを作成します。
詳細については、Amazon S3 デベロッパーガイドの「サーバー側の暗号化を使用したデータの保護」を参照してください。
-
-
-
DB クラスターストレージ設定、DB インスタンスクラス、DB クラスター識別子やログイン認証情報など、DB クラスターの設定を選択します。各設定の詳細については、「Aurora DB クラスターの設定」を参照してください。
-
必要に応じて、Aurora MySQL DB クラスターの追加設定をカスタマイズします。
-
[データベースの作成] を選択して Aurora DB インスタンスを起動します。
Amazon RDS コンソールでは、新しい DB インスタンスが DB インスタンスのリストに表示されます。DB インスタンスが作成されて使用できるようになるまで、DB インスタンスのステータスは [作成中] となります。ステータスが [available] に変わったら、DB クラスターのプライマリインスタンスに接続できます。DB インスタンスクラスと割り当てられたストレージによっては、新しいインスタンスを使用できるようになるまで数分かかることがあります。
新しく作成したクラスターを表示するには、Amazon RDS コンソールで [データベース] ビューを選択し、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 DB クラスターを設定するには
-
暗号化レプリケーションのための準備があることを確認してください。
-
外部の MySQL プライマリデータベースで SSL が有効になっておらず、クライアントキーとクライアント証明書が準備されていない場合、MySQL データベースサーバーで SSL を有効にし、必要なクライアントキーとクライアントの証明書を生成します。
-
SSL が外部プライマリで有効になっている場合は、Aurora MySQL DB クラスターにクライアントキーおよび証明書を提供します。これらがない場合は、Aurora MySQL DB クラスター用に新しいキーと証明書を生成します。クライアント証明書に署名するには、外部の MySQL プライマリデータベースで SSL の設定に使用した認証局キーが必要です。
詳細については、MySQL ドキュメントの「openssl を使って SSL 証明書とキーを作成する
」を参照してください。 認証局証明書、クライアントキーおよびクライアント証明書が必要となります。
-
-
SSL を使用して、プライマリユーザーとして Aurora MySQL DB クラスターに接続します。
SSL で Aurora MySQL DB クラスターに接続する詳細については、「Aurora MySQL DB クラスターへの接続」を参照してください。
-
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 クラスターへの接続を参照してください。
注記
手順を実行したあと、シークレットはファイルに保存されます。ファイルを後で消去するには、mysql.rds_remove_binlog_ssl_material ストアドプロシージャを実行できます。
Amazon Aurora MySQL DB クラスターと外部の MySQL データベースを同期する
レプリケーションを使用して、Amazon Aurora MySQL DB クラスターと MySQL データベースを同期できます。
レプリケーションを使用して、Aurora MySQL DB クラスターと MySQL データベースを同期するには
-
外部の 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)
-
レプリケーションをスタートするバイナリログの位置を決定します。レプリケーションをスタートする位置は後のステップで指定します。
AWS Management Console の使用
AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/
) を開きます。 -
ナビゲーションペインの [Events] (イベント) を選択します。
-
[イベント] リストで、[Recovered from Binary log filename (バイナリログのファイル名から復旧済み)] イベントの位置をメモします。
AWS CLI の使用
describe-events AWS CLI コマンドを使用sるうことにより、binlog ファイルの名前と場所を取得することもできます。
describe-events
コマンドの例を以下に示します。PROMPT> aws rds describe-events
出力で、バイナリログの位置を示すイベントを特定します。
-
外部の 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 接続を要求します。例えば、以下のステートメントを使用して、ユーザーアカウント
に SSL 接続を要求できます。<user_name>
GRANT USAGE ON *.* TO '
<user_name>
'@'<domain_name>
' REQUIRE SSL;注記
REQUIRE SSL
が含まれていない場合には、レプリケーション接続がメッセージの表示なしで非暗号化接続に戻る場合があります。 -
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
<db_cluster_endpoint>
このホスト名は、Aurora MySQL DB クラスターのエンドポイントからの DNS 名です。
-
mysql.rds_reset_external_master (Aurora MySQL バージョン 2) または mysql.rds_reset_external_source (Aurora MySQL バージョン 3) ストアプロシージャを実行して、バイナリログレプリケーションを有効化します。このストアプロシージャの構文は次のとおりです。
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_reset_external_master (Aurora MySQL バージョン 2)」および「mysql.rds_reset_external_source (Aurora MySQL バージョン 3)」を参照してください。
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 認証局証明書、クライアント証明書およびクライアントキーもローカルディスクにダウンロードされます。
-
mysql.rds_start_replication ストアプロシージャを実行して、バイナリログレプリケーションをスタートします。
CALL mysql.rds_start_replication;
-
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 プライマリに追いついたことを示し、レプリケーションを停止するための次のステップに進むことができます。 -
MySQL レプリケーションのMySQL プライマリデータベースに接続して、レプリケーションを停止します。これを行うには、mysql.rds_stop_replication ストアドプロシージャを実行します。
CALL mysql.rds_stop_replication;