こんにちは、インフラのテックリードをしている沼沢です。
この記事は、「あすけんの Aurora 2 → Aurora 3 へのメジャーバージョンアップ軌跡」の第4弾です。
過去の記事はこちらからお読みください。
あすけんの Aurora 2 → Aurora 3 へのメジャーバージョンアップ軌跡 (1) 絶望篇
あすけんの Aurora 2 → Aurora 3 へのメジャーバージョンアップ軌跡 (2) 希望篇
あすけんの Aurora 2 → Aurora 3 へのメジャーバージョンアップ軌跡 (3) 困難篇
度重なるメンテナンス延期に見舞われましたが、ついに完結します。
4th Take
3rd Take で発覚したレプリケーションエラーをスキップ後、レプリケーションは再開していたため、レプリケーションが追いつくのを待つだけの状態でした。
そのため、すぐさまビジネスサイドとの再々々調整を行い、次は12月上旬での実施が決まりました。
また、3rd Take と同じ失敗が起きても気付けるように、AuroraBinlogReplicaLag が0未満を示した場合に Slack に通知が飛ぶように仕込んでおきました。
2024年11月中旬〜11月末
ここまで レプリカ側の Aurora MySQL のバージョンは 3.07.1 (MySQL 8.0.36 互換)を利用していましたが、事前調査で MySQL 8.0.36 には COUNT(*) 遅い問題など、様々な問題が報告されていることがわかっていました。
MySQL 8.0.37 では解消されているとの情報も入手していたことから、MySQL 8.0.37 以上の互換性を持った Aurora のマイナーバージョンがリリースされた場合はアップグレードしようと以前から決めていました。
そんな中、2024年11月17日に MySQL 8.0.39 互換である Aurora MySQL 3.08 がリリースされたことで、次回のメンテナンスまでにアップグレードをしておくことにしました。
https://aws.amazon.com/jp/about-aws/whats-new/2024/11/amazon-aurora-mysql-3-08-compatible-8-0-39-generally-available/
無事にレプリカ側のマイナーバージョンアップを行い、レプリケーションを再開させ、メンテナンス日を待つだけの日々を過ごしました。
2024年12月上旬
マイナーバージョンアップ対応の数日後、レプリケーションの状態を確認した時、AuroraBinlogReplicaLag が0のまま、一度もラグが増えることなく推移していることに気が付きました。
これまでレプリケーションが正常に稼働していた際、0になることはあっても常に0という状態はありませんでした。
嫌な予感しかしない。
マイナーバージョンアップしたことでレプリケーションの効率性が上がってラグが出なくなった可能性を考え、リリースノートを改めて確認しましたがレプリケーション効率性に関する変更は特に見当たりませんでした。
他のメトリクスを確認したところ、レプリケーションが正常に稼働していれば1以上を記録しているはずの DMLThroughput や Queries も0を示していました。
クエリが実行されていないのにラグがない…？
状況がよくわからないまま、レプリカステータスを確認しました。(一部抜粋)
mysql> show replica status\G *************************** 1. row *************************** ~~snip~~ Source_Log_File: mysql-bin-changelog.414938 Read_Source_Log_Pos: 127863388 Relay_Log_File: relaylog.559041 Relay_Log_Pos: 5497813 Relay_Source_Log_File: mysql-bin-changelog.414931 Replica_IO_Running: Yes Replica_SQL_Running: Yes ~~snip~~ Last_Errno: 0 Last_Error: ~~snip~~ Seconds_Behind_Source: 0 ~~snip~~ Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: ~~snip~~ Replica_SQL_Running_State: waiting for handler commit ~~snip~~ Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: 以下略
Replica_IO_Running、Replica_SQL_Running ともに Yes、ということはレプリケーションは正常に動いている…？
Seconds_Behind_Source は 0 ですが、ポジションなどを確認するとソース側とかなりの開きが出ている事がわかります。
ではなぜレプリケーションは正常とみなされているのか。
Replica_SQL_Running_State を見ると「waiting for handler commit」とあります。
このステータスは「スレッドが他のクエリのトランザクションのコミットを待機」している状態のことを指しますが、いつまで経ってもこの状態から変わりません。
https://dev.mysql.com/doc/refman/8.0/ja/general-thread-states.html
もしかすると、このクラスタ固有の問題かもしれないと考え、スナップショットから復元したクラスタ同士で同様のレプリケーション設定を行いましたが、同じように「waiting for handler commit」で止まってしまう状態は必ず再現しました。
少し調べてみると、過去の MySQL バージョンに似たようなバグがあったことがわかり、MySQL 8.0.39 互換である Aurora MySQL 3.08.0 でも同じようなバグが存在するのではないかと考えました。(公式情報は見つけられず…)
https://stackoverflow.com/questions/72029457/mysql-waiting-for-handler-commit
ここまで試したことや調べたことを持って AWS サポートに問い合わせをしましたが、問題の解決には至りませんでした。
レプリケーションが止まってから既に2日半ほどを費やしており、これ以上時間をかけていても仕方がないと考え、元のバージョンに戻して再チャレンジすることとしました。
RDS は稼働中のクラスタを過去バージョンに戻すことはできないため、またデータディクショナリ不整合の解消からやり直しです。
※マイナーバージョンアップ前のスナップショットから復元すればバージョンダウンは可能ですが、このスナップショットは日数が経過しており、レプリカラグが開きすぎていることからやり直しを選択しました。
5th Take
すぐさま次回のメンテナンス日程を再々々々調整を行い、もはや慣れてしまった手順でレプリケーションを貼るところまで完了しました。
2024年12月25日
迎えたメンテナンス当日。
“あすけんの女” こと未来さんが彼氏の存在を匂わせたとして世間を騒がせてしまったあの日、裏ではエンジニアたちが夜な夜な集まりメンテナンスを行いました。
※匂わせについて気になる方はこちらへどうぞ
https://togetter.com/li/2485137
終わってしまえばなんてことはなく、この日、メジャーバージョンアップ対応はあっけなく幕を閉じました。
その後の経過も特に問題は発生せず、無事に2025年を迎えることができたのでした。
おまけ
万が一どうにもならない事態が発生する場面を想定し旧クラスタを1台だけ起動したまま残しておきましたが、データ量が膨大なためそれなりにコストがかかります。
新年を気持ち良く迎えるため、大晦日の夜に煩悩とともに旧クラスタを消し去りました。
また、それでも万が一のことを考え、しばらくは最終スナップショットを保持していましたが、それもつい先日削除しました。
これでついに完全に旧クラスタとお別れすることができました。
さようなら、全ての Aurora 2 クラスタたち。
俺たちの戦いはこれからだ
俺たちと一緒に戦ってくれる仲間を募集しています！
このようなカオスを楽しめる方からのご連絡お待ちしております。
https://www.asken.inc/recruit
