Amazon RDS for MySQL v8へのみちのり 第32回 中国地方DB勉強 2023/10/07 ※このページは削除して構いません USE TEMPLATE Click @gho4d76g

● お話すること（主にインフラ観点） ○ Amazon RDS for MySQLのライフサイクル ○ Amazon RDS for MySQLのアップグレードとサービスダウンタイム ○ Amazon RDS for MySQLv5.5→v5.6→v5.7→v8 を駆け抜けたあるシステム の話 ● お話しないこと（主にアプリケーション観点） ○ データベースバージョン移行におけるアプリケーションの機能・性能試験に関 するトピック ○ データベースエンジンのパフォーマンスチューニングに関するトピック 今日お話すること・しないこと

Amazon RDS for MySQLのライフサイクル MySQL Community Edition Amazon RDS for MySQL 2024 2022 2020 2018 2016 2014 2012 2010 2024 2022 2020 2018 2016 2014 2012 2010 v5.6 Release v5.6 Release v5.6 EoL v5.7 Release v5.7 EoL v5.7 Release v8.0 Release v8.0 Release 2026 v8.0 EoL（予定） 2026 v5.6 EoL（延長） v5.7 EoL（延長） ｲﾏｺｺ! v8.0 EoL（予定） ─Community Supportを基準にライフサイクル管理を考えるのが基本 ─

Amazon RDS for MySQLライフサイクル 2023/9/1にv5.7系EoL発表と併せ て延長サポートを発表 ● 最大3年間の有償延長サポート ● 2023/12からオプトイン可 ● これまでのdbインスタンス稼働コ ストに加えて$0.120/vCPU数/時 間の追加コストが発生 （ap-northeast-1, 2年目まで） https://aws.amazon.com/jp/about-aws/whats-new/2023/09/amazon-aurora-rds-extended-support-mysql-postgresql-databases/?nc1=h_ls

[命題] ○ データベースはITサービスの構成要素の中で最も長命 ○ データベースの格納データは基本的に増え続ける ○ データベースの停止 ＝ ITサービスの停止 ○ ITサービスにはそれぞれ許容可能なダウンタイムが存在する アップグレード vs サービスダウンタイム 移行方式設計 is 重要

(1)単純なインプレースアップグレード v5.7.x P アップグレードプロセス v8.0.x P 許容可能な サービスダウンタイムか？ アップグレードを開始 アップグレード完了 アップグレードに所要する時間は対象のデータベースの状態によって 大きく異なるためリハーサル重要

リードレプリカによる多段アップグレード方式 v5.7.x v5.7.x v5.7.x v8.0.x プライマリ （オンライン状態) リードレプリカ作成 プライマリ （オンライン状態) v8.0.x v5.7.x スイッチオーバー サービスダウンタイム 約10分程度 非同期レプリ ケーション 非同期レプリ ケーション(*) ※ 異なるマイナーバージョン、 異なるメジャーバージョン間の非同期レプリケーションが可能（ただし制約もある） 参考: MySQL バージョン間のレプリケーション互換性 (https://dev.mysql.com/doc/refman/8.0/ja/replication-compatibility.html) 破棄 (2)リードレプリカによるスイッチオーバー方式 レプリケーションを解除し アップグレードを開始 アップグレード完了後、レ プリケーションを再開 プライマリはこの時間分の Binaryログを保持を担保 （binlog retention hours+十分な ストレージ空きスペース） アップグレードプロセス （≠サービスダウンタイム） P P RR P RR P

● AWS re:Invent 2022で発表 ● ミラー環境（Green）のリソースデプロイ、ロ ジカルレプリケーションの構成、同期、 Blue-Green間のスイッチオーバーといった 一連のタスクをよしなにコントロールしてくれ るサービス (3)Amazon RDS ブルー/グリーンデプロイ 画像出所: https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html

RDS for MySQL v5.5→5.6→v5.7→v8 を駆け抜け たあるシステムの話 時期 主要なDBメンテナンス 移行方式 特記 2016年 v5.5.x → v5.6.x への更新 インプレースアップグレー ド ー 2021年 v5.6.x → v5.7.x への更新 インプレースアップグレー ド（※） デフォルトでは許容不可能なダウンタイム が発生するためワークアラウンドとして ”old temporal datatypes” の変換処理 をスキップすることを選択 2022年 DBインスタンスストレージ 暗号化 暗号化したリードレプリカ によるスイッチオーバー インプレースでは不可能。加えてRDS固有 の問題であるファーストアタッチペナルティ との戦い 2023年 v5.7.x → v8.0.x への更新、 ストレージType変換（GP3 移行） 異なるメジャーバージョン のレプリカによるスイッチ オーバー v8.0でold temporal datatypesのサ ポート終了にともない、v5.7移行時の方式 選択が一気に負債化 → 呪縛／(^o^)＼

● ”old temporal datatypes”とは? ○ MySQL5.6.4より前に使用されていたマイクロ秒非対応のTIME、DATETIME型。 MySQL8.0では廃止されておりアップグレード前にこれらの型変換が必須 ○ 通常のmysql_upgradeあるいはALTER TABLE FORCEによって変換可能 ● なぜ負債化したのか? ○ v5.7移行時に、インプレースアップグレード時間短縮のために、”old temporal datatypes”の変換を省略 (─avoid_temporal_upgradeの甘い誘惑─) ○ RDS固有の制約でRDSマスターユーザーであってもシステムスキーマ (e.g. mysql)のデータ ベースオブジェクトを変更できない (─アンタッチャブルパワー・ rdsadmin─) ”old temporal datatypes”の負債化

パラメータ `avoid_temporal_upgrade=false`を設定して5.7.38→5.7.41間のマイナーバー ジョンアップをすることでシステムスキーマに残置した old temporal datatypesを変換。その 後、v8系へのメジャーアップグレードが可能に（ ただし、トレード・オフとしてマイナーアップグ レード所要時間は48時間超え💦） ”old temporal datatypes”の負債化 5.7.38 5.7.41 8.0.32 マイナーアップグレード メジャーアップグレード システムスキーマに古い DATETIME型が残置 （ALTER不可） 直接アップグレードは不可 能 システムスキーマの古い DATETIME型が変換され た状態 (∩´∀｀)∩ﾜｰｲ

怖い話👻 次の条件を満たす場合にRDS for MySQL v8系への道が閉ざされる可能性 があります。 ● v5.6.4系以前のバージョンでプロビジョンしたRDS DBインスタンス ● v5.6.4移行後にパラメータ `avoid_temporal_upgrade=true` を設定 ● 現時点のv5.7系最新バージョン(v5.7.43)まで更新ずみ 最後の希望は v5.7.44のマイナーアップデートリリース ただし、現時点ではv5.7.44のリリース予定は未定

● 移行方式設計は慎重に ○ 先の先を見なアカン──── ○ 手間を惜しまず、人事を尽くそう ● マネージドサービスに固有の制約に向き合う ○ RDS for MySQLの場合: ■ ファーストアタッチペナルティ、rdsadminという特別な存在 ● 今後の不安要素 ○ utf8mb3の廃止が次の負債化の予感💦 まとめ