Amazon-Aurora

Aurora (MySQL)使ってみた。

Amazon Aurora, aws, rds コメントを残す

全般

概念は理解していても深くまで理解できていないので、構築をしながら理解する回です。

全般の参考:
AWS公式サイト

次のリンクはRDSとの違いを知りたい時の参考になります。（公式のQA）:
Amazon Aurora のよくある質問

  • ”構築前”のイメージ
    RDSより高性能で、フェールオーバーが早い！
    ストレージとインスタンスが別。
    高い。。

  • 調べてみた結果
    プライマリ (ライター) DB インスタンス
    ⇒読み書きを行う。
    Aurora レプリカ (リーダー DB インスタンス)
    ⇒読み込みを行う。
    ※（ローカル）書き込み転送という機能があり、リーダーDBで書込み操作を行うと転送できる。
    Amazon Aurora MySQL DB クラスターでのローカル書き込み転送の使用

    • Aurora Global Databaseはクロスリージョンレプリカを容易に作成できる。（グローバル）書込み転送が可能。

    • バックトラック機能を使用できる。つまり巻き戻し（上限は 72 時間）
      Aurora DB クラスターのバックトラック

    • 強制的に自動バックアップが設定され、3つのストレージが作成される。

    • 料金は、RDSをマルチAZで使うよりも、タイプ次第ではAuroraの方が安くなる。

構築

  • EC2（Amazon Linux 2023）をパブリックサブネットに配置済みとします。
    ※既にこの環境は削除済です。
  • セキュリティグループは、EC2用とAurora用で作成しておきます。

Auroraは、RDSのコンソールから起動します。まずこれ。

サブネットグループで3つのサブネットを対象に作成しておく。

  • エンジンバージョン
    "Aurora MySQL 3.05.2 (compatible with MySQL 8.0.32) - メジャーバージョンのデフォルト 8.0"
    コミュニティデータベースと Aurora 間でのバージョン番号の違いがあります。Auroraとコミュニティデータベース、2つのバージョンが存在するということ。
    細部はドキュメントを確認しましょう。
    Amazon Aurora バージョン

image.png

項目 設定値 / 説明
テンプレート 開発/テスト（今回はこちらを選択）
DB クラスター識別子 auroradb-test（任意）
マスターユーザー名 任意
パスワード 任意
クラスターストレージ設定 Aurora スタンダード（今回はこちらを選択）
インスタンスクラス db.t3.medium
接続オプション EC2 コンピューティングリソースに接続しない
ネットワークタイプ IPv4
VPC 作成した VPC を選択
セキュリティグループ 事前に作成したものを適用
デフォルトは削除
アベイラビリティゾーン ap-northeast-1c
拡張モニタリング 使用しない
最初のデータベース名 test
フェイルオーバー優先順位 高（tier-0）→ 低（tier-15）

～Amazon Aurora のよくある質問より～

クラスターの各インスタンスに昇格優先階層を割り当てることができます。プライマリインスタンスが失敗した場合、Amazon RDS は最も高い優先度のレプリカをプライマリに昇格します。複数の Aurora レプリカで同じ優先度を共有する場合、Amazon RDS は最大サイズのレプリカを昇格します。複数の Aurora レプリカで同じ優先度とサイズを共有する場合、Amazon RDS は同じ昇格階層の任意のレプリカを昇格します。

image.png

image.png

シングルで作成が完了しました。
次にEC2からログインしてみましょう。
まずリポジトリのインストールから始めます。

sudo dnf -y install https://dev.mysql.com/get/mysql84-community-release-el9-1.noarch.rpm

MySQLクライアントと共通ツールのインストール

sudo dnf -y install mysql mysql-community-client

MySQLサーバーのインストール

sudo dnf -y install mysql-community-server

MySQLサーバーを起動

sudo systemctl start mysqld

MySQLサーバーの状態を確認

sudo systemctl status mysqld

起動時の自動起動を設定

sudo systemctl enable mysqld

初期パスワードを確認

sudo grep 'temporary password' /var/log/mysqld.log(初期パスワードが画面に表示されます。)

MySQL(EC2)にログイン

mysql -u root -p（ここで表示された初期パスワードを入力）

接続の確認ができたらログアウトします。
続いて、Auroraに接続します。

mysql -h {エンドポイント} -u admin -p

接続ができたらAuroraの基本的な構築方法や、基礎理解が修了したものと思い込むことにします(;^ω^)

データ移行の準備

現状の整理例

EC2(MySQL):

  • アカウント
    • root
      • BACKUP権限を付加必須
  • test(データベース)
    • test-table(テーブル)

Aurora(MySQL)

  • アカウント
    • admin
  • test(データベースのみ作成)

EC2(MySQL)構築開始

ALTER USER 'root'@'localhost' identified BY '(新しいパスワード)';

既存データと、移行先データベースのDB名は同じ名前にしています。
現状のデータベースを確認

show databases;

データベースを作成

CREATE DATABASE test;

データベースが作成されたか確認

show databases;

testデータベースを使用

USE test;

任意のカラム作成

CREATE TABLE `test-table` (
    test1 INT,
    test2 VARCHAR(50)
);

データを挿入します。

INSERT INTO `test-table` (test1, test2) VALUES (1, 'Value1');
INSERT INTO `test-table` (test1, test2) VALUES (2, 'Value2');

データが挿入されたか確認

SELECT * FROM `test-table`;

出力例

mysql> SELECT * FROM `test-table`;
+-------+--------+
| test1 | test2  |
+-------+--------+
|     1 | Value1 |
|     2 | Value2 |
+-------+--------+
2 rows in set (0.00 sec)

権限確認

SHOW GRANTS FOR 'root'@'%';

出力例

mysql> SHOW GRANTS FOR 'root'@'%';
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for root@%                                                                                                                                                                                                                                                                                                                                                                                |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, SHUTDOWN, PROCESS, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER, CREATE TABLESPACE, CREATE ROLE, DROP ROLE ON *.* TO `root`@`%` WITH GRANT OPTION |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

BACKUPが存在しないことがわかります。
BACKUPを追加します。

GRANT BACKUP_ADMIN ON *.* TO 'root'@'%';

次にDMSからの接続（つまりリモート接続）を許可します。
※限定的に接続させる場合は「%」の箇所をプライベートIPアドレスに置き換えましょう。

UPDATE mysql.user SET Host = '%' WHERE User = 'root' AND Host = 'localhost';

変更を反映

FLUSH PRIVILEGES;

次にやっとAurora
EC2から接続します。

mysql -h {エンドポイント} -u admin -p

Aurora構築時に設定した初期データベース(EC2上に構築したDBと同じtestデータベース）があるか確認

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| test               |
+--------------------+
5 rows in set (0.01 sec)

データ移行

「データ移行」タブに移動
image.png
image.png
image.png
image.png

フルロード（ソースデータベースからターゲットデータベースへの 1 回限りの移行を実行します。ダウンタイムを最小限に抑えることが重要でない場合は、このオプションを選択します。）として進めます。
ロールはその場で作成可能。ソース用、ターゲット用、データ移行用が必要。
このロールを実行するには、次のロールを作成する。これはコンソールに案内があります。
ご参考までに記載します:
Amazon VPC を管理するための AWS DMS の IAM ロールの作成

ロールの作成:
ポリシー:
AmazonDMSVPCManagementRole

ロール名:
dms-vpc-role

注意書きを確認して実行します。内容は、同じ名前の既存のデータベースが上書きされることに対して同意を求めるものです。
image.png

ポップアップの案内に従い進捗を確認
移行完了です。
image.png
ログでも確認してみます。
image.png
今更感ありますが、裏ではAWS DMSが機能し、移行前に自動的にバックアップを作成、問題なく移行できたらバックアップを削除してくれています。あっという間の出来事でした。

CloudWatchでEngineUptimeを見てみます。
image.png

RDS（Aurora）イベントでダウンタイムを同時にみる。
image.png

マルチAZ化するなかでダウンタイムが発生するか確認してみる。
「リーダーの追加」からマルチAZ化を行います。
image.png
image.png
マスターとは違うAZに配置します。
image.png
image.png
デフォルトで検証します。
image.png
当たり前だろと言われたらそれまでですが、リーダーを追加したことで、クラスター自体及びライターインスタンスに瞬断なく、迅速にリーダーを追加できたことがわかります（クリックした時間から計測すると約4分）。
image.png

マルチ化前のプルダウンの状態
RDSと違って自動バックアップが強制なだけあってクロスリージョンレプリケーションが既に選択可能となっていますね。その他にもクローンの作成などといった、あったらいいな機能が豊富に存在することがわかります。
image.png

マルチ化後のリーダーインスタンスのプルダウン
image.png
image.png

イベントログを確認すると、1分未満でフェールオーバーが完了しました。目測で40-50秒ほどでは完了していてびっくりするばかりです。この間に瞬断が発生している可能性がありますね。
image.png

EngineUptimeでも目測とほぼ同じ感じですね。1分未満。
image.png

image.png

image.png

書込み転送について気になっていたのでコンソールで見てみると、リーダーDBインスタンスでいつでも設定できるようです。
image.png

感想

最後まで読んでいただきありがとうございます！
冒頭に記載したとおり勝手なイメージが出来上がっていましたが、DR（Disaster Recovery）に向いている点、インスタンスサイズ（マルチAZ時）によっては料金パフォーマンスが高いという点、に特に驚かされました。大変勉強になりました！
では！

返信を残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

CAPTCHA