# 外部の MySQL データベースから Amazon Aurora MySQL DB クラスターへのデータ移行
<a name="AuroraMySQL.Migrating.ExtMySQL"></a>

データベースが 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 からの物理的な移行
<a name="AuroraMySQL.Migrating.ExtMySQL.S3"></a>

完全バックアップファイルと増分バックアップファイルをソース 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)

## 制約事項と考慮事項
<a name="AuroraMySQL.Migrating.ExtMySQL.S3.Limits"></a>

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)」を参照してください。

## 開始する前に
<a name="AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs"></a>

Amazon S3 バケットにデータをコピーし、それらのファイルから DB クラスターを復元するには、事前に以下の作業を行う必要があります。
+ Percona XtraBackup をローカルサーバーにインストールします。
+ お客様に代わって Aurora MySQL が Amazon S3 バケットにアクセスすることを許可します。

### Percona XtraBackup のインストール
<a name="AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs.XtraBackup"></a>

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 バージョンがソースデータベースのエンジンバージョンと互換性があることを確認してください。

### 必要なアクセス許可
<a name="AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs.Permitting"></a>

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 サービスロールの作成
<a name="AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs.CreateRole"></a>

[**新規ロールの作成**] オプション (このトピックで後述します) を選択して、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 クラスターとして復元するファイルのバックアップ
<a name="AuroraMySQL.Migrating.ExtMySQL.S3.Backup"></a>

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 での完全バックアップの作成
<a name="AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Full"></a>

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 のスタート方法](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html)」を参照してください。

### Percona XtraBackup での増分バックアップの使用
<a name="AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Incr"></a>

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)」を参照してください。

### バックアップに関する考慮事項
<a name="AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Considerations"></a>

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 クラスターの復元
<a name="AuroraMySQL.Migrating.ExtMySQL.S3.Restore"></a>

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 データベースを同期する
<a name="AuroraMySQL.Migrating.ExtMySQL.S3.RepSync"></a>

移行中のダウンタイムを減少あるいはなくすためには、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 クラスターを設定する
<a name="AuroraMySQL.Migrating.ExtMySQL.S3.RepSync.ConfigureEncryption"></a>

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

**注記**  
暗号化レプリケーションを使う必要がない場合、このステップをスキップして、「[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 データベースを同期する
<a name="AuroraMySQL.Migrating.ExtMySQL.S3.RepSync.Synchronizing"></a>

レプリケーションを使用して、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 '<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` が含まれていない場合には、レプリケーション接続がメッセージの表示なしで非暗号化接続に戻る場合があります。

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 <db_cluster_endpoint>
   ```

   このホスト名は、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 への物理的な移行にかかる時間の短縮
<a name="AuroraMySQL.Migrating.ExtMySQL.Prechecks"></a>

Amazon Aurora MySQL へのデータベース移行プロセスをスピードアップするために、以下のデータベース修正を行うことができます。

**重要**  
これらのアップデートは、本稼働データベースではなく、そのコピーに対して実行するようにしてください。このコピーをバックアップし、Aurora MySQL DB クラスターに復元することで、本稼働データベースのサービス停止を回避できます。

## サポートされていないテーブルタイプ
<a name="AuroraMySQL.Migrating.ExtMySQL.Prechecks.Tables"></a>

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

## サポートされていない権限を持つユーザーアカウント
<a name="AuroraMySQL.Migrating.ExtMySQL.Prechecks.Users"></a>

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 に対する動的権限
<a name="AuroraMySQL.Migrating.ExtMySQL.Prechecks.Dynamic"></a>

動的権限はインポートされません。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' を使用して保存されたオブジェクト
<a name="AuroraMySQL.Migrating.ExtMySQL.Prechecks.Objects"></a>

`'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 への論理的移行
<a name="AuroraMySQL.Migrating.ExtMySQL.mysqldump"></a>

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)