Facebook at MySQL5.6で聞いてきた話のメモ
こんにちは。smallpalaceです。
こないだ11/14とかにやってたdb tec showcaseであったセミナーのうち、
Facebookの松信さんが話された内容の個人的な備忘録です。
詳しくはそのうち松信さんのスライドが公開される気がするのでそちらを見てください。
色々抜けてるところも多いと思うので。
-----------------
規模間が大きいからコストメリットがあるのでMySQLEnginneeringチームがある
魔改造して使ってる
5.6をつかう理由
重要な機能が本体にマージされている
独自に管理しなければならないパッチの量が抑えられる
接続数が多い場合に高速
リクエストをより安定して裁ける
ストール(高負荷時にかたまるような状態になること)しにくい
InnnoDBConpressionの強化
性能の落ち方が緩やかに（5.1の改造がマージされた）
リカバリとフェイルオーバがより簡素に
スレーブ障害→再起動してレプリケーションを再開すればOK
テーブル管理になったため
GTIDによって、マスタのフェイルオーバー手順が簡素に
MHAよりリレーログのあるなしの制約がない
Semisyncでデータ消失の確率がない
まだつかってない機能
Perfomansceschema
パフォーマンスのダウンが５～３０％
性能分析はほかの手段で
GTID
いくつかの深刻なバグや機能不足があったもののようやく実用可能なレベルに
まもなく本願環境に投入する予定
MTS（マルチスレッドスレーブ）
GTIDなしではトラブルシューティングが極めて困難
オフィシャルにはないがFacebookで必要なもの
高速なフルテーブルスキャン
より低コストなSemi-Synchronousレプリケーション
ほかメモり切れず
Semisinc mysqlbinlog
I/Oスレッドの安定化と高速化
バイナリログの読み込み時にグローバルロックを持たないように
高速プリフェッチ
SemiSync mysqlbinlog
同じマスタにバイナリログだけスレーブの代わりに持たせるもの。コスト面から
Semisyncレプリケーションの性能改善
BinlogReaderが多数いる場合にコミット性能が指数関数的に悪化する
pluginlog?のせい
I/Oスレッドの安定化と高速化
マスタスレーブの
転送スピードをパラメータで制御可能に
バイナリログの読み取りサイズを8kbから1mbにとか
LogicalReadAhead高速なフルテーブルスキャン
バックアップやオンラインスキーマ変更など
テーブルが断片化するとテーブルスキャンが遅くなる
遠いページ同士を連続して読むとランダムリードになるので
先読みしてメモリに載せてあたためておくと早いというやつ
10GBのテーブルで1分で読める
InnodbログファイルへのReadModifyWrite回避
InnoDBはInnoDBログファイルに対して512バイト単位で書き込む
OSのI/O単位は4KB
対象ページがファイルシステム
InnDBログファイルとバイナリログのuncache
DuoublewriteBufferへの書き込み量削減
書き込み量2倍だとSSDにやさしくない
ページIDだけ書く。壊れたら再構築
その他
super_read_only
一部のシステム変数を変更したときにログに出す
start transaction with consistent innodb snapshot
flush tables with read lockしたくない
段階的アプローチ
初期段階では主要な機能の多くはつかわずにアップグレード
限定的な機能のみ有効化
本番環境と同じ条件化で検証
5.6アップグレード時に起きた主な問題
SetOptionがエラーになる
古いバージョンのConnector/Jを裏で実行しているのでつかえなくなる
Drop/Alter Tableが遅くなった
→高速なパッチが5.5から5.6へ繁栄されてなかったが今は解決済み
PersistenntOptimizerStatistics
InnoDBの統計情報がテーブルに保存されるようになった
時々ストールが起きる
統計情報のアップデータの処理が無関係のユーザスレッドを待たすことがある
いくつかのクエリでオプティマイザが誤動作
eq_range_index_dive_limitシステム変数
INなどのイコール条件が多数ある場合、統計情報を読みに行かなくなった
defaultは10
IN予想スキャン件数は11%レコード数
レンジパーティションの実行計画の変化
マッチしないパーティションがたくさんある場合、予想スキャン件数を過剰に低く見積もってしまう不具合
bugid70265
GTIDの有効化作業が困難
ランタイムで変更できないためローリングアップグレードできない
マスタ・スレーブを同時にupgradeしないとだめ
FB版ではマスタがOFFでもスレーブONを可能に改造した
マスタですべてのバイナリログをスキャンするという不具合がある
GTIDでクラッシュセーフスレーブが機能しなくなる
スレーブが壊れてもあとから再起動するだけでrepを再開継続してくれる機能
必要なパラメータはrelay_log_info_repository=TABLEと、、
マスタのクラッシュリカバリ後にスレーブが全停止することがある
5.5と5.6でスレーブに転送するしくみがことなる。fsyncを待つかまたないかの差
スレーブでのxtrabackpupはデッドロックを招くことがある
Flushtableswithreadlock+show slavestatusでデッドロックを引き起こすことがある
２つのバグがあり5.6.13で片方なおってるがもう片方はなおってない
そのたのバグ
メモりきれず
まとめ
5.6の機能は実用的なものが多い
Facebookでは5.6を本番運用してる
慎重にいこうして確認をふまえ多くのバグレポートを登録しfixしてからつかってる
GTIDとMTSはまもなくつかう予定
今後新たな不具合が発生することは想定済み
-----------------
以上、とても勉強になりました。
みていただいた方はありがとうございました。
