概要 最近、Aurora2(MySQL5.7)だったクラスターをAurora3(MySQL8.0)にアップグレードしたところ、特定のクエリだけが失敗するという事象があった。 ClowdWatchLogsに出力していたerrorログには /tmp/xxx is full! と出力されていた。 Aurora2(MySQL5.7)の時代にはなかったことだったので、Aurora3(MySQL8.0)によるものであることはわかり、それが新しく採用されたTempTableストレージエンジンによるものであることがわかった。 TempTableストレージエンジンとはどういったものか、Aurora3の仕様もあわせて色々わかったので記録をしておこうと思います。 最初に結論 Aurora2からAurora3にアップグレードする際には temptable_max_ram と temptable_max_mmap の値を必ず確認して、必要に応じて調整したほうが良い。 TempTableストレージエンジンとは 詳細な説明は下記を参照してもらうとして、ざっくり説明すると内部一時テーブルを使うようなクエリを実行した場合に、MySQL5.7のときにつかっていたInnoDBテーブルではなくメモリを利用したストレージエンジンとなり、5.7のときよりも効率的にクエリを処理することができるようになったストレージエンジンのことを指す。 https://dev.mysql.com/doc/refman/8.0/ja/internal-temporary-tables.html TempTableストレージエンジンでは temptable_max_ram を上限としてオンメモリで処理されて、それを超えると、temptable_max_mmap を上限として、mmap()システムコールにより、ローカルストレージにファイルを作成して、仮想メモリにマッピングを行う。 ページサイズ単位（Linuxではデフォルト4KiB)でメモリ上にデータがロードされるので、InnoDBテーブルに変換される場合よりも、効率的（可変長）で高速に処理される。 では、temptable_max_mmap を超えたサイズのデータをクエリするような場合はどのような挙動になるか。 MySQL8.0の挙動 Aurora3に関わらず、MySQL8.0の仕様では、temptable_max_mmap を超えると、InnoDBテーブルに書き込むようになる。 つまり、遅くはなるけど処理は継続される。 Aurora3の挙動 Aurora3ではどうなるかというと、ライターとリーダーで挙動が異なる。 ライターはMySQL8のデフォルトの挙動と同じになるが、リーダーの場合は temptable_max_mmap の値を超えると /tmp/xxx is full!とエラーが出力されてクエリが失敗する。 temptable_max_ram と temptable_max_mmap はデフォルト1GiBなので、合計2GiBを超えるようなクエリは失敗して終了してしまう。 原因についてはAWSサポートにも確認してわかっているが、まずAuroraは共有ストレージを採用しており、 そして、リーダーインスタンスは共有ストレージを参照は可能だが、書き込みはできない。 内部一時テーブルを作成するのにあたり、ライターは問題にならないがリーダーインスタンスで、MySQL5.7のときは共有ストレージではなく、ローカルストレージにMyISAMとして書き込みを行う仕様だった。 リーダーインスタンスでは、オンディスク一時テーブルはローカルストレージを使用する MyISAM ストレージエンジンを使用します。これは、読み取り専用インスタンスでは Aurora クラスターボリュームにデータを保存できないためです。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.CompareMySQL57.html MySQL8.0.16以降、内部一時テーブルのストレージエンジンを指定していた internal_tmp_disk_storage_engine が廃止されて、デフォルト InnoDB となった。 Auroraでもこの仕様に則り、Aurora2では internal_tmp_disk_storage_engine が適用され、Aurora3では internal_tmp_mem_storage_engineが適用されるようになった。 パラメータグループをみても、Aurora2のときにあった internal_tmp_disk_storage_engine は Aurora3では見当たらず、かわりに internal_tmp_mem_storage_engine のみが存在する。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html internal_tmp_mem_storage_engine はメモリを使った内部一時テーブルの処理のみとなり、デフォルトが TempTable で、MEMORY にも変更は可能である。

– AWSのRDS的なデータベースサービス – 2015/10/28日現在、使用可能なデータベースはMySQL5.5と5.6のみ。PostgreSQLは使用できない。 – IPv4ベースで接続するには、IPv4（有料$0.01/h）の申請が必要。 ※デフォルトでIPv6は付与されている。 – IPv4はグローバルIPアドレスなのでセキュリティーに注意する。 – Compute EngineのVMからIPv4で接続した場合、tracerouteする限りはGoogle内部で完結しているようなのでセキュリティー上問題ないと思われる。 – IPv4で接続するには、インスタンスのグローバルIPも固定IPアドレスの方が良い？※VMに指定しているホスト名では制限できないため。 – 時間単位の従量課金か、日にち単位の課金かを選択できる。常時稼働させるにはパッケージ（日にち単位）の方が安価。 – レプリカはリードレプリカとして使用できるようだけど、マスターを一度バックアップする必要がある。 バックアップからリードレプリカが作成可能。 – 普通にmysqlコマンドで接続して、SQLを実行可能。 以上。

詳解MySQL 5.7 止まらぬ進化に乗り遅れないためのテクニカルガイド 概要 他にも書いている人たくさんいるけど、別名でリストアとかってあんまり書かれていないので、テストして残しておこうと思います。 テストケース１：mysqldumpで特定のデータベースをバックアップして、別名でリストアしてみる。 まず、testdb01というデータベースを作る。 そして、t_nameというテーブルにid4までのデータをインサートする。 その後、下記コマンドでtestdb01だけdumpを取得します。 # mysqldump -u root -p testdb01 > testdb01.sql つぎに、testdb02という新しい空のデータベースを作成し、testdb01を更新してみる。 その後、 # mysql -u root -p testdb02 < testdb01.sql その結果が以下の通りです。 mysql> use testdb01; mysql> select * from t_name; +------+-------+ | id | name | +------+-------+ | 1 | hoge1 | | 2 | hoge1 | | 3 | hoge1 | | 4 | hoge1 | | 5 | hoge2 | +------+-------+ 5 rows in set (0.

3/1の土曜日に、オープンソースカンファレンス2014に行ってきました。 開催場所が多摩市の明星大学（めいせい）で、とても遠かったために時間ギリギリでした。 でも、MySQL Clusterの勉強会でも講演されてた方のMySQLのチューニングの話とか、今旬なオープンソースを色々知ることができてよかったですね。 是非来年も行きたいです。 ただ、MicrosoftさんもさくらインターネットさんもGMOさんも萌え萌え系のキャラ押しなのが気になりましたｗ 個人的には多摩モノレールのエヴァ感ががすごい感動したので、それを見られただけでも良かったですｗ

■MariaDB勉強会メモ：2014/02/18　場所：DeNA＠渋谷ヒカリエ [Montyさんの講演] ・2009年から開発スタート ・feedback_pluginはデフォルトで無効→有効にしてほしい。 ・20%くらいが10.0を利用している ・MySQLからのMariaDBへの移行について ・ProgressReportで実行の進捗が確認可能 ・マスタースレーブ環境でMySQLと比べてMariaDB環境の方が高速 ・optimizer features ・Kristian Nielsen’s blogを見ると良い ・InnoDBが使える ・Performance Schemaはデフォルトでオフにするほうを推奨 ・一つのスレーブが複数のマスターを持つことが可能。 ・TokuDB ・Olivier Bertrand ・WikipediaはMariaDB　10-15%くらい高速化している ・2013 4月　GoogleはMariaDBを使用する ・2013 6月　RHELも導入 ・MariaDBへ移行する理由→MySQLの開発チームがMariaDBの開発をしている ・たくさんのfeaturesがあるからMySQLを使用する理由は無い ・マルチマスター　4-5倍 [斯波さんの講演] Spider ・DBシャーディング Mroongaストレージエンジン ・全文検索、位置情報検索 ・検索中でも高速に更新可能 MariaDB10.0 ・RC版、もうすぐ安定版 [Colin Charlesさんの講演] ・SkySQLのチーフエバンジェリスト ・GoogleのMySQLからMariaDBへの移行について ・kakao talkはMariaDBへ移行 ・WordPressはMySQL、MariaDBを推奨 ・slash gear blog VPS使用しているが年間$12000削減できた ・OLX　広告　40ミリオンページビュー [堤井さんの講演] ・MySQL5.5とMariaDB5.5との互換性はある ・MySQL5.5とMariaDB5.6との互換性は低い ・MySQLからMariaDBへの移行はスムーズにできるが、MariaDBからMySQLへ戻すのは難しいのではないかと思われる ・OSS ・速いらしい。 ・オプティマイザが優秀。 ・スレッドプール。 ・Oracle社１社のコントロールでない。 ・開発の方向性が見える。 ・コミュニティからのフィードバック ・Buildも楽しい。（MacOS X)　–> Mac Portsでやるのが推奨。