MENU
データベース＆クラウド技術情報
  1. ホーム
  2. 技術情報
  3. AWS
  4. MySQLからAmazon Auroraへの移行(Xtrabackup)

MySQLからAmazon Auroraへの移行(Xtrabackup)

AWS

MySQLからXtrabackup(Percona XtraBackup)を利用し、Amazon Auroraへの移行

サービスが利用できるようになってから時間が経っていますが、最近まとめてみたので公開します。
公式ページはここです。

目次

簡単な概要説明

  • 移行元DBの対象はオンプレミスや仮想サーバ、EC2上で稼働するMySQL5.5またはMySQL5.6(*1)
  • XtraBackupを利用します。
    • XtraBackupとはPercona社が提供するMySQL用のバックアップツール(ホットバックアップ)
    • MySQL以外にもPercona ServerやMariaDB,さらにはGalera Clusterもサポート
    • Install方法はこちらから
  • Amazon S3にバックアップファイルをコピーし、そこからAurora Clusterの復元を行います。
  • RDSからS3を利用するためのIAM Roleが必要です。
  • 差分を適用する場合はバイナリログをonにしておく必要があります。

*1 マイナーバージョンについてはおまけに記載してます。

移行手順

環境

移行元DB :

  • CentOS7.3
  • MySQL Community Server 5.5.54
  • Backup用Directory /s3-restore/backup
  • DataSize 8Gくらい(tpcc-mysqlで作成)
  • S3 Bucket : /db-migrate/xtrabackup/

1.Xtrabackup Install

[sh]
sudo yum -y install epel-release
sudo yum -y install http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm
sudo yum list | grep percona
sudo yum -y install percona-xtrabackup-24
[/sh]

2.Backup

mysqldが起動している状況で下記コマンドを実行します。
[sh]
innobackupex –user="アカウント" –password="パスワード" –no-timestamp /s3-restore/backup
[/sh]
–no-timestampがないとタイムスタンプ名でフォルダが新規に作成されます。
またサイズが大きい場合は公式ページにあるように–streamオプション及びsplitで圧縮・分割するとよさそうです。
今回は分割なしで実施してます。
差分を取得する場合はバイナリログを有効にしておきます。

3.S3へコピー

AWS CLIを利用します。
[sh]
aws s3 sync /s3-restore/backup s3://db-migrate/xtrabackup
[/sh]
AWS CLIはデフォルトでSSLを使用公式ページより

4.IAM Role作成

手順は公式通りに実施します 。
policyは下記です。
[sh]
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::db-migrate"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::db-migrate/xtrabackup/*"
]
}
]
}
[/sh]

5.Aurora Cluster作成

AWSマネージメントコンソールからRDSを選択しダッシュボードから[S3からAuroraDBクラスター復元]を選びます。

ソースバックアップの詳細の指定をします。

[DB 詳細の指定]をして[DBインスタンスの作成]を実施します。

1分程度待つとインスタンスの[DBクラスターの詳細]に進捗状況が表示されます。
ただ検証時に実施した限りではless than 1%から動きませんでした。

6.差分更新

xtrabackupで出力したファイルの中にあるxtrabackup_infoにbinlog_posが出力されます。

AuroraではCHANGE MASTER TO 構文が使えないため、procedureで設定します。
[sh]
CALL mysql.rds_set_external_master (‘マスターのIP’, port,’アカウント’, ‘パスワード’, ‘binファイル名’, ポジション, 0);
[/sh]
最後の0はssl_encryptionだが現在未実装とのこと。デフォルトの0で実行します。

レプリケーションを開始します。
[sh]
CALL mysql.rds_start_replication;
[/sh]

時間

検証時では各作業の時間はおおよそ下記のようになりました。

  • バックアップ取得 5分
  • S3へのアップロード 8分
  • Aurora Clusterの復元 40分

と合計で１時間弱でした。
もちろん環境によって差分は出ると思うのであくまで参考程度です。

EC2で同程度のインスタンス(t2.medium)にmysql5.6.35を入れてリストアしたところ
約2分程度で完了しました。速度的な恩恵はオンプレミス程はなさそうです。

おまけ

以前、検証時にバージョン5.6.34で実施した際、ソースエンジンのバージョンについて下記のエラーが出ました。

ただ、ソースエンジンのバージョン入力時に5.6.10と入力すると中身のデータが5.6.34でも移行は出来ました。
移行後のデータについても移行元のデータとの差分はなかったので、そのまま使えそうな気はするが移行後のデータは確認が必要ですね。

おまけ2

公式ページではユーザーアカウントは移行対象外となっているが検証した限りアカウントの移行も行われており、利用も出来ました。

使ってみた感想

Xtrabackupを利用する目的としてリストアまでの速度が魅力というイメージがあったのですが、S3から復元するとどうしても時間がかかってしまいます。
ただ検証データをmysqldumpを利用してオンプレミス環境からAuroraにリストアした際には、バックアップ取得で6分、リストアで73分程度かかったのでmysqldumpよりは速度面でのメリットはありそうです。

VPNやAWS Direct Connectが利用できずAWS Database Migration Serviceが利用出来ない場合などにはより利用価値がありそうですね。

AWS
よかったらシェアしてね！
  • URLをコピーしました！

関連記事

目次