Amazon Aurora MySQL 3でBlue/Greenデプロイした時GreenはRead Onlyじゃない

掲題の通りだが、Amazon Aurora MySQL 3においてはデフォルトでGreen環境へ書き込みが許可されているようだ。

上記RDSのドキュメントには下記の記載がある。

ブルー/グリーンデプロイを作成すると、グリーン環境の DB インスタンスはデフォルトで読み取り専用になります。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html

テスト中は、グリーン環境のデータベースを読み取り専用に保つことをお勧めします。グリーン環境ではレプリケーションの競合が発生する可能性があるため、書き込み操作を有効にする場合は注意してください。また、スイッチオーバー後に本稼働データベースに意図しないデータが発生する可能性もあります。RDS for MySQL の書き込み操作を有効にするには、read_only パラメータを 0 に設定し、DB インスタンスを再起動します。RDS for PostgreSQL の場合、セッションレベルで default_transaction_read_only パラメータを off に設定します。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html

対してAuroraは専用のドキュメントが用意されておりそちらには下記記載がある。

重要

Aurora MySQL バージョン 3 では、ブルー/グリーンデプロイを作成すると、グリーン環境の DB クラスターはデフォルトで書き込み操作を許可します。read_only パラメータ を 1 に設定し、クラスターを再起動して、DB クラスターを読み取り専用にすることをお勧めします。

RDSのドキュメントを確認してRead Onlyになっている認識でいたので、Green環境を見て驚いた。
Aurora MySQL 2が2024年10月31日に標準サポート期限を迎えるため、Aurora MySQL 3にバージョンアップする機会も増えるだろうし留意しておきたい。

要点整理から攻略する『AWS認定 データベース-専門知識』 (Compass Booksシリーズ)

mysqldump8.0.32でsingle-transactionの挙動が変わった

参考記事に書いてある通りだが知らなかったので備忘録

参考記事

• AWS RDSにmysqldump: Couldn't execute 'FLUSH TABLES WITH READ LOCK': Access denied for userが出て接続できなくなった - mattintosh note
• mysqldumpを「8.0.32」にアップグレードするとRDSのMySQL環境に対して、mysqldumpができなくなったときの対応メモ #AWS - Qiita

要はmysqldumpのsingle-transactionの動作が8.0.31と8.0.32以上で異なる
8.0.32以上ではFLUSH TABLES WITH READ LOCKを実行するようになった

Amazon RDSではFLUSH TABLES WITH READ LOCKは許可されていないので8.0.32以上で、
single-transactionを実行するとCouldn't execute 'FLUSH TABLES WITH READ LOCK'になる

8.0.33以上で--set-gtid-purged=OFFをつければAmazon Aurora MySQLでdump取得できた

MySQL運用・管理［実践］入門 〜安全かつ高速にデータを扱う内部構造・動作原理を学ぶ

Amazon S3のライフサイクルによるストレージクラス移行制約

S3のライフサイクルによってストレージクラス移行を設定したがストレージクラス移行されないファイルがあり原因を調査しました。
今回はStandardからGlacier Instant Retrievalに移行を試みました。

結果、今回はファイルの容量が5KiB程度であった為下記制約に該当していました。

• 128 KiB 未満のオブジェクト – 以下の移行では、Amazon S3 は 128 KiB 未満のオブジェクトを移行しません。
  • S3 Standard または S3 標準 – IA ストレージクラスから S3 Intelligent-Tiering または S3 Glacier Instant Retrieval へ移行します。
  • S3 Standard ストレージクラスから S3 Standard – IA または S3 1 ゾーン – IA への移行。

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html

なぜ、128KiBが閾値になるかというとS3料金のストレージクラス毎の説明が関係してきます。

S3 Glacier Instant Retrieval の課金対象となる最小オブジェクトサイズは 128 KB です。128 KB より小さいサイズのオブジェクトを保存することもできますが、適切なストレージクラス料金で 128 KB のストレージとして課金されます。

https://aws.amazon.com/jp/s3/pricing/

日本語が難しいですね。適切なストレージクラス料金...この点下記記事で確認してくれていました。

「128 KB より小さいオブジェクトは 128 KB として S3 Glacier Instant Retrieval のストレージ料金で課金される」が正しい考え方でした。

https://dev.classmethod.jp/articles/s3-minimum-billable-object-size/

当方で試算をしてみるとストレージ料金のみで考えると26KiBより大きい場合にはGlacier Instant Retrievalに置いたほうが安くなりそうでした。
ライフサイクルで移行してくれないだけで明示的に指定すればストレージクラスの変更は可能です。
数ファイルくらいでは気にする必要ないと思いますが、ファイル数が膨大になるようだと価格差が気になってくるかもしれませんね。

AWSコスト最適化ガイドブック