社内共有用の資料です。 資料内のリンク先URLをぜひご覧ください。

1. MySQL5.6関連情報まとめ
※社内向け資料です
2013/11
KOMIYA@ISAO

2. 自己紹介
 ビデオゲームが好きだった（ゼル伝,FE,メガテン,塊魂他）




主婦です。最近はやる暇がなく今の趣味は娘（2歳）とお
出かけ等です。
シェルスクリプトとMySQLが比較的好きです。
ISAO歴は8年くらいな気がします。ずっとサーバ運用構
築とかしてます。
@smallpalaceですが有用な技術情報は特につぶやい
ていません。情報収集が主です。
FBの友達申請は乗っ取りでなければ受け入れる方針な
のでお気軽にどうぞ。

3. 主に変わったところ１
 GTID（GlobalTransactionID）：トランザクションセーフになるがMyISAM







やCreate..Select等のトランザクションセーフでない仕組みはあきらめるしかなく、
バグもあるのでまだ無効がいいです。ローリングアップグレードが不可能。
binlogフォーマット：デフォルト値が異なるので下位互換性が必要ならbinlogchecksum=NONEに設定を変える必要がある
MySQL Utility：mysqlfailover等のpythonツールが出た。便利だけど一部
GTIDが有効でないと使えなかったりも。
ｉnnodb_buffer_pool_dump:バッファプールを保存しておいて再起動し
たらロードできるので暖気運転したり重みを少しずつあげるとかの気を使う必要
がなくなった。
マルチスレッドスレーブ：DBスキーマが複数あるならスレッドスレーブを増やすと
並列処理してくれる。GTIDが有効でないとトラブルシュートが難しいらしい
読み取り専用トランザクション：宣言すればそうなるというものでMyISAMなみに
読むのが早くなるけどアプリの改修が要る。5.7では宣言しなくても自動的に
selectならread_onlyトランザクションになるらしいのでアプリの改修が不要にな
る模様。
スレーブに転送する際にfsyncを待つかまたないかのしくみ：が変わってるらし
くMHAつかってない限りはsync_binlog=1にしないとクラッシュセーフでない
フェイルセーフなreplication：同期の情報をファイルじゃなくてテーブルに書
くようにしたことで実現した模様。

4. 主に変わったところ２
 Performance_schema：pf統計とる機能デフォルトONになってオーバ







ヘッドは1割くらいらしいがメモリを500MBくらい食うっぽくt1.microやm1.small
では厳しいと聞いた。バックアップスレーブや検証環境以外はOFFか取る値の
調整が必要。オプティマイザトレースとかできたりなど細かいことが見られるよう
になる。
Innodb_memcache_api：memcacheからinnodbに接続できる夢のAPI
だけど某社の検証結果ではmemcache(repcache)より40%パフォーマンスダ
ウン、FBの人もなぜかinnodbより遅いくらいのことを言っててメモリリークのバ
グもある。
ロード方法のベストプラクティスが異なる：@sh2ndさんのブログをみましょう
/usrの下のmy.cnf：こっそりsql_modeが仕込まれているのでmvかつ明示
指定しないと前バージョンとクエリの挙動が変わってしまう
オプティマイザが賢くなった：遅かったサブクエリ他が早くなったようです
InnoDBデータファイルを別ホストに移動可能に：ロックする手順が要ります
がidbファイルを移動できるようになった
SSD向けのパラメータが増えた：ページサイズ変えたり先読みしない等可能に。
設定パラメータ自体が120個くらい増えてて調べるのが大変だった
詳しくはこちら↓
http://downloads.mysql.com/presentations/02_201303_MySQL_JP_Tech-Tour.pdf

5. バグ情報など
 GTID有効でネットワークが途切れるとデータ消失する
 InnoDBmemcacheAPIのメモリリーク（ #68530 ）
 GRANT文発行時、構文に特定の記載ミスがあるとレプリ
ケーションが停止する（ # 68892）
 マッチしないパーティションがたくさんある場合、予想ス
キャン件数を過剰に低く見積もってしまう不具合
※上記は勉強会で見かけた情報などです
僕らのMySQL5.6移行記(仮)
http://www.slideshare.net/conmame/mysql56-27565355

6. パフォーマンス関連
 基本的にあがってるけどクエリによっては下がったりする
という話をよく聞きます
InnoDBに関して
・参照専用トランザクションを用いるとMyISAMと同程度に早いという話
・スレッドの同時実行性能向上
・SSDへ最適化
・MemcacheAPI
・バッファプールのダンプとリストアが可能に
・オプティマイザの改善によるSQL処理実行性能の向上と処理時間の短縮
「MySQL 5.6時代のパフォーマンスチューニング」という中の人のスライドをどうぞ
http://www.slideshare.net/yoyamasaki/20131110-tuning-onmysql56

7. 運用方法の変化について
 GTIDが有効だとSlaveでクエリをスキップできなくなって確認






して空コミットしないといけなくなった（割と手間）
MySQL Utilityというpythonツールが便利そう
バッファプールのダンプとリストアが可能になった
reset slave all;しないとマスタの情報が全部消えない
5.6以前のバージョンのMySQLにimportする場合、また、リ
モートの5.5サーバから5.6のmysqldumpを使用してダンプす
る場合は、、mysqldumpに--set-gtid-purged=OFFを付けな
いとダメ
.ibdがコピーできるようになった。
パスワードの管理ファイルが難読化できるようになった

8. HAについて
 GTIDを有効にすればmysqlfailoverというのが使えて便利な
模様。最初はデーモンじゃなかったけどデーモン化した模様。
変わってからまだ試せてない。
 最近のmysqlcusualではGTIDはディスられまくりでそれって
MHAでできるよねという意見も。MHA作ったご本人はMHA
はリレーログが必要だけどGTIDだとそれが必要ないところが
いいしわかりやすくなると謙虚でした。
 FaceBookではそろそろGTIDつかおうとしてる模様。通常マ
スタ・スレーブ両方同時にオフラインでGTID有効化しないと
いけないところをスレーブだけとかローリングバージョンアップ
できるように改造したとのこと。
 弊社ではMHAとかでいいと思っています。Binlogフォーマッ
ト変わったのにも対応してくれました。（2013/5）

9. データロード方法のベストプラクティス
 詳しくは@sh2さんのブログURLをみてください。
http://d.hatena.ne.jp/sh2/20131007
mysql5.6における最適なデータロード手順
・テーブル作成
・プライマリインデックス作成
・データロード
・外部キー制約無効化
・セカンダリインデックス作成
・外部キー制約付与
・外部キー制約有効化
↑できるならこうしたほうがロードが早いようです
Percona Server with XtraDBのmysqldumpの新オプションに--innodb-optimizekeysというのがあってまだバグがあるけど一回keyをはずしてdumpしといて後でまた貼
るみたいなことができてロードが早くなるらしいです。
https://bugs.launchpad.net/percona-server/+bug/1233841

10. 変えた設定について１
 既存から新規追加したパラメータの一部（新規追加119、削除12、変更43でした）
table_open_cache_instances=2
performance_schema=OFF
innodb_buffer_pool_instances=5
innodb_io_capacity=400
innodb_io_capacity_max=2000
innodb_page_size=16384
innodb_print_all_deadlocks=ON
innodb_read_io_threads=8
#innodb_read_only
innodb_write_io_threads=8
innodb_flush_neighbors=1
#16コアなら8か16
#パフォーマンス統計
#innnodb_buffer_pool_size/innodb_buffer_pool_instance=1GB以上となるように調整
#ストレージのIOPS性能を指定するパラメータ。ioDriveなら20000とか
#非常時にinndb_io_capacityをあげることができる最大値、デフォルト2000
#左記はデフォルト値。SSDやioDriveで4KBのブロックサイズが最適の模様
#InnoDBのすべてのデッドロックに関する情報がエラーログに記録されるように
#読み込み用スレッド数
#読み取り専用になる起動パラメータ。(HA構成を組むときは要注意
#書き込み用スレッド数
#innodb_buffer_poolをflushするときに他のダーティページも一緒にflushして
ディスクシークを削減したいかどうか。デフォルトON。SSDならOFFでもいい。
innodb_sync_array_size=8
#CPU*2くらい。mutex/rw_lockのイベント待ち処理の並列性に影響。待機中のス
レッドの数が多いワークロードにおける高い同時実行性のために、スレッドを調整するために使用される内部データ構造を分割します。
詳しくはこちら→
@sh2ndさんのブログにもっと詳しくかかれています
http://d.hatena.ne.jp/sh2/20130806

11. 変えた設定について２
 Replicationがらみのパラメータ
binlog-ignore-db=mysql,information_schema,performance_schema
#replicate-ignore-
dbとbinlog-ignore-dbをあわせるかつmaster/slaveで同一である必要がある模様
gtid-mode = OFF
enforce_gtid_consistency=false
#GrobalTransactionIDを使ったレプリケーションを行う。
#有効にするとトランザクションセーフなステートメントの みログに記録でき、CREATE・・
SELECTやトランザクション内でのtmpテーブル作成やトラ ンザクション有効無効双方のテーブルへの同時アクセス等ができなくなる(MyISAMは使えなくなります)
master-info-repository=TABLE
# master.infoをテーブルに記録できるようになりクラッシュセーフになった。
relay-log-info-repository=TABLE #relaylog.infoをテーブルに記録できるようになりクラッシュセーフになった
sync-master-info=1
#0より大きい場合、スレーブは、sync_master_infoイベント後（fdatasync（）を使用して）ディスクへ
master.infoファイルを同期化します
slave-parallel-workers=1 #GTIDが有効じゃないとマルチスレッドスレーブはトラブルシュートが困難らしい
binlog-checksum=NONE #下位互換にするならNONE。デフォルトCRC32
#master-verify-checksum=1
#有効にすると、チェックサムを使用してバイナリログからイベントを検証するため、不一致が
発生した場合にエラーためにマスタで停止を引き起こす。
#slave-sql-verify-checksum=1
#有効にすると、スレーブはリレーログから読み取ったチ>ェックサムを検証し、不一致の場
合には、スレーブがエラーで停止します
binlog-rows-query-log_events=1
log_bin_use_v1_row_events=ON
#下位互換にするなら無効に
#有効にすると古いスレーブとreplicationする際エラーを出さなくする（ただしtimestamp絡
みでエラーがでることも)
report-port=3306
report-host=10.1.2.84(自ホストのIP) #masterからshow slave hostsで見られるようになる
↓詳しくはこちら
http://downloads.mysql.com/presentations/MySQLTechTour_Replication.pdf

12. Facebook at MySQL5.6できいた話の一部
 FBにはORACLEから引きぬかれた人で構成されたmysqlエキスパートチームがあり
大規模向けの改修をして本家にパッチを送りまくっていて5.6ではそれが結構盛り込
まれているので大量のパッチを管理するよりはアップデートすることにした
 Facebookでは5.6を本番運用中
 プロダクションへのクエリを検証環境にも投げるというのをしてバグ出しした
 つかってない機能はPerformance_schemaとGTIDとマルチスレッドスレーブ。うち
GTIDとMTSは最近ようやくマシになってきたのでつかう予定
 多数の改造等があって書ききれません。松信さんがスライドを公開するまではメモった
ブログをよかったらどうぞ
http://smallpalace.hatenablog.com/entry/2013/11/21/041811

13. 5.6関係ないけどMariaDBのうわさ
 MariaDBがRedhat系で将来MySQLに変わりメインの
DBとして扱われるとかGoogleがMySQLからMariaDBに
全部乗り換えるといううわさについて
⇒Googleの乗り換えについてはMariaDBの中の人がそう
いってるだけでGoogleの人は否定したとORACLEの人
が言ってた
⇒MariaDBの中の人は元々MySQLから分離して開発を
続けてて袂を分かった人々でライバル心があるっぽい雰
囲気だった、というMariaDBの勉強会の関連ツイートを
見かけた
⇒Redhatの話はよくわからずニュースで見たレベル

14. 5.7の情報をちょっと
 まだGAでないので色々変わる可能性があります
詳しくは中の人の資料をご覧ください
http://www.slideshare.net/rkajiyama/20131025-casual-uppt

15. その他お勧め情報
 もし良かったらどうぞ
Devsの常識、DBAは非常識
http://www.slideshare.net/yoku0825/devsdba?from_search=5
とあるイルカのバーボンハウス
http://www.slideshare.net/yoku0825/ss-27597161
漢のコンピュータ道
http://nippondanji.blogspot.jp/
「実践ハイパフォーマンスMySQL 第3版」 が予約注文可能に！
http://www.amazon.co.jp/dp/4873116384/ref=cm_sw_r_tw_dp_2TRJsb0QZ
Z2T1
MySQL Performance Blog（英語）
http://www.mysqlperformanceblog.com/

16. フォローしとくといい専門家の方
順不同です。かききれなかった方ごめんなさい
@yoku0825
@sh2nd
@nippondanji
@meijik
@yyamasaki1
@Rkajiyama
@kamipo
@myfinder
@kazeburo
@sakaik

17. おわり
 ご清聴ありがとうございました！
 なんか間違ってたらお手数ですが是非教えてください