発生したバージョン
- Aurora MySQL 3.10.0
現象
DBクラスターパラメータグループ(以降、場所によってはDBCPGと記載)またはDBインスタンスパラメータグループ(以降、場所によってはDBIPGと記載)で以下のパラメータを設定した。
| パラメータ名 | 値 |
|---|---|
init_connect |
SET SESSION time_zone = CASE WHEN POSITION('rds' IN CURRENT_USER()) = 1 THEN 'UTC' ELSE 'Asia/Tokyo' END; |
その直後からDBを利用しているサービスで接続エラーが発生した。
このエラーは、DBインスタンスを再起動することで解決した。
原因の結論
バグ。
MySQL自体によるものか、RDS(Aurora)によるものかは完全には判断がつかなかったが、高確率でRDS固有のもの。関連する問題が少なくとも2015年時点では認知されていた雰囲気がある。
2025/08/12追記
記事末尾に追記したとおり、AWSサポートからAWS固有の問題であるとの回答があった。
原因調査詳細
現象が発生する条件の調査
まず、 init_connect に設定する値は変えず、DBクラスターパラメータグループとDBインスタンスパラメータグループのどちらへどのように設定すれば問題が発生するかを調査した。
それをまとめたのが以下:
| 変更概要 | DBCPG(変更前) | DBIPG(変更前) | DBCPG(変更後) | DBIPG(変更後) | 問題が発生 |
|---|---|---|---|---|---|
① init_connect パラメータを新たに追加 |
なし | なし | なし | あり | 発生する |
| ② 記述箇所をDBIPGからDBCPGに移動 | なし | あり | あり | なし | 発生する |
| ③ 記述箇所をDBCPGからDBIPGに移動 | あり | なし | なし | あり | 発生する |
| ④ DBIPGと全く同じ値をDBCPGにも記載 | なし | あり | あり | あり | 発生する |
⑤ init_connect パラメータを削除 |
なし | あり | なし | なし | 発生しない |
-
なし:init_connectに何も設定されていない状態 -
あり:init_connectにSET SESSION time_zone = CASE WHEN POSITION('rds' IN CURRENT_USER()) = 1 THEN 'UTC' ELSE 'Asia/Tokyo' END;が設定されている状態
いずれの問題発生もDBインスタンスの再起動で復旧した。
また、不正確ながら複数インスタンスで構成されるクラスターの場合、再起動したインスタンスのみ復旧したように見えた (これは再検証していない)。
この結果で特に目を引くのは②③④で、いずれも本来であればDBへなんの影響も与えない変更 (DBクラスターパラメータグループとDBインスタンスパラメータグループは後者を優先としてどちらかの値が採用されるため)であるにも関わらず、実際には問題が発生してしまっている。
唯一問題が発生しなかった⑤は init_connect パラメータを削除したケースで、一連の調査では init_connect を設定したとき、もし仮にそれが本来なんの意味もない、既存と同じ値の設定だったとしても、問題を発生させるということがわかった。
エラーログ
error/mysql-error.log を確認すると次の様なメッセージが大量に出ていた。
2025-08-07T22:12:22.105373Z 246376 [Warning] [MY-013130] [Server] Aborted connection 246376 to db: 'dev_abc' user: 'dev_abc_s' host: '11.109.130.12' (init_connect command failed; diagnostics area: MY-001064 - You have an error in your SQL syntax; check the manual that corr)
このログより、 init_connect で設定されているクエリになんらかの異常が発生している可能性が出てきた。
init_connect の実際の値の確認
以下、3つの init_connect の値はそれぞれ上から
- パラメータグループの変更前
- パラメータグループの変更後
- インスタンスの再起動後
これをまとめたのが以下:
| タイミング |
init_connect の値 |
|---|---|
| ①パラメータグループの変更前 | SET SESSION time_zone = CASE WHEN POSITION('rds' IN CURRENT_USER()) = 1 THEN 'UTC' ELSE 'Asia/Tokyo' END; |
| ②パラメータグループの変更後 | SET SESSION time_zone = CASE WHEN POSITION(''rds'' IN CURRENT_USER()) = 1 THEN ''UTC'' ELSE ''Asia/Tokyo'' END; |
| ③インスタンスの再起動後 | SET SESSION time_zone = CASE WHEN POSITION('rds' IN CURRENT_USER()) = 1 THEN 'UTC' ELSE 'Asia/Tokyo' END; |
これを見れば分かる通り、問題が発生している②のタイミングだけ init_connect の値がおかしい。
これはエラーログ・エラーメッセージの内容とも整合している。
また、②と③の間ではDBインスタンスの再起動しかしておらず、パラメータグループの値は変わっていない。
調査結果から推測される問題発生のメカニズム
問題はDBインスタンスを再起動せず、パラメータグループを変えたときだけに発生する。
このことから、 init_connect を変更したときの各インスタンス設定への反映プロセスにバグがあり、具体的には ' (シングルクォート)のエスケープ実装に問題があって、1つのシングルクォートが2つに増殖するのだと思われる。
MySQL自体とAWS RDS、どちらのバグなのか？
2025/08/08現在、3時間ほどネット上を調査したが、完全に同一の現象報告は見つからなかった。
ただし、AWS RDSについて似た報告が多数あり、一方でMySQL自体の問題としての情報はほぼなかったため、AWS RDS固有のバグ・問題の可能性が高い (2025/08/12追記: AWSサポートからの回答でAWS側のバグと確定)。
以下はその状況証拠的調査結果:
RDS(MySQLエンジンにてタイムゾーンを変更する方法を整理) #MySQL - Qiita
というのも、この設定を施した上でRDSが再起動もしくはfailoverするとMySQL接続後クエリを発行出来なくなるという不具合があるからである。
この記事では逆に再起動すると問題が発生する、という記述がある。
また、その回避策としてストアドプロシージャーを使うという方法を書いているが、これはおそらくシングルクォートの記述そのものを回避する方法であり、本記事の事例でも有効という点で同様の事例に見える。
Amazon RDS(MySQL)でTimezoneを変更する | DevelopersIO
init_connectパラメータに直接コマンドを投入するとうまく動かないので、ストアドプロシージャを定義し、CALL文で呼び出すようにする
やはりこちらでも直接のコマンド記入ではうまく動かないとの記述あり。
本来、MySQL自体の仕様としては問題ないはずなので、AWS RDS固有の問題の可能性が高い。
[技術ブログvol.39] RDSのタイムゾーンについて - DENET 技術ブログ
こちらでも同様にストアドプロシージャーを使っている。
取るべき対処の案
概ね2つある。
1. ストアドプロシージャーを使う
上記の調査でも書かれていた方法。
シングルクォートのエスケープにバグがあるのなら、シングルクォートを書かなくて良いストアドプロシージャーとその呼び出しにしてしまえばよいというかなり強引な方法。
たしかに解決できるが、ストアドプロシージャーという管理対象リソースが1つ増える点がネック。
2. init_connectをやめる
[新機能]Amazon RDSで日本時間が使用可能になりました！ | DevelopersIO
など多数の記事で書かれている通り2025年時点でパラメータグループから直接time_zoneを設定できるようになった。
そのため、 init_connect の利用目的が time_zone の設定であれば、シンプルにパラメータグループ上での time_zone 設定へ移行すれば良い。
2025/08/12追記
AWSサポートへの問い合わせから、次の回答が得られた。
- 上で記述した値を
init_connectに設定すると、- DBクラスターパラメータグループ、DBパラメータグループいずれを変更しても当該エラーが発生する - DBインスタンスを再起動するとエラーは解消される
- シングルクォーテーションの代わりにダブルクォーテーションを使用すれば、起動中にパラメータを編集してもエラーは発生しない
- この問題は、DBインスタンス起動中にDynamicパラメータへの変更を反映する動作と、再起動時にパラメータグループを反映する動作が異なるため
Discussion