※データベースに特化したインスタンスを作成できる ※最初に文字コードや時差を指定したパラメータグループを作成しておくと、スムーズに構築できそう（後述） ■パラメータグループの作成 作成したいRDSのバージョンに合わせてパラメータグループを作成し、以下の設定を変更しておく 設定については、後述の「データベースの文字コードをUTF8MB4にする」「時差対策」「スロークエリ出力」を参照 character_set_client: utf8mb4 character_set_connection: utf8mb4 character_set_database: utf8mb4 character_set_results: utf8mb4 character_set_server: utf8mb4 init_connect: SET SESSION time_zone = CASE WHEN POSITION('rdsadmin@' IN CURRENT_USER()) = 1 THEN 'UTC' ELSE 'Asia/Tokyo' END; slow_query_log: 1 long_query_time: 1 ■RDSの作成 「Relational Database Service → 今すぐ始める」もしくは「Relational Database Service → DBインスタンスの起動」からインスタンスを作成 データベース作成方法を選択: 標準作成 エンジンのオプション: MariaDB バージョン: MariaDB 10.6.12 テンプレート: 開発/テスト DBインスタンス識別子: refirio-develop（大文字で入力しても小文字で保存される） マスターユーザー名: rdsmaster マスターパスワード: XXXXXXXXXXXX DBインスタンスクラス: バースト可能クラス（t クラスを含む） db.t3.micro ストレージタイプ: 汎用（SSD） ストレージ割り当て: 20GiB ストレージの自動スケーリングを有効にする: チェックを外す マルチAZ配置: スタンバイインスタンスを作成しないでください コンピューティングリソース: EC2コンピューティングリソースに接続しない ネットワークタイプ: IPv4 Virtual Private Cloud: （あらかじめ作成したものを選択） DBサブネットグループ: （あらかじめ作成したものを選択） パブリックアクセス: なし VPCセキュリティグループ (ファイアウォール): （「default」と、データベース用に作成したセキュリティグループを割り当てる） アベイラビリティーゾーン: 指定なし 最初のデータベース名: （作成したいデータベース名を入力） DBパラメータグループ: （上で作成したものを選択） オプショングループ: default:mariadb-10-6 ※「ストレージタイプ」は、マルチAZを使う場合はデフォルトが「プロビジョニングIOPS（SSD）」になる？ 「汎用（SSD）」に比べて非常に高額なので注意 ※マルチAZ配置の時に、アベイラビリティゾーンを指定するとインスタンス作成時にエラーになった インスタンスが作成されるまで数分待つ 必要に応じて、WebサーバからMySQLにアクセスするための設定を行っておく # yum -y install php-mysql # service httpd restart RDSのエンドポイントが以下の場合、 develop.xxxxx.rds.amazonaws.com:3306 例えばWebサーバからSSHで以下のようにすればRDSへ接続できる mysql -h develop.xxxxx.rds.amazonaws.com -u webmaster -p MySQL データベースエンジンを実行している DB インスタンスに接続する http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html RDSに接続できません https://forums.aws.amazon.com/thread.jspa?threadID=115768 ■EC2との紐づけ 2022年の終わりごろから、RDSインスタンス作成時に既存EC2との紐付けができるようになっている RDSインスタンス作成時にEC2に接続設定するオプション | ヤマムギ https://www.yamamanx.com/rds-ec2-autocon/ Amazon RDSインスタンス作成時に既存EC2との紐付けができるようになっていた - Qiita https://qiita.com/wol/items/8add252515b4c70f5261 RDS作成時に「コンピューティングリソース」で「EC2コンピューティングリソースに接続」を選択し、一例だが以下のように設定する ただしこれまでどおり「EC2コンピューティングリソースに接続しない」として、自身で作成したセキュリティグループ単位で設定する…でいい気はする EC2インスタンス: （接続を許可したいEC2インスタンス。このEC2に自動作成されたセキュリティグループが追加されるらしい） Virtual Private Cloud: （選択済みで変更できなくなっていた） DBサブネットグループ: 既存の選択 既存のDBサブネットグループ: （あらかじめ作成したものを選択） パブリックアクセス: なし VPCセキュリティグループ (ファイアウォール): default ※「Amazon RDS は、コンピューティングリソースとの接続を許可 する新しい VPC セキュリティグループ rds-ec2-1 を追加します。」と表示されている ■データベースの文字コードをUTF8にする ※文字コードを何も設定しないと、日本語が文字化けしてしまう ※今新規に設定するなら、絵文字なども扱えるUTF8MB4にしておく方が良さそう（後述） 「RDS」→「パラメータグループ」→「パラメータグループの作成」 新しく「refirio-develop」のような名前でパラメータグループを作成し、「character_set_database」と「character_set_server」を「utf8」に設定する 今ならutf8mb4も検討する（後述） 作成したパラメータグループをもとにRDSインスタンスを作成する （RDSインスタンス作成後にパラメータグループを設定しても、既存のデータベースの文字コードには影響しない 必要に応じてデータベースの文字コードを変更するか、データベースを作り直すかをする） 新規にテーブルを作成するときは、以下のように「DEFAULT CHARSET=utf8」を指定する CREATE TABLE IF NOT EXISTS users( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '代理キー', created DATETIME NOT NULL COMMENT '作成日時', modified DATETIME NOT NULL COMMENT '更新日時', username VARCHAR(80) NOT NULL UNIQUE COMMENT 'ユーザ名', password VARCHAR(80) COMMENT 'パスワード', PRIMARY KEY(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT 'ユーザ'; Amazon RDS の MySQL で UTF-8 のデータベースを作る http://dotnsf.blog.jp/archives/2211314.html RDSで日本語が文字化けする問題 http://qiita.com/reoy/items/e355debf1e2b2abd703b ■データベースの文字コードをUTF8MB4にする ※UTF8では4バイト文字が文字化けするので、絵文字などを扱いたければUTF8MB4にしておく パラメータグループを「character_set_」で絞り込むと、文字コードに関する値が表示される 以下のを値をすべて「utf8mb4」に変更する character_set_client character_set_connection character_set_database character_set_results character_set_server character_set_filesystem は変更しなくていいみたい 以降、MySQLと同様に「CHARSET=utf8mb4」を指定してテーブルを作成すればいい RDS MySQL5.5.33 で『utf8mb4』(4バイト対応UTF-8文字コードセット)を試してみた http://dev.classmethod.jp/cloud/aws/utf8mb4-on-rds-mysql/ MySQLの文字コードをutf8mb4に変更 http://qiita.com/deco/items/bfa125ae45c16811536a ■時差対策 「RDS」→「パラメータグループ」→ 作成したパラメータグループを選択 →「パラメータの編集」で、 「init_connect」の値に以下を設定する SET SESSION time_zone = CASE WHEN POSITION('rdsadmin@' IN CURRENT_USER()) = 1 THEN 'UTC' ELSE 'Asia/Tokyo' END; 「time_zone」を「Asia/Tokyo」に設定しているが、「rdsadmin」というユーザで接続してきた場合のみ除外する AmazonがRDSを管理するためにrdsadminというユーザを用意しているが、 このユーザが接続した時にタイムゾーンがUTC以外だと不都合が起こるらしい Amazon Auroraでタイムゾーンを設定する http://dev.classmethod.jp/cloud/aws/aurora-set-timezone/ AWS RDSのタイムゾーンについて http://techfun.cc/aws/aws-rds-timezone.html ■スロークエリ出力 RDSでslow queryを出力させる方法 http://rfs.jp/server/aws/aws-rds_slow-query.html RDSでslow queryを出力する http://digape.com/201206/aws-rds%E3%81%A7slow-query%E3%82%92%E5%87%BA%E5%8A%9B%E3%81%99%E3%82%8B/ パラメータグループで指定できる long_query_time を 0 にするとすべてのクエリが記録されるので、いったん 0 にして記録されることを確認する 最初は 0.1 くらいにして様子を見つつ、記録されるクエリが多いなら値を大きくして…と調整する long_query_time はRDSを再起動しなくても、値を設定してから数秒後に反映された （「適用タイプ」が「dynamic」の値は、すぐに反映されるみたい） mysql> SHOW GLOBAL VARIABLES LIKE 'slow_query_log'; … スロークエリのONを確認 +----------------+-------+ | Variable_name | Value | +----------------+-------+ | slow_query_log | ON | +----------------+-------+ 1 row in set (0.00 sec) mysql> SHOW GLOBAL VARIABLES LIKE 'long_query_time'; … スロークエリの記録時間を確認 +-----------------+----------+ | Variable_name | Value | +-----------------+----------+ | long_query_time | 0.100000 | +-----------------+----------+ 1 row in set (0.00 sec) パラメータグループで log_output を FILE にしておくと、AWS管理画面からスロークエリのファイルをダウンロードできる （RDS → インスタンス → インスタンスを選択 → ログ → slowquery/mysql-slowquery.log → ダウンロード） パラメータグループで log_output を TABLE にしておくと、SQLで確認できる mysql> SELECT * FROM mysql.slow_log; … スロークエリを確認 +---------------------+-----------------------------------+------------+-----------+-----------+---------------+------+----------------+-----------+-----------+---------------------------------+-----------+ | start_time | user_host | query_time | lock_time | rows_sent | rows_examined | db | last_insert_id | insert_id | server_id | sql_text | thread_id | +---------------------+-----------------------------------+------------+-----------+-----------+---------------+------+----------------+-----------+-----------+---------------------------------+-----------+ | 2016-11-16 11:11:31 | testuser[testuser] @ [10.0.0.23] | 00:00:00 | 00:00:00 | 341 | 341 | | 0 | 0 | 598711836 | SHOW STATUS | 7225454 | | 2016-11-16 11:11:46 | webuser[webuser] @ [10.0.1.103] | 00:00:00 | 00:00:00 | 100 | 100 | test | 0 | 0 | 598711836 | SELECT * FROM accounts LIMIT 100| 7225468 | | 2016-11-16 11:11:46 | webuser[webuser] @ [10.0.1.103] | 00:00:00 | 00:00:00 | 100 | 100 | test | 0 | 0 | 598711836 | Quit | 7225468 | +---------------------+-----------------------------------+------------+-----------+-----------+---------------+------+----------------+-----------+-----------+---------------------------------+-----------+ 3 rows in set (0.00 sec) 以下のように、対象を絞って確認するのも有効 mysql> SELECT start_time, query_time, lock_time, sql_text FROM mysql.slow_log ORDER BY start_time DESC LIMIT 10; RDSでのエラーログは以前は見ることができなかったが、現在は RDS → インスタンス → （インスタンスを選択） → ログ から表示できる…らしいが、思ったような情報が書き込まれていないのでログはMySQL経由で確認するほうがいいような。要勉強 ■タイムアウトの時間を変更する 設定を確認すると、以下のようになっている mysql> SHOW GLOBAL VARIABLES LIKE 'wait_timeout'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | wait_timeout | 28800 | +---------------+-------+ 1 row in set (0.04 sec) 「max_connections」は、RDS上では「{DBInstanceClassMemory/12582880}」となっている 「wait_timeout」は、RDS上では空欄になっている RDSのパラメータグループ設定画面から900（15分）に変更してみる mysql> SHOW GLOBAL VARIABLES LIKE 'wait_timeout'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | wait_timeout | 900 | +---------------+-------+ 1 row in set (0.17 sec) コマンドで確認すると変更されている ■マルチAZにしたときのRDSの挙動 マルチAZにしておくことで、ダウンタイムを短くすることができる RDS起動後にマルチAZに変更する場合の解説は、後述の「RDSをシングルAZからマルチAZに変更」を参照 マルチAZか否かによっての停止時間の差は、後述の「RDSのインスタンスタイプを変更」を参照 【5分でわかる】スペックアップ＆メンテナンス時のRDSの動作 - ナレコムAWSレシピ | AIに強い情報サイト https://recipe.kc-cloud.jp/archives/10806 ■RDSをシングルAZからマルチAZに変更 一時的にMulti-AZにしてフェイルオーバーしたRDSのAvailability Zoneを元にもどす一番簡単な方法（TGI Multi-AZ Pattern） http://blog.serverworks.co.jp/tech/2014/10/08/tgi-multi-az-pattern/ 「RDS」→「インスタンス」→ 対象のインスタンスを選択 →「変更」 「インスタンスの仕様」にある「マルチ AZ 配置」を「はい」に変更し、「次へ」ボタンを押す。 内容を確認し、「変更のスケジュール」にある「すぐに適用」にチェックを入れて「DBインスタンスの変更」ボタンを押す。 少し待つと、インスタンス一覧で「ステータス」が「変更中」になる。 「利用可能」になればOK。 変更自体は15分ほどかかったが、ダウンタイムは発生しないとのこと。 （ブラウザを時々リロードしていたが、アクセスできないことは無かった。） ■RDSのインスタンスタイプを変更 上に書いた、マルチAZへの変更と同じ手順で可能。 ただしシングルAZの場合、6〜8分程度インスタンスが停止する。 マルチAZの場合でも、1分程度インスタンスが停止する。 【AWS】RDSのインスタンスタイプ変更にかかる時間を調べてみた http://dev.classmethod.jp/cloud/aws/rds-scaleup-instancetype/ 18:58に作業を開始して db.t2.micro を db.t2.small に変更した場合、 18:58 変更 18:59 ステータスが「変更中」になった 19:05 データベースに接続できなくなった 19:06 データベースに接続できるようになった 19:14 ステータスが「利用可能」になった くらいの時間だった（上記のように大抵15分程度で完了するが、アクセスが集中しているときに変更すると20分以上かかった） RDSのイベントを見ると19:05に 「Multi-AZ instance failover started」「Multi-AZ instance failover completed」 となっていた。 ブラウザを時々リロードしていたが、接続できない時間は数十秒程度だった。その間RDSからは SQLSTATE[HY000] [2003] Can't connect to MySQL server on 'develop.xxxxx.ap-northeast-1.rds.amazonaws.com' (4) というエラーメッセージが返されていた ■RDSのストレージサイズを変更 以下は古い記事だが、「インスタンスがリブートし」と書かれている。 [AWS] RDSのストレージ容量を増やす - AWS講座 - [SMART] https://rfs.jp/server/aws/aws-rds_strage.html 以下は比較的最近の記事で、「RDSのストレージ追加にはダウンタイムは発生しません」と書かれている。 ただし「ほとんどの場合」とも書かれているので、念のためメンテナンスをスケジュール化して告知したい。 RDSストレージ追加する際に確認しておきたいこと｜スクショはつらいよ https://chariosan.com/2020/09/20/rds_storage_add/ 自動スケーリングは停止時間が発生しないようなので、また検討しておきたい。 【DBのディスクサイズ管理が簡単に】RDSのストレージがストレージの自動スケーリングをサポートしました！ | DevelopersIO https://dev.classmethod.jp/articles/rds-storage-auto-scaling/ 以下、実際にストレージサイズを変更したときのメモ RDSのスペックはdb.t2.micro 設定タブで「ストレージ」は「5GiB」となっている モニタリングによると、「4.7GB」の空きがある 「変更」で「ストレージ割り当て」を「5」から「6」に変更してみる PHPから数秒おきにRDSへ接続させていたが、ダウンタイムは確認できなかった 詳細は以下のとおり 11:40 インスタンスを変更 11:40 ステータスが「変更中」になった 11:44 ステータスが「Storage-optimization」になった。設定タブで「ストレージ」は「6GiB」になった 11:51 モニタリングでは「5.8GB」の空きがあるとなった（段階を経て拡張された） 11:59 ステータスが「利用可能」になった RDSのスペックはdb.t2.small 設定タブで「ストレージ」は「5GiB」となっている モニタリングによると、「890MB」の空きがある 「変更」で「ストレージ割り当て」を「5」から「20」に変更してみる ときどき画面をリロードしての確認では、ダウンタイムは確認できなかった。Cron実行エラーのメールも届いていない 詳細は以下のとおり 17:04 インスタンスを変更 17:04 ステータスが「変更中」になった 17:11 設定タブで「ストレージ」が「20GiB」になった 17:13 ステータスが「Storage-optimization」になった 17:22 モニタリングでは「16GB」の空きがあるとなった（段階を経て拡張された） 17:29 ステータスが「利用可能」になった ■RDSの再起動 RDSの再起動を行ったときのメモ スペックは db.t2.micro でマルチAZなし RDS → データベース → staging の画面で「アクション → 再起動」を実行する データが少ないからか、マルチAZでは無いのに1分ほどで完了した 詳細は以下のとおり 10:54 変更 10:54 ステータスが「再起動中」になり、データベースに接続できなくなった（「システムエラーが発生しました。」の表示になった） 10:55 ステータスが「利用可能」になり、データベースに接続できるようになった スペックは db.t2.small でマルチAZあり RDS → データベース → production の画面で「アクション → 再起動」を実行する 確認画面の「フェイルオーバーで再起動しますか?」にはチェックを付けなかった 再起動は30秒ほどで完了した 詳細は以下のとおり 11:02 変更 11:02 ステータスが「再起動中」になり、データベースに接続できなくなった（「システムエラーが発生しました。」の表示になった） 11:03 ステータスが「利用可能」になり、データベースに接続できるようになった マルチAZでの、フェイルオーバーについては以下に解説がある DB インスタンスの再起動 - Amazon Relational Database Service https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_RebootInstance.html > DB インスタンスのフェイルオーバーを強制的に実行すると、Amazon RDS によって別のアベイラビリティーゾーン内のスタンバイレプリカに自動的に切り替わり、スタンバイ DB インスタンスを参照するように DB インスタンスの DNS レコードが更新されます。 > したがって、DB インスタンスへの既存の接続のクリーンアップと再確立が必要になります。 > フェイルオーバーによる再起動が便利なのは、テスト用の DB インスタンスで障害をシミュレートするときや、フェイルオーバーの実行後にオペレーションを元の AZ に復元するときです。 メモリの回復を目的とした再起動なら、フェイルオーバーは不要そう 必要に応じて判断する ■RDSのマスターパスワードを変更 「RDS」→「インスタンス」→ 対象のインスタンスを選択 →「変更」 「新しいマスターパスワード」に設定したいパスワードを入力し、「次へ」ボタンを押す 内容を確認し、「変更のスケジュール」にある「すぐに適用」にチェックを入れて「DBインスタンスの変更」ボタンを押す ■Blue/Greenデプロイ データベースに対して、マイグレーションに丸2日かかるような変更を行う場合、メンテナンス期間を設けるのも難しい この場合、Blue/Greenデプロイを使えば1分ほどのダウンタイムで変更を行うことができる（準備には本来の時間がかかる） 【衝撃】AWSのRDSがデータを失わないBlue/Greenデプロイに対応しました #reinvent | DevelopersIO https://dev.classmethod.jp/articles/rds-bg-deploy/ Amazon RDS Blue/Green Deployments を色々と検証してみた！ https://zenn.dev/stafes_blog/articles/117a003fa9a1ca RDS Blue/Green Deployments を使ってシュッと utf8mb4 にマイグレーションした話 - カミナシ エンジニアブログ https://kaminashi-developer.hatenablog.jp/entry/2023/07/03/migration-to-utf8mb4-with-rds-blue-green-... ■バックアップの概要 Amazon RDS for SQL Server https://aws.amazon.com/jp/rds/sqlserver/ DBインスタンスのバックアップが毎日、トランザクションログのバックアップが5分ごとに行われ 最大5分前まで、保持期間内の任意の時点にDBインスタンスを復元できます 自動バックアップの保持期間は、最大35日間まで設定できます …とあるが、「データベースを特定時点の内容に戻せる」機能では無いので注意。以下詳細 ■バックアップについて詳細 スナップショットが日次で自動取得され、5分ごとにトランザクションログも保存されている それぞれ、保存先はS3となる これらバックアップから、RDSを復元することができる …が、これらは「データベースを特定時点の内容に戻せる」ではなく、 「特定時点の内容をもとに新規にデータベースを作成する」という機能なので注意 よって復元したデータベースを使用する場合、 ・バックアップをもとにRDSを新規に起動する（普通にRDSを新規作成するだけの時間がかかる） ・サービスのエンドポイントを、新規に起動したRDSに変更する（WebアプリケーションのRDS接続先を変更する） ・セキュリティグループなど一部のパラメータを修正する（バックアップから復元時には指定できない） ・復元中に書き込まれたデータを新しいデータベースに反映する という作業が必要になる スナップショット自体については以下のとおり データベースのバックアップと思っておいて問題ない スナップショット (snapshot)とは｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典 https://wa3.i-3-i.info/word14388.html DB スナップショットの作成 - Amazon Relational Database Service https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html RDSを稼働させたままスナップショットを取得した場合、データの整合性はどのタイミングまで保障されるのでしょうか？ - 株式会社サーバーワークス サポートページ https://support.serverworks.co.jp/hc/ja/articles/360007955413-RDS%E3%82%92%E7%A8%BC%E5%83%8D%E3%81%9... スナップショット自動作成のデフォルト時間は、東京リージョンだと「13:00-21:00 UTC」から自動的に決定されるらしい 過去実際に構築した案件では、毎日「04:00 PM UTC」にバックアップが作成されていた（案件によって数時間の差がある） 「04:00 PM UTC」なので「16:00 UTC」なので「01:00 JST」となり、つまり深夜1時ごろ AWS データベースサービスの自動バックアップ設定まとめ | DevelopersIO https://dev.classmethod.jp/articles/automated-snapshots-of-aws-database-services/ シングルAZの場合、バックアップの際に数秒間I/Oが一時中断することがある マルチAZの場合、バックアップはスタンバイから取得されるためI/Oは中断されない（数分負荷が高くなることはある） バックアップの使用 - Amazon Relational Database Service https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html 自動バックアップウィンドウ中、バックアッププロセスの開始時にストレージ I/O が一時中断することがあります (通常は数秒間)。 マルチ AZ 配置のバックアップ中は、レイテンシーが数分間高くなることがあります。 MariaDB、MySQL、Oracle、PostgreSQL の場合、バックアップはスタンバイから取得されるため、 マルチ AZ 配置のバックアップ中プライマリで I/O アクティビティは中断しません。 ■スナップショットの作成 「RDS」→「インスタンス」→ 対象のインスタンスを選択 → 「アクション」→「スナップショットの取得」 で、「スナップショット名」を指定して取得する 取得したスナップショットは 「RDS」→「スナップショット」 に保存される ■スナップショットの復元 「RDS」→「スナップショット」→ 対象のスナップショットを選択 → 「スナップショットの復元」 で、新規作成時と同様に各パラメータを入力する。 「DBインスタンス識別子」は、既存のものと重複しないものを指定する セキュリティグループなど一部のパラメータは指定できないので、復元後に設定を変更する必要がある 入力したら「DBインスタンスの復元」ボタンを押す。RDSが新規に作成される。 ■特定時点への復元 「RDS」→「インスタンス」→ 対象のインスタンスを選択 → 「アクション」→「特定時点への復元」 で、「復元可能な最新時刻を使用する」もしくは「任意の復元時刻を使用する」で日時を指定 あとは、スナップショットの復元と同様に各パラメータを入力する。 入力したら「DBインスタンスの起動」ボタンを押す。RDSが新規に作成される ■復元中に書き込まれたデータを新しいデータベースに反映 具体的な方法は要検討 SHOW TABLE STATUS; を実行すると、「Create_time」にテーブルの作成日時、「Update_time」にテーブルの更新日時が表示される これをもとに更新されたテーブルを特定 …と思ったが、InnoDBなどでは「Update_time」が常にNULLになるため使えない （InnoDBは、システムテーブルスペース内に複数のテーブルを格納するため） 特定テーブルのみ、独自のシステムでバックアップしておくなど、何らかの保険を持っておくほうがいいかも？ ■停止 RDSは停止できず、課金を中断したければスナップショットを撮って削除する必要があった 現在はシングルAZ構成なら停止が利用できるみたい 本番環境のRDSを止めることはないだろうけど、開発・検収環境のRDSなら使わない間は停止できる …と思ったけど、7日を超えて停止させていると自動で削除されるらしい。使い所がよく分からず [速報] RDSインスタンスの起動/停止 http://dev.classmethod.jp/cloud/aws/start-stop-db-instance-for-rds/ ■マイナーバージョン自動アップグレード [全部乗せ] Amazon Aurora の設定変更で注意が必要なものをまとめてみた | DevelopersIO https://dev.classmethod.jp/articles/tsnote-aurora-downtime-occurs-setting-situation/ RDS マイナーバージョン自動アップグレードについて調べてみる https://zenn.dev/ysmtegsr/scraps/a114584a3a5405 【小ネタ】RDSのマイナーエンジンアップグレードに失敗した話 | SEEDS Creators' Blog | 株式会社シーズ https://www.seeds-std.co.jp/blog/creators/2022-07-28-105106/ RDSのマイナーバージョンアップ = 後方互換あり バージョンアップの自動適用 = ダウンタイムが発生する となっている 意図しないダウンタイムを避けるためにも、本番環境では手動適用の方が良さそう ■メジャーバージョンアップグレード（MariaDB） Amazon RDS の MariaDB のバージョン - Amazon Relational Database Service https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/MariaDB.Concepts.VersionMgmt.html 「MariaDB 10.3 の終了」で10.3の終了について触れられている。2023年10月23日にサポートが終了するとのこと。 MariaDB DB エンジンのアップグレード - Amazon Relational Database Service https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MariaDB.html 「MariaDB DB インスタンスのアップグレード」でアップグレードについて案内されている。 DB インスタンスのエンジンバージョンのアップグレード - Amazon Relational Database Service https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Upgrading.html 「エンジンバージョンの手動アップグレード」について触れられている。「変更」画面からエンジンを変更するとのこと。 【小ネタ】RDSのパラメータグループの差分を簡単に表示してみた | DevelopersIO https://dev.classmethod.jp/articles/diff_rds_parameter/ 同じ設定のパラメータグループを作り直す際に、差分比較を利用できる。 AWSから「[アクションが必要] Amazon RDS for MariaDB はエンジンメジャーバージョン 10.3 を廃止します」というメールが届いた。 本文を確認すると、MariaDB 10.6へのアップグレードが必要とのこと。 メジャーバージョンアップは手動で対応する必要がある。 $ mysql -h develop.xxxxx.ap-northeast-1.rds.amazonaws.com -u webmaster -p Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 100 Server version: 10.3.36-MariaDB-log Source distribution 作業前は「10.3.36」となっている。 該当のRDSには「RDS → パラメータグループ」にある「develop」を適用しているが、これはファミリーが「mariadb10.3」ベースとなっている。 これを「mariadb10.6」ベースにする必要があるが、あとからの変更には対応していない。よってパラメータグループを新規に作成して差し替える。 パラメータグループの一覧で「default.mariadb10.3」と「develop」を選択し、「パラメータグループアクション → 比較」を実行する。 以下の差分が表示された。 パラメータ default.mariadb10.3 develop - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - character_set_client <engine-default> utf8mb4 character_set_connection <engine-default> utf8mb4 character_set_database <engine-default> utf8mb4 character_set_results <engine-default> utf8mb4 character_set_server <engine-default> utf8mb4 init_connect <engine-default> SET SESSION time_zone = CASE WHEN POSITION('rdsadmin@' IN CURRENT_USER()) = 1 THEN 'UTC' ELSE 'Asia/Tokyo' END; innodb_lock_wait_timeout <engine-default> 600 long_query_time <engine-default> 1 slow_query_log <engine-default> 1 これをもとに、新しくパラメータグループを作成する。 パラメータグループファミリー: mariadb10.6 グループ名: develop-mariadb10.6 説明: Parameter group for Develop 比較用に、デフォルト設定用のパラメータグループも作成する。 パラメータグループファミリー: mariadb10.6 グループ名: default-mariadb10-6 説明: Default group for MariaDB10.6 新しく作成したパラメータグループに、差分が無いことを確認する。 差分内容をもとに「develop-mariadb10.6」の値を調整する。調整後に再度差分を比較し、意図した内容になっているか確認する。 AWSコンソールで「RDS → データベース」で「develop」を選択し、「変更」ボタンをクリックする。 「DB エンジンバージョン」が「10.3.36」になっているが、これを「10.6.8」に変更する。（10.6系の一番新しいものを選択する。） 変更すると「DB パラメータグループ」が空欄になるので、上の手順で作成した「develop-mariadb10.6」に変更する。 ページ下部の「続行」ボタンをクリックする。 「変更のスケジュール」で「すぐに適用」を選択し、「DBインスタンスを変更」ボタンをクリックする。 11:45 変更を実行 11:46 ステータスが「アップグレード」になった 11:47 トップページで「SQLSTATE[HY000] [2002] Connection refused (SQL: select * from `session_generals` where `id` = FK9bRNg3gIvH3xYAAP39NuNBbK8eI7GLQ10uddiM limit 1)」のエラーが表示されるようになった 11:50 トップページが表示されるようになった。管理画面へのログインも維持できている 11:53 ステータスが「変更中」になった。サイトにはアクセスできている 11:54 ステータスが「利用可能」になった AWSコンソールで、エンジンバージョンが「10.6.8」になっていることを確認できる また、SSH経由でもバージョンの変更を確認できる $ mysql -h develop.xxxxx.ap-northeast-1.rds.amazonaws.com -u webmaster -p Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 111 Server version: 10.6.8-MariaDB-log managed by https://aws.amazon.com/rds/ ■メジャーバージョンアップグレード（MariaDB / 失敗した手順） AWSコンソールで「RDS → データベース」で「develop」を選択し、「変更」ボタンをクリックする。 「DB エンジンバージョン」が「10.3.36」になっているが、これを「10.6.8」に変更する。（10.6系の一番新しいものを選択する。） ページ下部の「続行」ボタンをクリックする。 「変更のスケジュール」で「すぐに適用」を選択し、「DBインスタンスを変更」ボタンをクリックする。 …が、以下のエラーが表示された。 前述のとおり、パラメータグループを作り直す必要がある。 ■メジャーバージョンアップグレード（MySQL） MySQL5.7をMySQL8.0にバージョンアップしたときのメモ 基本的にはMariaDBと同じ手順で、MySQL8.0用のパラメータグループを作成して割り当てる必要がある 参考までに、MySQL6と7が飛ばされている理由は以下に記載されている What happened to MySQL 6 & 7? - Database Administrators Stack Exchange https://dba.stackexchange.com/questions/207506/what-happened-to-mysql-6-7 以下、実際に作業した時のメモ まずは準備から 以下の内容でパラメータグループを作成する パラメータグループファミリー: mysql5.7 グループ名: test-mysql5 説明: Parameter group for test-mysql 以下の内容でパラメータグループを設定する character_set_client: utf8mb4 character_set_connection: utf8mb4 character_set_database: utf8mb4 character_set_results: utf8mb4 character_set_server: utf8mb4 init_connect: SET SESSION time_zone = CASE WHEN POSITION('rdsadmin@' IN CURRENT_USER()) = 1 THEN 'UTC' ELSE 'Asia/Tokyo' END; 以下の内容でRDSを作成する エンジンのオプション: MySQL エンジンバージョン: MySQL 5.7.44 テンプレート: 本番稼働用 可用性と耐久性: マルチAZ DBインスタンス DBインスタンス識別子: test-mysql マスターユーザの名前: rdsmaster マスターパスワード: abcd1234 DBインスタンスのクラス: db.t3.micro ストレージタイプ: 汎用SSD（gp3） ストレージ割り当て: 20 コンピューティングリソース: EC2コンピューティングリソースに接続しない ネットワークタイプ: IPv4 Virtual Private Cloud: Default VPC DBサブネットグループ: default パブリックアクセス: なし VPCセキュリティグループ (ファイアウォール): default 最初のデータベース名: test DBパラメータグループ: test-mysql5 オプショングループ: default:mysql-5-7 バックアップ保持期間: 1 以下の内容で接続ユーザを作成する # mysql -h test-mysql.xxxxx.ap-northeast-1.rds.amazonaws.com -u rdsmaster -p > GRANT ALL PRIVILEGES ON test.* TO webmaster IDENTIFIED BY 'abcd1234'; # mysql -h test-mysql.xxxxx.ap-northeast-1.rds.amazonaws.com -u webmaster -p テストデータを登録する CREATE TABLE table_test( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'ID', text VARCHAR(255) NOT NULL COMMENT 'テキスト', PRIMARY KEY(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT 'テーブル操作テスト'; INSERT INTO table_test(text) VALUES('テストメッセージ1'); INSERT INTO table_test(text) VALUES('テストメッセージ2'); SELECT * FROM table_test; ひとまず、terraport_testのEC2から接続を試みる （必要になれば新規にEC2を起動する） # vi mysql.php 以下のとおり実行し、各値を取得できることを確認 $ php mysql.php version: 5.7.44 now: 2023-12-12 14:39:21 text: テストメッセージ1 ここまで準備 ここからバージョンアップ 以下の内容でパラメータグループを作成する パラメータグループファミリー: mysql8.0 グループ名: test-mysql8 説明: Parameter group for test-mysql 以下の内容でパラメータグループを設定する character_set_client: utf8mb4 character_set_connection: utf8mb4 character_set_database: utf8mb4 character_set_results: utf8mb4 character_set_server: utf8mb4 init_connect: SET SESSION time_zone = CASE WHEN POSITION('rdsadmin@' IN CURRENT_USER()) = 1 THEN 'UTC' ELSE 'Asia/Tokyo' END; ※MySQL5.7とMySQL8.0の両方で、パラメータグループの「sql_mode」はデフォルトで「NO_ENGINE_SUBSTITUTION」となっている ※MySQL5.7では、パラメータグループの「default_authentication_plugin」はデフォルトで「-」となっている MySQL8.0では、パラメータグループの「default_authentication_plugin」は「mysql_native_password」となっている エンジンバージョンを変更する 対象RDSの「編集」画面で以下のとおり設定を変更する DBエンジンバージョン: 5.7.44 → 8.0.35 DBパラメータグループ: test-mysql8 ※「DBエンジンバージョン」を変更すると、「DBパラメータグループ」が「default.mysql8.0」に変更された また、「オプショングループ」が「default.mysql8.0」に変更された 「DBパラメータグループ」を、上で作成した「test-mysql8」に変更する そのまま「続行」ボタンを押すと、変更内容の確認画面になる 「すぐに適用」にして「DBインスタンスを変更」ボタンを押す 14:50 変更を実行。ステータスが「アップグレード」になった 14:52 トップページで「SQLSTATE[HY000] [2003] Can't connect to MySQL server on 'test-mysql.xxxxx.ap-northeast-1.rds.amazonaws.com' (111)」のエラーが表示されるようになった 14:55 トップページが表示されるようになった 14:58 ステータスが「Configuring-enhanced-monitoring」になった。サイトにはアクセスできている 15:00 ステータスが「変更中」になった。サイトにはアクセスできている 15:02 ステータスが「利用可能」になった テストプログラムを実行して、各値を取得できることを確認 $ php mysql.php version: 8.0.35 now: 2023-12-12 15:02:20 text: テストメッセージ1 ■メジャーバージョンアップグレード（MySQL / 失敗した手順） 対象RDSの「編集」画面で以下のとおり設定を変更する DBエンジンバージョン: 5.7.44 → 8.0.35 この時点で「DBパラメータグループ」と「オプショングループ」の設定がグレーアウトされた そのまま「続行」ボタンを押すと、変更内容の確認画面になる 「DBインスタンスを変更」ボタンを押すと、以下のエラーが表示された MariaDBのときと同じく、MySQL8.0用のパラメータグループを作成しておく必要があるのだと思われる ■RDSのメモリ 空きメモリ（FreeableMemory）がどんどん減少するので調査したときのメモ（2GBのメモリだが、空き容量が200MBくらいまで下がった） RDSの挙動としては ・パラメータ「innodb_buffer_pool_size」によって定められた値までメモリの割り当てを行う ・デフォルトで「{DBInstanceClassMemory*3/4}」となっており、この値を変更することは推奨されない ・RDSがsmallの場合、メモリ容量2GBのうち3/4である1.5GB程度は、InnoDBのバッファプールがメモリを使用することが想定された挙動となる ・RDSインスタンスの再起動により、FreeableMemoryの値が回復する可能性はあるが、運用していると同じ水準まで下がると思われる となっているらしい 今回はRDSを再起動することで、空きメモリは1GBくらいまで増えた その後徐々に下がっていったが、440MBくらいで下がるのが止まった。これなら想定の範囲内と言えそう さらい下がるようなら、RDSのスペックアップが必要なのかもしれない ■RDSのスワップ RDSのスワップを監視していると ・CPU使用率は基本的には1〜2%程度。たまに30%とか ・使用可能なメモリは1.4GBほどある ・書き込みレイテンシーはほとんど0 ・スワップは時々発生している という状態になっている どの案件のRDSも数値は違えど同じ動作をしているので、 少なくとも「RDSに余計な設定をしてしまったからメモリが正しく使われていない」は無さそう デフォルトの設定から、さらに突き詰めた設定をすべき、とかはあるかも インスタンスをアップすべき、とかはあるかも 微々たるものだから問題ではない、とか？ AWS Developer Forums: RDS mysql instance uses swap but have ... https://forums.aws.amazon.com/message.jspa?messageID=383919 RDSはそういう動作が普通みたい？ EC2も、freeのメモリがあってもswapは少し消費されるみたい？ Linuxサーバ全般でそういうものかも？ メモリ−は十分なはずなのに SWAP を使ってる？ | Linux のメモリー管理(メモリ−が足りない？,メモリーリークの検出/防止)(Kodama's tips page) http://www.math.kobe-u.ac.jp/HOME/kodama/tips-free-memory.html#memory_swap どうしてメモリはスワップするのか！？ - インフラエンジニアway - Powered by HEARTBEATS https://heartbeats.jp/hbblog/2014/01/linux-page-swap.html 使われていないプログラムをメモリから追い出し、バッファやキャッシュに転用する その際にもスワップが使われるらしい 物理メモリの空き容量が足りていても、malloc()した際に連続した領域が確保できないと、 その領域を確保できるまで物理メモリに存在するページをスワップするらしい ■Aurora Amazon Aurora（高性能マネージドリレーショナルデータベース）| AWS https://aws.amazon.com/jp/rds/aurora/ Amazon Auroraとは何かをわかりやすく図解、RDSとどう違う？ 連載：全部わかるAWS入門｜ビジネス+IT https://www.sbbit.jp/article/cont1/95514 Amazon Auroraを作成してみた | DevelopersIO https://dev.classmethod.jp/articles/lim-rds-aurora/ Amazon AuroraはRDSのデータベースエンジンの1つであり、 クラウドの普及に伴ってAmazonがその内部アーキテクチャを再設計したデータベース ■Aurora Serverless ※未検証 Amazon Aurora Serverless | AWS https://aws.amazon.com/jp/rds/aurora/serverless/ 待たせたな！噂のAuroraサーバーレスv2がGA。初心者にも分かりやすくまとめてみた - Qiita https://qiita.com/minorun365/items/2a548f6138b6869de51a Aurora Serverlessについての整理 | DevelopersIO https://dev.classmethod.jp/articles/aurora-serverless-summary/ Aurora Serverlessを実際に使ってみたメリットとデメリット | 株式会社PLAN-B https://service.plan-b.co.jp/blog/tech/28232/ インスタンススケールの管理も含めて対応してくれる 通常のAmazon Auroraに比べると料金は高めみたいだが、 高いスペックで常時稼働させているインスタンスなら、細やかなスケーリングにより費用を抑えられる可能性はありそう ■リードレプリカ 【AWS】知識ゼロから理解するRDS超入門 | 技術ブログ | MIYABI Lab https://miyabi-lab.space/blog/31 【Amazon RDS】マルチAZとリードレプリカの違い - Qiita https://qiita.com/1_ta/items/85954500a2c667f0e898 【AWS】RDSのレプリケーションについて解説します。 - Amazon Web Service(AWS)導入開発支援 https://www.acrovision.jp/service/aws/?p=2462 コラム - Amazon Web Servicesを追いかける | 第4回　Amazon RDS リードレプリカの設定｜CTC教育サービス 研修/トレーニング https://www.school.ctc-g.co.jp/columns/strawbag/strawbag04.html RDSのマルチAZは、あくまでもバックアップのためであって、そのままリードレプリカとして使えるものでは無いみたい？ 別途「リードレプリカを作成」の作業を行うことで、リードレプリカのエンドポイントが発行され、接続できるようになるみたい？ （マルチAZで無いRDSでも、「リードレプリカを作成」のメニューは存在する） ただし「マスター」「スレーブ」「レプリカ」の3台構成になるため、単純なマルチAZに比べると料金が1.5倍になるので注意 要勉強 Amazon Auroraを作成してみた | DevelopersIO https://dev.classmethod.jp/articles/lim-rds-aurora/ Aurora+MySQLの場合、レプリカを作成しなくてもスレーブに読み込み専用でアクセスできるみたい？ つまりAuroraの方が台数を抑えられるが、1台あたりのコストはAuroraの方が高いらしい また、パフォーマンスはAuroraの方が高いらしい Laravelでマスター／スレーブ構成のデータベースに接続するための設定 | I am a software engineer https://imanengineer.net/laravel-how-to-configure-master-slave-db/ レプリカのデータを参照する場合、原則プログラム側で接続先を切り替える必要がある Laravelの場合、設定を調整することにより、マスター/スレーブのデータベースに対して、 「SELECTクエリ発行時はスレーブ」「それ以外はwriteマスター」 ができるらしい ■証明書の更新 外部からSSL/TLS接続しないRDSも含めて対応が必要 放置しておくと2020年3月5日に強制アップデートされる 予期しないダウンタイムを避けるためには、手動で設定変更＆RDS再起動をする必要がある 【早めに準備を！】2020年にAmazon Relational Database Service (RDS)/Amazon AuroraでSSL/TLS証明書をアップデートする必要が生じます ｜ Developers.IO https://dev.classmethod.jp/cloud/aws/notification-about-certificate-rotation-for-rds-and-aurora/ RDSとAuroraのSSL/TLS 証明書のメンテナンスアナウンスについて - サーバーワークスエンジニアブログ http://blog.serverworks.co.jp/tech/2019/10/18/rds-aurora-certificate-maintanance/ ■PostgreSQL RDSを新規に作成する際、「エンジンのタイプ」として「Amazon Aurora」や「MySQL」などとともに「PostgreSQL」が並んでいる よってMySQLとPostgreSQLを併用するなら、2台のRDSを起動する必要があるみたい ユーザの権限などハマりどころはあるようなので、使う場合は以下などで改めて確認したい RDS (PostgreSQL) でデータベースを作成するときの注意点 - Qiita https://qiita.com/bwtakacy/items/845c193c6da3218a546d RDS PostgreSQLで参照専用のユーザを作成する（複数のスキーマがあっても一発で） - Qiita https://qiita.com/Morihaya/items/b4c5c7f28736b95be732 ■オートスケーリング RDSは原則オートスケーリングに対応していない ただしAurora Serverlessなら対応している 詳細は、前述のファイル内の「Aurora Serverless」を参照 また「ElastiCache (Redis)」内の「オートスケーリング」も参考にする