私は如何にして詳解 MySQL 5.7を執筆するに至ったか

先日・・・といっても既に先月のことになるのだが、詳解MySQL 5.7　出版記念交流会には多くの方に来て頂いた。台風にも関わらず、とても多くの（60名ほど）の方に足を運んで頂いたのは、本当に嬉しかった。ここで改めてお礼申し上げる。

ありがとうございました！！

さて、交流会のときに使用したスライドを公開したので、興味のある方は見ていただきたい。

私は如何にして詳解 MySQL 5.7を執筆するに至ったか from Mikiya Okuno

少しスライドを補足すると、MySQL 5.7の新機能にスポットを当てた本というのは、やはりニッチだと思う。しかし、MySQL 5.7を使いこなす上で、このようにまとまった情報は必須・・・というか、無いと話にならないだろうと思っていたので、出版するに至ったことは非常にありがたい。よくこんな企画をよく通してくれたなと・・・。G社さんの反応は、至って普通だったと思う。とはいえ、今後もMySQLを使っていこうと考えている人には必ず役に立つ内容だと信じているので、まだ読んでいないという人は、ぜひ目を通して欲しい。

さて、今回の書籍は「詳解MySQL 5.7」というタイトルになっているのだが、今後もMySQLのバージョンが上がるたびに追随するのか？と聞かれると、それは厳しいと言わざるを得ない。先日、MySQL 8.0.0 DMRについての記事を書いたが、それにあわせて詳解MySQL 8.0を書くのか？ということになると、非常に悩ましい。MySQL 8.0の新機能は、今のところ数としては本一冊を書くほどのボリュームではないからだ。アーキテクチャなどの部分にフォーカスした本なら書けるかも知れないが、他にも予定があるのでちょっと時間的に厳しい。

MySQL 8.0でも様々な魅力的な改良が入っているものの、MySQL 5.7も十分魅力的な機能が満載となっている。なので、もし今新しくMySQLを採用したプロジェクトを始める場合には、ぜひMySQL 5.7の使用を検討して欲しいと思う。

交流会でも話をしたのだが、MySQL 5.7を使う上で個人的に一番注意したい点は、sync_binlog=1がデフォルトになったという点だ。バイナリログへのグループコミットがしっかりしたので、多くの場合にはこの設定でも困らない。ただし、スレーブ上でバイナリログを有効化し、log_slave_updates=1でレプリケーションによる更新も記録する場合には注意が必要だ。この設定は、GTIDを使ってスレーブを昇格する場合に多く使われるのだが、レプリケーション（＝SQLスレッド）による更新をいちいちsync_binlogでディスクに同期すると、とても遅くなってしまう。もし、MySQL 5.7にするとレプリケーションが遅れるようになったという現象に遭遇した場合には、sync_binlog=1による影響を疑うべきである。

対策としては、マルチスレッドスレーブ（MTS）の利用を薦めたい。MTSならば、スレーブ側でも同様にバイナリログへの書き込みが、グループコミットで行われるからだ。少なくともマスターから遅れることはなくなるだろう。スレッド数は多め（100など）にしておいたほうがパフォーマンスが向上する。ちなみに、sync_binlog=0の対策はオススメしない。スレーブがクラッシュしたときにバイナリログが欠損してしまうので、スレーブを昇格に利用するという目的が毀損されてしまうからだ。

そんなわけで、MySQLをお使いの皆さんには、詳解MySQL 5.7を読んで、楽しいMySQLライフを満喫していただきたいと思う。