Amazon Aurora はリレーショナルデータベースエンジンです。既存の RDS よりコスト効率よく設定、操作、スケーリングできるそうですので、既存の RDS MySQL DB インスタンスを、Amazon Aurora MySQL DB クラスターに移行してみます。
Contents
Amazon Aurora
MySQL や PostgreSQL と互換性があり、RDS で Aurora を管理します。
管理
- データベースのプロビジョニング
- パッチ適用
- バックアップ
- 復旧
- 障害検出
- 修復などのルーチンタスク
移行
既存の RDS を Aurora に移行できます。
下記の RDS には Aurora への移行ツールもあるようです。
- Amazon RDS for MySQL
- Amazon RDS for PostgreSQL
料金
- 1 USD/日以下から
特徴
- スループット（MySQL：最大 5 倍、PostgreSQL：最大 3倍）
- Auto Scaling SSD ストレージ（最大 64 TB）
- レプリケーションを3 つのアベイラビリティーゾーン間で行える（6 通りまでの方式）
- 15 個までのリードレプリカ (レプリカラグは 10 ms 未満)
- 自動モニタリングとフェイルオーバー（30 秒未満）
設定項目
設定
- DB インスタンス識別子の入力
- マスターユーザの名前の入力
- マスターパスワードの入力
ネットワーク & セキュリティ
- Virtual Private Cloud の設定
- サブネットグループの設定
- パブリックアクセシビリティの設定
- アベイラビリティーゾーンの設定
- VPC セキュリティグループの設定
データベースの設定
- DB クラスター識別子
- データベースの名前
- データベースのポート
- DB パラメータグループ
- DB クラスターのパラメータグループ
- オプショングループ
暗号化
- 暗号化
- マスターキー
フェイルオーバー
- 優先度
バックアップ
- バックアップの保存期間
モニタリング
- 拡張モニタリング
- モニタリングロール
メンテナンス
- マイナーバージョン自動アップグレード
- メンテナンスウィンドウ
移行する
移行には２タイプあります。
- 物理移行（データベースファイルの物理コピー）
- 論理移行（挿入、更新、削除などの論理的な変更を適用）
物理移行の方が高速でパフォーマンスを低下しないようですが、制限があります。
論理移行は低速ですが、物理ストレージ構造には影響されないものの、複雑なデータベースコンポーネントではブロックされるなどのも問題もあるようです。
いくつか移行方法はあるようですが、今回は、物理移行でリードレプリカを使った方法を試してみます。
- 既存のRDS for MySQL から Aurora MySQL リードレプリカを作成
- Aurora リードレプリカから読み取り停止
- Aurora リードレプリカのレプリケーションを停止
- Aurora MySQL リードレプリカを読み取りと書き込み用のスタンドアロンにする（インスタンスの操作からリードレプリカの昇格）
- Aurora MySQL からリードレプリカを作成
- アプリケーション側での接続エンドポイントの変更（セキュリティグループが適切か確認しておくこと）
- RDS for MySQL を停止、削除
方法は複数ありますので、要件に適した方法を選択して実行することが可能です。
さらに Amazon Aurora Serverless では
- 自動的に起動
- シャットダウン
- スケールアップ
- スケールダウン
が可能で、現在はプレビューが行われているようです。