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

smallpalace's blog

鯖缶主婦の日々の記録です

Facebook at MySQL5.6で聞いてきた話のメモ

MySQL 勉強会・セミナー

こんにちは。smallpalaceです。

こないだ11/14とかにやってたdb tec showcaseであったセミナーのうち、

Facebookの松信さんが話された内容の個人的な備忘録です。

 

詳しくはそのうち松信さんのスライドが公開される気がするのでそちらを見てください。

色々抜けてるところも多いと思うので。

 

-----------------

規模間が大きいからコストメリットがあるのでMySQLEnginneeringチームがある

魔改造して使ってる

 

5.6をつかう理由

重要な機能が本体にマージされている

 独自に管理しなければならないパッチの量が抑えられる

 

接続数が多い場合に高速

 

リクエストをより安定して裁ける

  ストール(高負荷時にかたまるような状態になること)しにくい

 

InnnoDBConpressionの強化

 性能の落ち方が緩やかに(5.1の改造がマージされた)

リカバリとフェイルオーバがより簡素に

 スレーブ障害→再起動してレプリケーションを再開すればOK

  テーブル管理になったため

 GTIDによって、マスタのフェイルオーバー手順が簡素に

 MHAよりリレーログのあるなしの制約がない

 Semisyncでデータ消失の確率がない

 

まだつかってない機能

 Perfomansceschema

  パフォーマンスのダウンが5~30%

  性能分析はほかの手段で

 GTID

  いくつかの深刻なバグや機能不足があったもののようやく実用可能なレベルに

  まもなく本願環境に投入する予定

 MTS(マルチスレッドスレーブ)

  GTIDなしではトラブルシューティングが極めて困難

 

オフィシャルにはないがFacebookで必要なもの

 非同期MysQLクライアントAPI

 高速なフルテーブルスキャン

 より低コストなSemi-Synchronousレプリケーション

 SSD/FLASH向けに適した動作

 

 ほかメモり切れず

 

Facebook版MySQL5.6レプリケーション

 Semisinc mysqlbinlog

 I/Oスレッドの安定化と高速化

 バイナリログの読み込み時にグローバルロックを持たないように

 高速プリフェッチ

 

SemiSync mysqlbinlog

 同じマスタにバイナリログだけスレーブの代わりに持たせるもの。コスト面から

 

Semisyncレプリケーションの性能改善

 BinlogReaderが多数いる場合にコミット性能が指数関数的に悪化する

 pluginlog?のせい

 

I/Oスレッドの安定化と高速化

 マスタスレーブの

転送スピードをパラメータで制御可能に

バイナリログの読み取りサイズを8kbから1mbにとか

 

LogicalReadAhead高速なフルテーブルスキャン

 バックアップやオンラインスキーマ変更など

 テーブルが断片化するとテーブルスキャンが遅くなる

  遠いページ同士を連続して読むとランダムリードになるので

 先読みしてメモリに載せてあたためておくと早いというやつ

 10GBのテーブルで1分で読める

 

InnodbログファイルへのReadModifyWrite回避

 

InnoDBInnoDBログファイルに対して512バイト単位で書き込む

OSのI/O単位は4KB

対象ページがファイルシステム

 

InnDBログファイルとバイナリログのuncache

 

DuoublewriteBufferへの書き込み量削減

 書き込み量2倍だとSSDにやさしくない

 ページIDだけ書く。壊れたら再構築

 

その他

 super_read_only

 一部のシステム変数を変更したときにログに出す

 SQL_NO_FCACHE

 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でデッドロックを引き起こすことがある

 2つのバグがあり5.6.13で片方なおってるがもう片方はなおってない

そのたのバグ

 メモりきれず

 

まとめ

 5.6の機能は実用的なものが多い

 Facebookでは5.6を本番運用してる

 慎重にいこうして確認をふまえ多くのバグレポートを登録しfixしてからつかってる

 GTIDとMTSはまもなくつかう予定

 今後新たな不具合が発生することは想定済み

-----------------

以上、とても勉強になりました。

みていただいた方はありがとうございました。