RDS for MySQL データベースを Amazon Aurora へ移行するためのベストプラクティス

MySQL は世界で最も普及しているオープンソースデータベースです。それにも関わらず、多くの利用者が一様にバックアップ、高可用性の確保にかかる膨大な手間に苦心していたり、また MySQL のスケーリングが複雑である、時間がかかる、あるいはその両方であると感じています。

お客様がそうした既存の MySQL 環境から Amazon RDS for MySQL へ移行する最大の理由の 1 つはそこにあります。Amazon RDS はポイントインタイムリカバリや高可用性などのオプションを複雑な設定など一切なしですぐに使用できる機能を提供します。RDS for MySQL はさらに、ソースあたり 5 つのリードレプリカに対応しています。このように、バイナリログ (binlog) レプリケーションを手動で設定したり、保守したりする必要なく、簡単にワークロードをスケールできます。

MySQL にハイエンドコマーシャルデータベースのパフォーマンスおよび可用性との互換性を期待するのであれば、MySQL データベースを Amazon Aurora に移行することでそれを実現できます。MySQL との互換性を持つ Amazon Aurora を使用することで、fast database clones および autoscaling replicas などの機能を活用できます。また、AWS Lambda および Amazon CloudWatch Logs といった他の AWS サービスとのネイティブ統合も可能になります。これらの機能に加えて、Amazon Aurora はまた、3 つのアベイラビリティーゾーンをまたぐデータのレプリケーションにより、優れた耐久性を実現します。また、最大で 15 個の Aurora レプリカにスケール可能で、すべてが通常では 20 ミリ秒未満のレイテンシーで実現されます。

このブログ記事では、Amazon RDS for MySQL から Amazon Aurora MySQL へ最小限のダウンタイムで移行する方法について掘り下げていきます。

移行に伴う考慮事項

どのような移行にもこれはつきものですが、考慮すべきことが多数あります。たとえば、ターゲット、移行するデータベースに依存するクライアントアプリケーション、移行中の可用性に関するビジネス要件などです。Amazon Aurora の MySQL エディションへ移行するときは、Aurora が MySQL 5.6 および MySQL 5.7 (あなたの選択次第) とワイヤー互換であることが重要です。これが意味することは、アプリケーションの視点からは MySQL 5.6 または 5.7、Aurora 5.6 または 5.7 との間に差異はありません。そのため、移行工程において、既存のアプリケーションコードを変更する必要はないはずです。

アプリケーション上のコードに変更は不要であっても、アプリケーションから新しいデータベースをポイントする方法が必要になります。もちろん、全アプリケーションの全接続文字列を変更することは可能ですが、もう 1 つの一般的なアプローチは、自分に代わって DNS にこれを実行させる方法です。このケースでは、接続文字列にデータベースインスタンスの実際のホスト名を使用しません。代わりに、データベースインスタンスのホスト名をポイントする正規名 (CNAME) レコードを作成するアプローチが考えられます。これを実行することで、複数の接続文字列設定を追跡して変更するのではなく、アプリケーションがポイントする 1 つのロケーションへのエンドポイントを変更できるようになります。

このパターンを使用する場合には、自分の CNAME レコードの 有効期限 (TTL) 設定を慎重に確認しましょう。この設定値が高すぎると、この CNAME によってポイントされるホスト名が求めるより長くキャッシュされる可能性があります。一方、この設定値が低すぎると、クライアントアプリケーションは、この CNAME を繰り返し解決しなくてはならなくなり、クライアントアプリケーションに余分なオーバーヘッドがのしかかる可能性があります。ユースケースごとに状況は異なるものの、TTL は最初 5 秒から始めるのが良いでしょう。

移行手順

既存の RDS for MySQL インスタンスを Amazon Aurora クラスターへ移行する最初のステップは、Amazon RDS マネジメントコンソールでインスタンスを選択することです。その後、インスタンスアクションで [Create Aurora read replica] (Aurora リードレプリカの作成) を選択します。

このオプションを選択する時点で、Aurora クラスターを定義するパラメータの数を指定する必要があります。Amazon Aurora クラスターにはソースインスタンスと同一のマスターユーザー名とマスターパスワードがあります。

移行の工程を始めると Amazon RDS が既存の RDS for MySQL インスタンスのスナップショットを作成し、スナップショットからのデータを新しく作成した Amazon Aurora クラスターへ復元します。ソースデータベースのサイズにもよりますが、この処理には数時間かかる可能性があります。

Amazon Aurora クラスターが作成され、初期セットのデータがロードされると、Amazon RDS は RDS for MySQL インスタンスから Amazon Aurora クラスターへの binlog レプリケーションを確立します。

binlog レプリケーションが確立され、レプリケーションが始まったら、Amazon Aurora クラスター上で CloudWatch メトリクス Aurora Binlog Replica Lag のモニタリングを開始することをお勧めします。

CloudWatch は binlog レプリカラグの俯瞰的なビューを提供しますが、新しく作成された Amazon Aurora クラスターにログインすることで、より詳細な測定値を見ることができます。そのためには、MySQL クライアントを使用して、コマンド show slave status\G を実行します。  このコマンドは非常に多くの有用な情報を返しますが、ここで私たちに必要な個別のメトリクスは Seconds_Behind_Master です。  このメトリクスが 0 になると、新しく作成した Amazon Aurora クラスターはオリジナルの RDS for MySQL インスタンスと同期されます。

新しい Amazon Aurora クラスターと、オリジナルの RDS for MySQL インスタンスとの同期が取れたら、RDS for MySQL インスタンスへの書き込みを停止するときです。ここからは、新しい Amazon Aurora クラスターへの書き込みを開始します。これを実行する方法は、次のようにいくつかあります。最初のオプションは、次に示したように、ソースインスタンスを単に停止するというものです。このアプローチはインスタンスをシャットダウンし、追加的な書き込みを回避します。

2 つ目のオプションはソースインスタンスを読み取り専用状態にするというものです。RDS for MySQL を使用してこれを実行する方法は、自分のインスタンスに割り当てられたパラメータグループを変更するというものです。read_only を設定すると、{TrueIfReplica} の値にデフォルト設定されます。  この場合、この値を明示的に 1 に設定し、インスタンスが読み取り専用であることを示します。このパラメータはダイナミックな適用タイプで、その設定が直ちに適用され、再起動は不要であることを意味します。

ここまでで、ソースの RDS for MySQL インスタンスは読み取り専用か、停止されている状態です。この時点で、Seconds_Behind_Master メトリクスをもう 1 度確認し、すべての binlog が適用されていることを確認します。

次に、Aurora のリードレプリカをライターにプロモートします。これを実行するには、ターゲットの Aurora クラスターを選択し、[インスタンスの操作] で [Promote read replica] (リードレプリカのプロモート) を選択します。これを選択してから処理が完了するまで数分かかります。この時点でアプリケーションの参照先となる CNAME をこの記事の最初に説明したとおりに変更します。

次の図に示すように、新しい Amazon Aurora のクラスターの [最新のイベント] を確認するとプロセスが完了したかを確かめることができます。

まとめ

本ブログ記事では、ライブの RDS for MySQL インスタンスをほぼダウンタイムなしで、新しい Amazon Aurora へ移行する方法について解説しました。今後のブログ記事では、自己ホスト型の MySQL データベースを Amazon EC2 から、またはオンプレミスのデータセンターから Amazon Aurora へ移行する方法について説明します。

今日、Amazon Aurora を使い始めるには、このコンソールをご使用ください。

RDS for MySQL および Aurora 間の移行についてさらに詳しい資料については、移行ドキュメントを参照してください。

著者について

Steve Abraham はアマゾン ウェブ サービスのプリンシパルソリューションアーキテクトです。 AWS の顧客と協力してデータベースプロジェクトに関する助言や技術支援を行い、AWS を使用する場面でソリューションの価値を向上させる手助けをしています。