AWS SCT と AWS DMS を使ってMySQLから Amazon Aurora に移行する方法

MySQLは素晴らしいオープンソースデータベースエンジンで、そのコスト効率から多くの企業で使われています。しかし、その他のオープンソースデータベースと同様に、ビジネスで使えるレベルの性能を出すには多くの労力が必要です。

データベースサイズが増えるとMySQLのスケーラビリティとクラッシュリカバリの複雑さも増します。レプリケーションスレーブを追加することでMySQLデータベースをスケールさせると、特にMySQLマスターで多くの書き込みが発生した場合に、レプリケーションラグを非常にに小さな値で維持することは困難を伴います。ほとんどの場合、安定したパフォーマンスを維持することは難しいです。

一方、Amazon Aurora では最大15個のリードレプリカを追加できます。また、書き込みノードで発生した変更を再実行するために必要な従来のバイナリログ (binlog) レプリケーションのパフォーマンスをAuroraでは気にする必要がなくなります。これはAuroraクラスターボリューム内のデータは、クラスター内のライターとリーダーに対して単一の論理ボリュームとして見えるためです。

多数のテーブルを含む大規模なデータベースでの高速リカバリも Amazon Aurora の重要な利点の一つです。従来のMySQLの実装では、データベースが大きくなるにつれてリカバリ時間が長くなります。MySQLはREDOログファイルを使用するため、クラッシュするとMySQLはテーブルの検出や検証オペレーションを大量に実行します。データベースの表領域が大きいほど、リカバリに必要な時間は長くなります。この影響は MySQL 5.7 でも当てはまります。

このような要因から、MySQLから Amazon Aurora への移行に関心が集まっています。この移行を実行するにはいくつかの方法がありますが、今回は Amazon RDS for MySQL またはオンプレミスや Amazon EC2 上のMySQLから Amazon Aurora with MySQL compatibility への同種間移行について考えます。

同種間移行の方法

AWSホワイトペーパーのサイトにある Amazon Aurora Migration Handbook で同種間移行のための推奨方法がリストされています。Amazon RDS for MySQL から移行するのであれば、RDSスナップショットでの移行方法を使用できます。この方法では、RDS MySQL のDBインスタンスのスナップショットから Aurora MySQL DB クラスターを作成します。これは非常に簡単です。Amazon Aurora へニアゼロダウンタイムで移行した場合は、ソースとなる RDS MySQL DBインスタンスからAuroraリードレプリカを作ることができます。RDSが Amazon Aurora へのリプリケーションを処理します。カットオーバーの準備ができたら、リードレプリカをバイナリログレプリケーションを使うプライマリの Amazon Aurora に昇格させるコマンドを実行します。

ソースのMySQLデータベースがEC2やオンプレミスサーバーにデプロイされている場合、Percona XtraBackup を使用して移行することを推奨します。この方法を使用すると、MySQLバックアップを Amazon S3 バケットにアップロードするパフォーマンスが向上します。この方法では、データベースのフルバックアップと増分バックアップを Amazon S3 に作成し、このS3上の増分ファイルはソースのMySQLとターゲット Amazon Aurora データベースの差分を縮めるのに役立ちます。もう一つの選択肢は、MySQLネイティブのエクスポートとインポートツールを使用することです。ネイティブツールを使うことで、あとでスキーマを手動で編集する必要がなくなる利点があります。しかし、移行のパフォーマンスを最適化する工数が非常に大きいです。3つ目の方法は既存のMySQLデータベースのリードレプリカとしてAuroraを設定することです。

場合によっては、推奨している方法を適用できないこともあります。たとえば、MySQL 5.7 から MySQL 5.6 互換のAuroraへ移行する場合、RDSスナップショットからのリストア、S3からのMySQLバックアップのリストア、MySQLのリードレプリカとしてのAuroraは、MySQLのバージョン間の互換性問題から実行できないかもしれません。また、ネイティブツールを使用したバルクロードを実行したあと、移行中のダウンタイムを減らすために、ソースのMySQLから追加で変更されたデータをキャプチャする必要があるかもしれません。

このブログ記事では、AWS Schema Conversion Tool (AWS SCT) と AWS Database Migration Service (AWS DMS) を使用した Amazon Aurora へのもう一つの移行パスを紹介します。バージョンが違うことでネイティブのバイナリログレプリケーションができないときや、追加のデータ変換要件があるときにこの方法が使えます。

AWS SCT によるスキーマ移行

ソースの MySQL InnoDB データベースから Amazon Aurora への同種間移行のために AWS SCT を使用できます。このツールを使用することで、MySQLからスキーマやビュー、ストアドプロシージャ、ファンクションをエクスポートすることができます。ただし、互換性のあるバージョン間での移行の場合、ネイティブツールを使用してMySQLのデータベースオブジェクト定義をエクスポートすることを推奨します。これにはmysqldumpや MySQL Workbench の Data Export and Import Wizard を含みます。

AWS SCT の使用を開始するには、新しいプロジェクトを作成します。Source Database Engine をMySQLに、Target Database Engine を Amazon RDS for MySQL に設定します。なぜなら Amazon Aurora for MySQL はMySQLと互換性があるためです。

その後、ソースデータベースとターゲットデータベースへの接続パラメータを指定します。

ソースデータベースからデータベースオブジェクト定義をエクスポートするには、エクスポートするスキーマ上で右クリックし、Convert Schema を選びます。

変換が完了したら、AWS SCT 内のターゲットデータベースセクションに移り、データベースオブジェクト定義を含む.sqlファイルを保存します。

AWS SCT .sql ファイルにいくつかの編集を加える必要があるかもしれません。
この後で AWS DMS を使用するために編集が必要な場合があります。DMSはフルデータロード処理の一部としてテーブルとプライマリキーを作成します。DMSはデータを効率的に移行するために、最低限必要なオブジェクトのみを作成します。このDMSの機能があるため、ターゲットスキーマオブジェクトを手動で作成するのではなく、上記の方法をとっています。

DMSがターゲットデータベースにテーブルを作成しているので、SCT .sql ファイルから次のセクションを削除します。

-- ------------ Write DROP-TABLE-stage scripts -----------
-- ------------ Write CREATE-DATABASE-stage scripts -----------

SCTはソースデータベースから既存のユーザーアカウントをエクスポートしません。ユーザーアカウント情報を手動でエクスポートし、対象の Amazon Aurora データベースでユーザーを再作成する必要があるかもしれません。または、AWS Identify and Access Management (IAM) ベースのユーザーまたはロール認証を使って、Amazon Aurora データベースインスタンスの認証をすることもできます。

DMSによるデータ移行

AWS DMS を使用してデータを移行することができます。AWS DMS は1回限りのデータ移行を行うことも、データを継続的にレプリケーションすることもできます。MySQLから Amazon Aurora への移行では、まずはバルクロードを行い、それからレプリケーションまたは Change Data Capture (CDC) を実行します。変更をレプリケーションするために、DMSはソースデータベースのバイナリログファイルを読む必要があるため、、ソースのMySQLデータベースのバイナリログが有効になっているという前提条件を満たしているかを確認する必要があります。

オンプレミスやEC2インスタンス上のMySQLソースの場合、次のパラメータをMySQL構成ファイル（my.iniまたはmy.cnf）で編集し、MySQLプロセスを再起動します。

log-bin=mysql-bin
binlog_format=row
binlog_checksum=none

RDS for MySQL の場合は、RDSインスタンスにひも付いているパラメータグループで前述のパラメータを設定します。

バイナリログが有効になっていることを確認するには、ソースのMySQLにログインし、MySQLクライアントで show binary logs コマンドを実行します。

DSMで移行プロセスを開始するには、まずソースとターゲットのエンドポイントを作成します。今回のソースエンドポイントは Amazon EC2 上の MySQL 5.7 であり、ターゲットエンドポイントは Amazon Aurora です。

エンドポイントの作成後、DMSタスクを作成します。タスク名およびレプリケーションインスタンス、ソースとターゲットエンドポイントを指定します。

移行タイプには「既存データを移行して、継続的な変更をレプリケートする」を選択します。このオプションはDMSが既存のデータのバルクロードを実行してから、その後にCDCを実行します。

また、「タスク設定」セクションで「キャッシュされた変更の適用前に停止」を選択します。前述の AWS SCT .sql ファイルからターゲットAuroraデータベースにセカンダリインデックスなどのデータベースオブジェクトを作成するために、このオプションを指定します。

タスク情報を設定した後、DMSはタスクを開始します。デフォルトではDMSは一度に8つのテーブルを読み込みます。バルクロードが完了すると、タスクのステータスが「停止」に変わります。

必要に応じてイベント通知によるタスクのステータス監視をすることができます。その場合、バルクロードが完了次第、通知されます。次に、編集した.sqlスクリプトを AWS SCT からターゲットデータベースに適用して、セカンダリデータベースオブジェクトを作成します。

セカンダリデータベースオブジェクトをターゲットのAuroraデータベースに適用した後、タスクを再開することができます。今回は継続的レプリケーションを実行します。

ソースデータベースの変更がキャプチャされることをテストするために、今回は3,534行をソースのMySQLのticket_purchase_histテーブルに追加します。また、テーブル間に制約が作成されることを確認するため、ticket_purchase_histテーブルと依存関係があるsporting_event_ticketテーブルを更新します。これらの変更がレプリケーションされているかどうかを確認するには、DMSタスクの「テーブル統計」タブを確認します。

バルクロードとCDCを実行した後、データベース比較ツールを使用してソースデータベースとターゲットデータベースが同期していることを検証できます。そのようなツールの一つは MySQL Workbench の Schema Synchronization and Comparison ユーティリティです。

まとめます。AWS DMS を使用することにより、バージョンの互換性問題を克服し、MySQL 5.7 から 5.6互換の Amazon Aurora への移行を実現することができます。AWS DMS レプリケーションは、移行中のダウンタイムを削減することができ、これはミッションクリティカルなアプリケーションをサポートするデータベースにとって重要なことです。Amazon Aurora では、高可用性とスケーラビリティを備えたMySQL互換データベースクラスターのメリットを享受できます。

（訳注: ブログの原文公開後に MySQL 5.7 互換の Amazon Aurora がリリースされました。これにより、RDSスナップショットからのリストア、またはソースのMySQLからネイティブなバイナリログレプリケーションすることで、MySQL 5.7 ソースから Amazon Aurora に移行することが可能になりました）

著者について

Marie Yap は Amazon Web Services のエンタープライズソリューションアーキテクトです。Marieはエンタープライズ顧客向けのアプリケーションやデータベースのパフォーマンスチューニングを中心としたテクニカルコンサルティングの経験を持っています。

Hemant Borole は Amazon Web Services の Big Data コンサルタントです。Hemantはデータベースプロジェクトのガイダンスや技術支援を提供をお客様と共に行っており、AWSを使用するときのソリューションの価値向上を手助けしています。

翻訳はソリューションアーキテクトの柴田（シバタツ）が行いました。原文は How to Migrate from MySQL to Amazon Aurora using AWS SCT and AWS DMS。