はじめに
長年 RDS for MySQL の 5.6 を使っていたのですが、昨年の 10 月くらいにリザーブドが切れるタイミングで(安くなって性能も上がるので)インスタンスタイプを変更しようと思ったのですよ。インスタンスタイプ変更なのでメンテ挟んで〜ということになるので、準備などをしてメンテ前日を迎えたわけです。
新しいインスタンスタイプでレプリカを作っておくというのをやろうとしたら、作れないと言われる...色々調べてみたら MySQL 8 以降じゃないとそのインスタンスタイプは使えないと...(料金表にはそんなこと書いてないじゃないかクソが！などと思った記憶があるのですが)そんなこんなで 2021 年のお仕事の一つが MySQL の version up に決定。
2 月に 5.7 にするか〜と思っていたら 5.6 サポート終了のお知らせ が出てました。
ということで 5.7 にする際に調べた RDS の挙動などをメモっておく
5.6 -> 5.7 の変更点
社の福利厚生で @yoku0825 さんに気軽に質問出来るので教えてください〜と言ったら
大量に教えてもらった。
- sql_mode のデフォの変更
- innodb_default_row_format について
- パーティショニングの方式変更
- 暗黙のテンポラリーテーブルに関して
5.7 に関してはこのくらいで 8 に関しては 5 倍くらいの情報を教えてくれた(感謝)
自分のサービスで使用している RDS で気にしないといけないところは特になかった。というのも、sql_mode は 5.7 デフォルトのパラメータグループであれば 5.6 と一緒だし、innodb_tmp_data_file_path に関しては RDS では変更不可。
version up 方法
続いてはどうやって version up させるか？という話。
前提としてプライマリに対して n 台のレプリカ紐づいているという構成
検証なので本番のスナップショットから復元した検証用の構成を使っている
プライマリを 5.7 にする
何も考えずプライマリを 5.7 にあげようとしたところ、レプリカが全台プライマリより上の version じゃないとプライマリは version up 出来ないと言われて終了。
レプリカを 5.7 にする
上記のような結果になったので全てのレプリカを 5.7 にした。5.7 にしている最中は一定時間接続出来なくなる。
再度プライマリの 5.7 化にチャレンジ
すんなりいけた。
これで 5.7 にするという方法は理解できたのだけれど、何か問題があって一定時間稼働させた後に 5.6 に戻したいとなった場合に辛いなと思ったのでそこら辺の検証をした。
version のロールバック方法の検証
上記の version up の検証をする前に考えていたのは下記
レプリカ一台を 5.6 のままにしておき、他のプライマリ/レプリカ全台を 5.7 にする。この状態で問題が起きたら 5.6 のレプリカを昇格させる。だったのだが上記の検証でそれが不可能なことが発覚した。
次に試したのが、プライマリ 5.6 の状態でレプリカが 5.7 と 5.6 の状態で 5.7 のレプリカを昇格させると 5.6 のレプリカのレプリケーション先は昇格した 5.7 のシン・プライマリに向くんでは？というやーつ。試したが 5.6 レプリカは 5.6 プライマリに対してレプリケーションしてた(元々こういう挙動だったっけ？)
実際に試した方法は上記だけで、他には binlog や全クエリのログを保存しているのでそれを使って差分を流し込むなどが考えられる。
その他にも RDS から EC2 とかで自前で建てた MySQL にレプリケーションが出来ればごにょごにょできるよね〜という選択肢もあるにはあるか？など考えていた。
結局簡単に戻せる方法はないのか？が知りたかったので AWS の中の人に直接聞いたら、結論としては簡単に戻せる方法はないのでクエリのログとかから手動で頑張ってという回答をいただいた。
さいごに
そんなこんなで問題が起きたら手動で頑張るしかないのか〜(手順はわかるが)めんどくさいな〜と思いつつ、水曜日の早朝にメンテナンスを行い 5.7 に上げたが特に問題は発生していないので、大勝利。
8 への version up も少し時間を空けてからトライする予定。
