db tech showcase 2013 TokyoのMySQLセッション

yoku0825 @yoku0825

「p_sはまだ使ってない。性能劣化が深刻なので、分析は他の手段でやっている」 #dbts2013 #mysql_jp

yoku0825 @yoku0825

「本家も認識していて、だんだんマシになってきているらしい」 #dbts2013 #mysql_jp

yoku0825 @yoku0825

「GTID、深刻なバグあったけど、FB的にはそろそろ本番環境に投入する予定」 #dbts2013 #mysql_jp

Tadashi Yamashita @tadayima_jp

松信さんのセッションもてんこ盛り。アリーナ（床）なら座れるかも。 #dbts2013 #mysql_jp

ITOH Hiroyuki @i_rethi

まだ使ってない起動、p_s(性能低下5〜30%ダウン)、GTIDはバグが多くて… 、MTS(Multi-Threaded slave)はGTID無しではトラブルシューティングが困難、オンラインDDLや全文検索など #dbts2013 #mysql_jp

yoku0825 @yoku0825

「MTS、GTIDがないとトラブルシュートが困難。GTIDがまだ投入されてないのでMTSも入れてない」 #dbts2013 #mysql_jp

ITOH Hiroyuki @i_rethi

オフィシャルにないけどFacebookで必要なもの。非同期MySQLクライアントAPI、高速なフルテーブルスキャン、より高速なレプリケーション、より低コストなSemi-syncレプリケーション #dbts2013 #mysql_jp

yoku0825 @yoku0825

「FB拡張。非同期MySQLクライアントAPI、高速テーブルスキャン、レプリケーションの高速化、低コストSemi-Sync、SSD向け最適化、その他。。」 #dbts2013 #mysql_jp

ITOH Hiroyuki @i_rethi

SSD/Flash向けに適した動作->書き込み量の軽減、より効率的な圧縮など #dbts2013 #mysql_jp

yoku0825 @yoku0825

「ロスレスSemi-sync(5.7と同等の機能) を5.6にバックポート。I/Oスレッドの転送速度を制御可能にしたり、バイナリーログの読み込みI/O単位を変えたり」 #dbts2013 #mysql_jp

ITOH Hiroyuki @i_rethi

レプリケーションの部分について。Semi-Sync mysqlbinlog、Enhanced(Loss-Less)Semi-sync(5.7と同等)、I/Oスレッドの安定化と高速化など #dbts2013 #mysql_jp

Neofact @NeofactJ

MySQL5.6 オフィシャルには無いがFacebookで必要なもの、としてFlash用に適した動作として「書き込み量の軽減」とあるのがAtomicWriteの事かな？ #dbts2013 #MySQL_jp

yoku0825 @yoku0825

「5.6でmysqlbinlogがsemi-syncをサポートした。コイツを同じDCに2つ以上ぶら下げてやって、バイナリーログをため込みつつSemi-syncを保証する。リソースも削減」 #dbts2013 #mysql_jp

yoku0825 @yoku0825

これウチでもやりたい。 #dbts2013 #mysql_jp

ITOH Hiroyuki @i_rethi

semisync mysqlbinlogを使うことでリソース消費を大きく軽減出来る。リレーログが無いので書き込み量が半分になるから等 #dbts2013 #mysql_jp

yoku0825 @yoku0825

「Binlog Readerが多数いる場合、コミット性能が劣化していくので、内部的なmutexをSemisyncの時しか取らないように書き換えてみた。100commit/secから27k commit/secになった」 #dbts2013 #mysql_jp

yoku0825 @yoku0825

「I/Oスレッドが帯域を占有すると他のクライアントに影響を与えてしまう。tcp_rmemとかで制限できるけど、mysqldの中で設定できるように」 #dbts2013 #mysql_jp

ITOH Hiroyuki @i_rethi

I/Oスレッドの安定化と高速化。マスター>スレーブの転送スピードをパラメータで制御可能。ネットワーク帯域を占有すると他のクライアントに影響する。少なすぎると遅延を招く。net.ipv4.tcp_[rw]memで制御可能だが、全プロセスに影響 #dbts2013 #mysql_jp

yoku0825 @yoku0825

「バイナリーログの読み込み単位は8KBになってるけど、古いファイルはページキャッシュにも載ってないし非効率なので1MBに変更」 #dbts2013 #mysql_jp

yoku0825 @yoku0825

「基本はmysqldump、オンラインでスキーマ変更の時はSELECT INTO OUTFILEなのでフルテーブルスキャンはFBでもユースケースとしてある」 #dbts2013 #mysql_jp

yoku0825 @yoku0825

「InnoDBは断片化するとランダムリードになってすこぶる遅くなるので、まずインデックスのブランチを片っ端から読んでページ番号の順番に読んでバッファプールをあっためておく」 #dbts2013 #mysql_jp

yoku0825 @yoku0825

「HDD上でのフルテーブルスキャンだと、10倍くらいLRAで速くなった」 #dbts2013 #mysql_jp

ITOH Hiroyuki @i_rethi

Logical Readaheadのベンチ。10GB通常10分が１分ちょいに #dbts2013 #mysql_jp

Neofact @NeofactJ

Innodbプラグイン周りのコメントで、「DoubleWriteBufferを減らす」とさらりとコメントしていたのでAtomicWrite事で間違いなさそう。 #dbts2013 #mysql_jp

Neofact @NeofactJ

InnoDBログファイルへのRead-Modify-Write回避には、書き込み単位を4KB単位に固定しReadを減らす。#dbts2013 #MySQL_jp