読者です 読者をやめる 読者になる 読者になる

reizist's blog

ウェブ

web+db vol97のMySQL運用最前線を読んだ

前職でソシャゲ開発/運用をしていた関係でちょろちょろ触る程度のなんちゃってDBA/インフラーなのでそこまで深い知識は持っていないけど、 最低限時代についていく必要はあるので読んだ。 なんか間違ってること僕が書いてたら教えてください。

目次

について書かれている。

MySQLの現在

今現在の最新である5.7に至るまでのMySQL史が紹介されている。 次期リリースの「MySQL 8.0」はしばらくでなさそうだし、5.6はリリースされてだいぶ経っている。 5.7に移行したほうがいいよね、という熱感を高める文章が記載されている。

innoDB徹底活用

  • innodbの解説(デフォルトで有効なストレージエンジンだし他のストレージエンジンにする必要ないとか)
  • mysqlのパラメータの中でも最も重要な innodb_buffer_pool_size がオンラインで変更可能になったよ
  • ファイルフォーマット/行フォーマットの変更
  • 日本語の全文検索が可能になったよ

あたりが言及されている。

innodb_buffer_pool_size の動的変更、 バッファプールを増やす場合 全てのアクセスが禁止されるのでパフォーマンス劣化が懸念され、 バッファプールを減らす場合 チャンク単位のページ開放でロックを取得する場合他のトランザクションに影響する等でパフォーマンス劣化が懸念される

あたりが気をつける点としてあって、短期的なパフォーマンス劣化で中長期のパフォーマンスを向上させるものだという認識。 オフラインで対応する場合mysqlプロセスを停止させる必要があるが、その場合buffer_pool_sizeが大きければ大きいほどflushに時間がかかるのでダウンタイムが伸びる可能性があって、 どうしてもダウンタイム作れないものにはアクセス少ない時間帯にオンラインコマンド叩いとく感じになると思う。

とはいえauroraなどマネージド・サービスならデフォルトでインスタンスの ¾ のメモリ量になるよう設定されているようで足らなければインスタンス変更で対応しそうだし、 自前でmysql管理するレベルのチームなら最初に innodb_buffer_pool_size を適切に設定しておくだろうし、 よっぽどリリース時から想定されていないアクセスが来たみたいな状況じゃないと使わなそう?(素人意見)

フォーマットのデフォルトが変更されたあたりは多分メリットしかなくて、

  • デフォルトがAnteropeからBarracudaになった件は、普通のアプリケーションエンジニアが意識するのって絵文字対応などのときだと思っていて、これにより各々の my.cnfinnodb_file_format = Barracuda を書く必要がなくなった
    • 関連して innodb_large_prefix も5.7デフォルトで1になっており絵文字対応がデフォルトで対応されている?
  • デフォルト行フォーマット innodb_default_row_formatdynamic になった件は、ちょっとまだ肌感としてはよくわかってなくて、 圧縮される(のでストレージ負荷が下がる)代わりにCPU負荷が上がるCompact( or Compressed)を採用するか否かの話になると思うんだけど、CPU負荷というのがどれくらいのものなのかわからないのと、もはや近頃はストレージ価格というのはどんどん下がっているのでリスク犯すなら思考停止して dynamic でいいじゃん、と思ってるんだけどどうなんでしょう

日本語の全文検索に関しては結構読み飛ばした(mysql内で形態素解析等するケースが思いつかなかった)

柔軟で安全なレプリケーション

この章がもう結構衝撃的で、正直前職では master_log_file , master_log_pos めっちゃ駆使してたし、 set global sql_slave_skip_counter=1 も手動で叩いていたので GTIDとクラッシュセーフスレーブすげーーという感想になった。

マルチソースレプリケーションに関しては、チャンネル単位で複数スレッドに並列化してスレイブを構築するほどスレイブ遅延が発生する状況を知らないので読み込んでみたけどあまり直近で使う未来は見えなかった。 むしろ

ただしチャンネルはお互いに独立しているため、チャ ンネル間の整合性は保証されません。すなわち、チャン ネル❶のマスタが更新されたあとにチャンネル❷のマス タが更新されたとしても、スレーブ上ではどちらが先に 更新されるか保証することはできない

等のコメントを読んで腰が引けたというかあまり使いたくない印象を持ってしまった。

設定における留意点と分析機能の利用

この章も「フムフム」と言って読んだ。SQLモードの変更やログのスタンプ形式の変更は読んで把握しておいてよかったなと思った。 とはいえ個人的にはDBは常にUTCでもいいんじゃないかとも思っているので(実際に前職はそういう運用をしていた)、頭にindexを作るに留める。

所感

どんどん最新機能出てきてそれを最前線で追っている方々、すげえみたいな小学生のような感想。 今までローカルのmysql5.6だったけど、手元の開発が落ち着いたタイミングで brew install mysql で5.7にあげよう。(今は brew install mysql56

サーバーエンジニアで少しでもDB(mysql)触る人は是非読みましょう

WEB+DB PRESS Vol.97

WEB+DB PRESS Vol.97

(pdfはgihyoから買える)

参考

www.slideshare.net

www.slideshare.net

nippondanji.blogspot.jp

yakst.com

yakst.com

Amazon Auroraを始めるためのパラメータ資料 | 外道父の匠

MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.7 InnoDB 圧縮テーブル