こんな事があります
Aurora MYSQL2から3へ移行したら、今までは動いていた、大きなテーブルの全件取得クエリがエラーで失敗するようになってしまった。なぜだ？？
2023-05-23T08:54:57.927471Z 100299 [ERROR] [MY-013132] [Server] The table '/rdsdbdata/tmp/#sql3612_187cb_0' is full! (handler.cc:4380)
今日中に直さないとデータ連係に支障が出てしまう...。
これで解決！
temptable_max_mmapとtemptable_max_ramの値を調整します。
| 変数名 | 意味 | デフォルト |
|---|---|---|
| temptable_max_mmap | 一時テーブルをストレージ上に作成する最大値 | 1GiB |
| temptable_max_ram | 一時テーブルをメモリー上に作成する最大値 | 1GiB |
設定例
この例では、2つの変数を併用することで22GiBまでの一時テーブルを作成することができるようになります。2GiBまでの一時テーブルであればメモリー上に作成されるため、クエリの実行速度低下を緩和できます。
20GiBまでの一時テーブルをストレージに作成できるようにする場合
temptable_max_mmap = 21474836480
インスタンスクラス毎に一時ストレージのサイズが異なるので、仕様を確認の上、設定した方が良いです。
Amazon Aurora MySQL のパフォーマンスとスケーリングの管理 - Amazon Aurora
2GiBまでの一時テーブルをメモリーに作成できるようにする場合
temptable_max_ram = 2147483648
インスタンスクラス毎にメモリーのサイズが異なるので、仕様を確認の上、設定した方が良いです。
Amazon RDS インスタンスタイプ | AWS
そもそも原因は？
この問題は、MySQL8.0から変更になった一時テーブルの仕様と、Aurora MySQL3のリーダーインスタンスの仕様がからんで発生します。リーダーインスタンスは、共有クラスター・ボリュームに書き込みができないAurora MySQLの仕様が原因です。
Aurora MySQL3（MySQL8.0）から、TempTableストレージエンジンが一時テーブルのデフォルトになりました。TempTableは一時テーブルをメモリー上に作成しますが、サイズが設定値を超えた場合、ストレージにオーバーフローしたデータを保存します。
このオーバーフローの処理方法が、ライターインスタンスとリーダーインスタンスで異なっています。
ライターのオーバーフロー処理
temptable_max_ramまでメモリーに保存
↓
tempable_max_mmapまでローカルストレージに保存
↓
共有クラスター・ボリュームに保存
↓
もう書き込み先がないので、エラーを返す
リーダーのオーバーフロー処理
temptable_max_ramまでメモリーに保存
↓
tempable_max_mmapまでローカルストレージに保存
↓
もう書き込み先がないので、エラーを返す
リーダーインスタンスは、共有クラスター・ボリュームに書き込みができない仕様なので、ローカルストレージがオーバーフローした時点で冒頭のエラーが発生します。そして、temptable_max_ramとtempable_max_mmapのデフォルトは1GiBなので、容易に上限に達してしまいます。
2023-05-23T08:54:57.927471Z 100299 [ERROR] [MY-013132] [Server] The table '/rdsdbdata/tmp/#sql3612_187cb_0' is full! (handler.cc:4380)
環境情報
- Aurora MySQL 3.02.2（MySQL 8.0.23）