ネタ的には 発掘するたび書き溜めてきたブログ記事 から 笑いが取れそうなものを 大事そうなもののみをピックアップして紹介した感じです。 知らないと致命傷、でも知ってれば予防できる（はず） MySQL 5.7で不幸になる人が1人でも少なくなってくれることを願っています。 さて、今年のYAPC::Asiaはメイントラックもトークを応募していたのですが見事に落選したので、1日目は完全にリラックスして過ごしました。LTの採否、当日になるまでわかんないのか大変だなーとか、他人事だったんですが、 1日目のLT見るじゃないですか。 面白いじゃないですか。 俺もしゃべりたくなるじゃないですか。 なったんですよ！！１ が、翌朝になってLTの応募ページをたどってみると

TL;DR MySQL 5.7.8には、mysqlpumpなるmysqldumpの後継バックアップクライアントが同梱されている。インデックスの遅延ロードや進捗の出力、パラレルでのダンプなど魅力的な拡張機能が入っている。 ただし、mysqlpumpの方は「全テーブルがInnoDB」「master_info_repository= TABLE」「relay_log_info_repository= TABLE」「gtid_mode= ONの場合にはMySQL 5.7.5以降であること(OFFの場合はこの制約は入らない)」「パラレルでバックアップする場合は更新を自分で止めておかなくてはならない」であることを前提に作られているため、それを満たさない場合は mysql40dump のようなラッパーを何かしら作る必要があります（レプリケーションの情報はテーブルに保存されていてそれはダンプに含まれるから

Changes in MySQL 5.7.44 (2023-10-25, General Availability)

こんにちは。ソリューションアーキテクトの下佐粉（しもさこ）で す。 先日(7/31)のお昼に緊急開催したAWS Black Belt Tech Webinar では RDSの新しいデータベースエンジン Amazon Auroraの解説を行いました。 これまでプレビューだったAuroraが一般公開（GA）された直後とあって、告知からあまり日にちが無かったにも関わらず非常に沢山の方にご参加いただきました。スライド資料を以下に公開しますので、見逃した方もぜひ参考になさってください。 Q&Aも非常に活発でした。時間の範囲お答えさせていただきましたが、それでも答えきれなかったご質問も多かったので、このエントリの後半にQ&Aをまとめています。こちらもぜひご参照ください。 次回のBlackbeltは8/5(水)18時から、AWSのNoSQL型データベースサービスであるDynamoDBについて解説します。

Description: Historically, the suggested way to run MySQL on NUMA machines has been to run with "numactl --interleave=all" so that things like the InnoDB buffer pool are spread across all NUMA nodes. However, for thread local allocations, it makes little sense to interleave across NUMA nodes as there is only one thread per connection. It would make more sense to allocate this memory node local. Re

一応、立場的には第三者に戻った(MySQL/InnoDBの性能追求が仕事ではない)ので、忘れられない暗い過去にも触れてみようと思います。 未だに騙されている人が多いみたいなので、MySQL/InnoDBの名誉のために書き残さなければなりません。何度でも言いますが、性能比較は自分の目的とする処理をちゃんと比較しないとだめです。そうでなくては、騙されて本当は悪い性能のものを掴まされることになります。 DBT-2と言う(TPC-Cをベースにした)ベンチマークがありますが、数多のRDBMS(商用/OSS双方)に対して独自にTPC-Cベンチマークを実装・チューニングして比較した経験のある私から見て、怪しい結果しか出ないので、長年、基本無視のスタンスを取っています。 が、３年前にあろうことかMySQLの性能QAがDBT-2(nonsp:mysql)を利用していて、とある性能FIXに対して問題を指摘して

MySQL5.6ではinnodb_file_per_tableがDefaultでテーブル毎にテーブルスペース（ファイル）が作成されますが、MySQL5.7.6 DMRからは、CREATE TABLESPACEステートメントによって、 複数テーブルで共有出来るテーブルスペースが作成出来るようになりました。また、Defaultデータディレクトリーとは別のパスにテーブルスペースを作成出来るので、 負荷が高いテーブルなどをSSDなどに配置するなど柔軟に対応することが可能になります。Oracle（テーブルスペース）やMS SQL（ファイルグループ）に関しては、 以前から同様に指定出来ますが、オープンソースデータベースのMySQLは5.7になり、更にそれらの商用データベースと同様の機能も利用出来る汎用性を備えたデータベースになってきました。 MySQL5.7はまだ5.7.7RCですが、更に新たな機能が

気づかなかったけど、これ5.7.2から入ってたのか。 フツーに扱うDATETIME型(やその親戚)は time_zone 変数に支配されるけど、ログに出力される時刻は log_timestamps 変数に支配される。 この変数の取りうる値は UTC または SYSTEM で、暗黙のデフォルトはUTC 。。 mysql57> SELECT @@version; +---------------+ | @@version | +---------------+ | 5.7.5-m15-log | +---------------+ 1 row in set (0.00 sec) mysql57> SHOW GLOBAL VARIABLES LIKE '%time_zone'; -- タイムゾーンはフツーにJST +------------------+--------+ | Variable_

先日、「InnoDB Deep Talk #2 (仮)」というイベントでお話ししてきました。 「事前情報は講演者の名前のみ(内容未定)」という、振り返ってみると異常な状況にも関わらずお集まりいただきありがとうございました。 今回は、前回とは違って少しだけ公開を意識して作ったあったので公開してみます。 これで手持ちのネタは出し尽くしたので、また暫くブログの更新は無いかもしれませんがご容赦を。。。

To explain these changes in more details: The slow query log remains disabled by default, but when enabled our hope is that we can make it immediately useful. A query exceeding 2 seconds will now be considered slow, and since queries that do not use indexes have the highest chance of causing future problems, they will also be logged unless they examine fewer than 1000 rows. The number of 1000 was

ご無沙汰しています。 作ってから公開されるまでのタイムラグで思い出してまで書く余裕が無くて暫く更新をお休みしていました…。 その代わり、MySQL-5.7では細かい修正も含めてある程度思っていた通りのInnoDBの改善ができたのではないかと思います。 で、本題。唐突ですが、先月末でInnoDBチームを辞しました。理由は色々ありますが、ネガティブな理由は一個もありません。願わくば、体がもう一つ欲しいくらいです。 もう一度、自分のユーザー視点を現在のものにアップデートするべく、一般ユーザーに戻ります。その方がInnoDBを更にフットワーク良く改善できると考えたからです。とはいえ、今の立場で大きな案件があるまで、新しい領域には踏み込めないでしょう。暫くはInnoDBチーム在職中に行った変更で、リリース済みのものについて解説していきます。 その後、実用的な技術情報やツール（もしも作ったら）を共有し

Morgan Tocker というMySQLの中の人(MySQL Community Teamのひと)が 自身のブログ で、MySQL 5.7のデフォルト値の変更に関する意見を募集していたりする。 Proposed MySQL 5.7 defaults. Please send feedback! http://t.co/Uq6c7STXBE — morgo (@morgo) 2015, 1月 23 Proposal to change Replication and InnoDB Settings in MySQL 5.7 http://t.co/gr3AwwmoEv — morgo (@morgo) 2015, 1月 14 ので、ちょっと解説してみます。わたしが勝手に思っていることを述べているだけなので、詳しくは原文をあたってください。 まずはこっち。 Proposal to chan

We are considering these changes as a package, for the following reasons: Enabling row based binary logging is the safer option for new applications. It allows all types and combinations of statements to be replicated safely (deterministically), and makes slaves more crash-resilient when using features such as temporary tables. InnoDB requires row-based replication in order to provide the READ-COM