mysqlcasual#6_20140711に行ってきた
こんにちは。smallpalaceです。
まあいつもどおり楽しみにしてた勉強会に行ってきたのでそのメモを。
誤字すみません。あがってたらリンク載せるのでそちらをご覧いただければと。
ハッシュタグ #mysqlcasual
行った方のブログ:
http://blog.mogmet.com/mysql-casual-talks-6/
---------------
最初はyoku0825さんのTokuDBのお話から
http://www.slideshare.net/mobile/yoku0825/toku-db-36871540
Tokutekが作ったFractalTree（R)Indexを実装したストレージエンジン
MariaDBのストレージエンジンとしてある
断片化しないらしい
外部キー制約はサポートしてなかった
配列を二つもってるもともと空きがあるのでランダムライトの性能がいいらしい
すごい早口でテストケースを解説していた
ファイルサイズを圧縮がイケてるという話だったのではかってみた
InnoDBの圧縮したやつの1/3のサイズ
スループットもいい感じのベンチ結果だった
所感
TokuDBはかなりCPUをぶんまわす。かなりCPUバウンド
ロック粒度がよくわからないかんじだった
公式MLが過疎
パーティショ二ングしてあってプルーニングが効かないクエリがおそい
カバーリングおそい
Countがおそいっぽい
mysqlコマンドラインクライアントからクエリーをたたくと不気味な静寂につうｔまれるとか
安定して使える感じではないけど面白いので影響ないところから。。
Q。ロック粒度って？
A。一応インデックスロックということになっている
selectどうしなのになぜ競合するのかよくわからないみたいなことも
------------------------------------------
MySQLゆるふわ運用のためのアグレッシブ開発～データを増やさないための設計
Songmu（そんむー）さん
http://songmu.github.io/slides/mysql-casual-6/#0
アプリ側のおかた
今日の話、
・MySQLのデータ量を如何に抑えてメモリに載せきるかという話
とか
ゆるふわ運用
・スケールアップで頑張りたい
・シャーディングとか絶対やだ
・slave参照もあんましたくない
・データをメモリに載せきる
最近のハードウェア事情
・ちゃんとインデックス効いたクエリを投げてる分には数万QPSいく
データをメモリに載せきるために
・パーティション活用
・論理削除
・データを増やさない
パーティションの活用
・MySQLのDeleteは遅いので一度の大量のデータを消すのに時間がかかる
・パーティションを設定することで、大量のデータを瞬時に消し込むことができる
パーティションの制限
・パーティション対象カラムは全てのユニークキー制約に含まれていないといけない
・外部キー制約を使えない
・個数制限（5.5だと1024、それいこうは8192）
・パーティションを切っていない領域にデータを格納できない
パーティションの種類
・RANGE
デイリーで切る
id,createde_dateとかでPrimarykey
保持期間を設定して期間が過ぎたデータを消す（ドロップする）
・LIST
期間データを持っているマスタ系のデータのid(event_idなど)毎に切る
id,name,event_id
イベント期間が過ぎたら消す（ドロップする）
Created_dateでパーティションを切る功罪
ロックの競合のはなし
対策はcreatede_dateをdate_timeでなくdateにする
created_dateでなくidでRANGEパーティション切る
先々のパーティションを余裕を見て作っておかないとエラーになる
カジュアルにINSERTでいるようになるのがパーティションのメリットの一つ
KVSを使って頑張って引き回していた一時セッションとかもこれでかいけつ
パーティションの運用
毎日未明に翌日分のパーティ所hンを作成するバッチまわすとか
データを増やさない仕組み
・論理削除をさえる
DELTEして履歴テーブルにBULKINSERT
履歴テーブルはパーティションを切って消してく
数百行ならいける
削除フラグのカラムを意識して変なIndexはらずにすむし
クエリもシンプルになる
・そのバッチ処理は必要か
たとえばユーザ全員プレゼントをする場合
バッチで全員に付与でなくユーザアクセスのタイミングで付与する
giftテーブルで付与機関を設定する
・データ型に気を付ける
マスタデータなどでSMALLINｔでいいところはそうするとか
・外部キー制約つけられないので厳しい
がんばりましょう
・古いデータをそう簡単に削除できないんです
ECとかだとあるある
5.6からEXCHANGE PARTITIONてのがあってパーティションを別テーブルに移せる
削除データをEXCHENGEするテーブルつくってプロダクション用はBLACKHOLEにしておいて、データ保全用のSLAVEには保存されるようにするとかするとよさそう
------------------------------------------
Yappoさん
BetterGroongaReplication
http://yappo.github.io/talks/20140711-mysqlcasual6/#/title
MySQLに頼らずにGroongaでReplicaiton実装したはなし
むかしSenna+MySQLでガラケー用の検索サイトつくっていた
出たてから使ってたらめちゃくちゃバグ多くパッチ書きまくっていた
・コツがあった
開発者が使ってない使い方はしない、fulltextindexは頻繁に更新しない、通常のMySQLの用途としてはつかわない、ORDERBY狙い＋OFFSET10000LIMIT10とかで10行しかfetchしないようにするパッチかいたり
・安定運用方法
databaseつくる、クローラを回して検索用データをinsertしまくる、URL別のスコアを計算する、スコアを基準に検索用テーブルをALTER TaBLE SERCH_DATA ORDER BY scoreとかする。。。
・ここ数年以内の話
全文検索が必要になってJVMで動いてるものを安心して使う気にならずGroonga
・Groonga＋MySQLの利点
rep凋落、MHA
欠点：闇が深い
・Groonga単独の欠点
repどうするの
なければつくったらいい
GroongaProxyサーバを作った
pgpoolのレプリケーション機能っぽい感じ
applicationはGroongaProxyServerになげる
だがしかし障害ノードの対処やスケールアウトどうするのか
クエリをproxyしてるだけだから、実際に運用することが不可能
アドバイスを受けてbinlogみたいな仕組みにしてみた
サーバ増設が簡単、設定はごくわずか、追加で必要なデーモンなし
システム概略の説明がこまかく。
最後のまとめ、困ったら優秀な人に泣きつけは納得
--------------------------------------------
doAkiさん
N:1Rep meets MHA
http://www.slideshare.net/do_aki/n1-replication-meets-mha
なんかすごい。
joinしたかったので作ったN:1のやつ
もう3年運用している驚くべき話。一部マスタサーバが変わったとか
pt-online-schemachengとかで止まったりする
マスタが切り替わっても対応できるコードを書いてみたらしい
MHA対応してみたらしい
マスタがfailしたときはちゃんと動かないっぽい切り替えるときは大丈夫らしい
--------------------------------------------
kamipoさん
ふつうのWeb開発者のためのクエリチューニング
http://kamipo.github.io/talks/20140711-mysqlcasual6/#/title
くそクエリのことについてついったでよく言ってる
5.6時代のぱふぉチューの前にクエリをチューニングしよう
DBIx::QueryLog
useするだけで全部のクエリをSTDERRにはいてくれる
アプリけーしょんを一切変更することなく使えて便利
plackup =mDBIx::...
これで問題を読み取れるのは訓練された開発者だけ
クエリや実行計画から問題を読み取るには経験が必要
Using filesortとか見た瞬間に一瞬でやばいやつきづけと
明らかにやばそうなクエリの解説が。。
ありがたいです。
MySQLCasuallogみたいなの
useするだけでつかえて実行計画のやばそうなところを色つけてくれる
赤いのが全部なくなるまでやればだれでもいける
ORDER BY狙いのキーの話を聞きたい人は投票しよう
http://yapcasia.org/2014/talk/show/e495bc1a-f30d-11e3-b7e8-e4a96aeab6a4
---------------------------------------------
ここでちょっと休憩
--------------------------------
続・AmazonRDS
もりさん @monry
http://www.slideshare.net/monry84/20140711-mysql-casual-talks-vol6
----------------------------------------
karupaneruraさん
NEXT KEY LOCKのはなし
http://www.slideshare.net/karupanerura/next-keylocking
Transaction分離レベルのはなし
一貫性と並列性のトレードオフ的な。
ファントムリード、実行中のInsertが見えちゃう
InnoDBはnext keyロックがある
record lock 単一のindex recordのロック、PKEYが１のやつ
gaplock
next keyロック
勘所、 index record lockえある、covering indexの場合などはlock範囲が異なる
クエリによってロック範囲が細かく異なる
---------------------------------
MySQL Fablicの話
dblmktさん
http://www.slideshare.net/doublemarket/mysqlcasual6fabric
アメブロのインフラの人
マスタ分割激しい
独自ルールでシャーディングしてる
テーブルがたくさんあってユーザごとのブログ入ってるテーブルが10万ユーザごとにわかれてたり
とあるマスタでslaveの数みたら65台あるとか
大変なところ
スレーブの作り直し面倒、シャーでぃんぐルール変更むずい
アクセスの片寄対策困る
my.cnf書き換えしんどい
--Replicate-do-tableをいちいち書いてる。。
いろいろ検討してみた
Jetpantsという
レンジベースのシャードかんり
MySQL Utilities
コピーコマンドとか
MySQL Fablicに期待してる
マスタ障害時、スレーブの自動昇格
シャーディング、クエリのロードバランシング
スレーブの複製も簡単
構成はAppが対応コネクタをつかって管理サーバに接続して、
どこにデータがあるかをもらってから参照と更新、適切なとこにいく
グローバルグループのマスタがいて、ほかのグループがいて
注意として、Fablic対応のコネクタ必須
MySQL5.6からのGTID必須
セットアップ、Fablicサーバのセットアップになる
設定ファイルはわりとデフォルトで動く感じだった
グループを最低でも一つは作らなくてはならない
FablicいれるとChange MAsterしなくていい
w障害検知を有効にできる
数秒で切り替わるかんじ
App側からは再接続の手続きを書く必要がある
シャード作成
分割とか移動もコマンド一発でできる感じ
グローバルグループにはスキーマだけが入るかんじ
ドキュメントがまだまだ
コマンドの結果がわかりにくい
シャードのルールの一覧表示
Fablicサーバが今のところHAできない、Pacemakerつかえばいいんじゃないとか、ボトルネックになる可能性がある
シャード分割、移動時
マスタにmysqldumpが走る
マスタとスレーブでDELTEが走る
GTIDrepつかう新規プロジェクトなら入れといてもいいかも
既存DBに入れるのはつらい
まとめ、もう一歩だけど結構いい感じだった
Yakstみてね
-------------------------------------------------
スタジオさんのLTしたい（仮）
LINEの人
http://www.slideshare.net/studio3104_com/my-sql-casual-talks-vol6
スロークエリログの解析どうしてますかというはなし
日次バッチによるメールで収集
サーバログインしてファイルみる
mysqldumpslow
pt-query-digest
グラフで可視化
mysqldumpslowはファイルを食わせないといけない
ホストまたがってたりする場合は合体させてから
対象期間指定できない
1台から５００台までのMYSQL運用
Nata2
スロークエリログのグラフと一覧が出る
リンクでどういうステータスになってるか見れる
https://github.com/studio3104/nata2
スロークエリログの登録、APIがあって情報追加してあげると。
fluentプラグイン開発中。ただ対象サーバのメモリ食うとかいろいろある
今後修正したい機能など
対象期間を細かく指定、個別のクエリビューみづらいので直したい
パッチ募集中
---------------------------------------------
菅原さん sgwr_dts クックパッドのひと
MHAonAWS+Rails
さまり
弊社のMHA設定
Railsアプリに設定した話
いろいろな理由でRDSつかってる
VPC RouteTableによる仮想IP
フェイルオーバーまわりのツールは自作
Route Tableまわりとか
ManagerはUpstertでデーモン化
マネージャは冗長化していない
サービスごとのcnfがあって作業ディレクトリを設定してる
ノードサーバのパペット
マスタサーバのパペット
そんなに手間なく設定できるようにはしてる
導入にあたって、検証環境つくってテストしました
切り替えるとRailsでエラーがでる
サーバが死んでも再接続はしてくれるけど書き込み制限されたりするとだめ、再接続のためのライブラリを作った
activerecord-mysql-reconnect
https://bitbucket.org/winebarrel/activerecord-mysql-reconnect
セッションを切って大丈夫か？
last_id、ほか構造体からとってきてるだけだから大丈夫だろうと
再接続モードを3つ用意した
一応サービス投入してオンライン切り替えして問題なかった
デモが。いい感じに再接続していました。
------------------------------------------------
梶山さん
MySQLUtilities
mysqluc -e "help utilities"
mysqlreplms：複数のマスタから1台のスレーブに集める
ある一定間隔できりかえてくれる
ただGTIDが必須
告知
7/17：OEMの組み込みセミナーCのライブラリとして取り込むやつ
9/5：MySQL Centralが海外で
10/10：詳細未定、18時以降
11/14：会議室とってあるよ
12/12：会議室とってあるよ
個人的にはMySQLでNoSQLとかいいな
-------------------------------------------
母数の少ないじゃんけん(当たらない人なので人が多いと勝てないw)にかって余ったタブレット菓子いただきました。ありがとうございました(^^)
EXPLAINが染まるやつ職場のFBグループに貼っときました。他の方のもおもしろかったです。闇が深い環境の話とかw
職場ではMSPな感じで5.6環境増えてきてるし昨年秋冬くらいに構築してた2つも5.6。でもGTIDは使ってなくて3台以上ならMHAが多かったかなー。
ではまたそのうちに。読んでいただきありがとうございました。
