mysqlcasual#7_20141212に行ってきた
こんにちは。smallpalaceです。
今回は定員2倍超の補欠から起死回生のスタッフ枠で参加できることになって会社の忘年会をスルーしていってきました。
ハッシュタグ：#mysqlcasual
ブログ
MySQL Casual Talks Vol. 7まとめ | b.l0g.jp
「MySQL Casual Talks vol.7」に参加してきた＆資料まとめ #mysqlcasual - 元RX-7乗りの適当な日々
---------------
MySQL Fablicつらい
@yoku0825さん
@yoku0825さん
娘さんが生まれるそうでめでたいです。
Fablicのクライアント言語のご紹介とデモが。MySQL::DBDつくったそうですごい。
sandboxでいくつかたててデモ。
5秒くらいで切り替わってた。
地雷友達募集だそうです。
---------------
@tatsuru
はてなの人
EC2でMySQL運用したはなし
MHAの構成、masterはENIつけてる（スプリットブレイン対策）
海を越えてもだいたいうごく
slaveはHAプロキシ
モニタリングは自社のまかれる
RDSならもっとカジュアル
最近SSDで安心
カジュアル運用のはなし
落ちたら終了、デイリーsnapshotからさくっとつくる
オートスケーリングはためしてるけど試験段階
5.6ならいけそう
EBS障害でI/O障害、ヘルスチェックちゃんとしないと気付かない
北米ハリケーンがきになる
ELB
DNSベースでつらいのでHAProxyつかってる
ある程度の規模までは運用しない、でいいのではという結論
お値段も2台より2割高いくらい
------
@mita2
ヤフーの三谷さん
オラクルDBとMySQLメインのDBチームのかた
perconaつかってる
PerconaLIVE、Pelcona社の有料カンファレンス
XtraDBのはなしを。
ハンズオンとかしてきた
GaleraClusterとかXtraDBCluster
アクティブアクティブのクラスタ。
ヨーロッパではメジャーらしい
OpenStackのバックエンドでも採用されている
本家MySQlでもおなじようなのを採用予定？
GroupReplication
どこに書いても同期してくれる
遅延を気にしなくていい
Writeのスケールはできない
データの同期はSST,IST、Donor
SST、mysqldump、rsync
SSTは常にあるという前提での設計がいい
ロックの問題、COMMITしたらデットロックが帰ってくるという挙動になる
運用上はWrite一個がいいじゃんというはなし
ふつうのレプリケーションと組み合わせることも可能
Gareta4.0の予定
ロックなしのDDL
でっかいトランザクションのパフォーマンス改善
オペミスで不整合おきるとそれいがいのノードが落ちたりするのを改善
PCIe-SSDとGaleraを組み合わせるのがいいんじゃないかと思っている
----------------------
おくむらさん@hfm、ぺぱぼのひと
へてむるのおはなし
http://htn.to/tKpxSg
4.0.25から5.0.96にあげたはなし
つねまつさんからのIssueのアサイン
ほぼ未経験の状態から。現状の把握から
顧客管理DB、よぼよぼのサーバ
slaveはぶっこわれててシングル運用だった
再起動してあがってくるかもわからない状況だった
チェインレプリケーションがどこまでできるかバージョンをだんだんあげてレプリケーションしたりしてた
最終的には5.0にすることになった
ほかでの実績があった
誰かがビルドしたrpmがあった
mysqldumpをリプレイスのなかでやろうということに
6/20 ワールドカップでみんなテレビ見てるからアクセス減るタイミングを見計らった
slaveが途中で止まる
INSERTクエリが実行されたときだけbin-logが壊れる現象に遭遇
霧戻してメンテ失敗
@hiboma先生にたすけてもらって
5.0のソースとGCCバージョンの相性に問題
4.33～4.4.0あたりのGCCのバージョンで5.0をビルドするとこける
最適化オプションつけるとだめとか。
http://htn.to/8X5wZ
あたらしいGCCでビルドしたら、redhat-rpm-configとの相性が悪くて
%install前にディレクトリ消してるのでデバッグ時に作られた必要なのがきえてた
8/22リベンジメンテ、早朝に。
1回目のメンテのdumpのおかげでレプリケーション作って切り替えるだけに。
旧サーバは一か月後にご臨終に。合掌。
------------------------------
ソーシャルゲームDBの危機回避
ソーシャルゲームDBの危機回避 // Speaker Deck
@strskすどうさん
・ディスク容量の危機を回避する
ソーシャルのギフトボックスやユーザのカード一覧
ギフトボックスとカード一覧の上昇率がやばい
一定期間のデータは必要なのであまり消せない
イベントピーク時に数十GBふえたり
やったこと
論理削除されている一定期間たったデータを削除
削除量が多すぎるのでメンテナンス実施
InSERT INTO SELECT、RENAMEでつくりなおす
データ削除バッチを
DELETEしても空き容量が増えない
OPTIMIZEが必要だったのでpt-online-schema-changeをつかって対応した
オンライン中でもロックせずに実行できるというの
--set-vars="sql_log_bin=0" れぷりさせたくないとき
--critical-load スレッド数がこれを超えると中断（デフォルト50）
--max-load
よくつかうオプション
・れぷり遅延の危機を回避する
TRUNCATEしたら遅延したという事件
ゲームのマスタデータが毎回データをクリアして読み込むスタイル
なぜかDELETEよりもおそい、小さいテーブルでも遅い
バグだった。内部でDROP・CREATEしてるinnodb_file_per_table=1で、バッファプールの利用が多いと遅くなる
DELETEにして遅延回避、そんなにデータ量がおおいわけではないので
----------------------------------------
おといれ休憩
--------------------------------------
@ryopekoさん
sidekiqにたいこうして
shinqというのをつくった
ActiveJob、Rails4.2から入るよていのキューアダプター
q4mのテーブルがかってにつくられる
ジェネレーターもある
へー
コマンドラインオプション
まとめ
モダンなインターフェースだけどモダンにしすぎて4.2からしかつかえないけどよろしくおねがいします
------------------------
@kakerukaeru
CONTINUOS RESTOREへの道
継続的リストアしてみた
slave全台
MYSQL群が突然の死をむかえたとして、
バックアップの正当性の担保を自動化してみた
バックアップ定期的にとってbinlogはsyncしてるchefでばらまいて、、
何をもってリストア完了とするか
backup用のslave
確認項目
テーブルの破損がない
中身が一定
定義が一致
れぷりとめるバックアップ止、早くて書ききれず
毎回はテーブル破損がないこと
一週間毎checkは全部やる
jenkinsで担保してる
これで安心してねれる、かも（ついさっき成功したばっか）
いっこいっこ確認する重圧からは解放された
check項目つめれるかも？
データ増えると時間足らないかも
----------------------------------
@ijinさん
MySQL FAILOVER CONSUL
WALTIというセキュリティーサービスをはじめましたNMAPがAPIからつかえるやつ
夏ごろのブログのフォローアップ
MHAとConsulでやってみたはなし
HHTP APIでrestでキーバリューが保存できる
リーダーノードがいてwirteは生じるとほかに同期して過半数の書き込みができたらコミットとみなす
リードはだいたいコンシスタンス
フェイルオーバーはmaster-ip-failover_scriptをよぶ
マスタのDNSのエンドポイントを書き換える
consul連携のデモが
IPがキャッシュされた場合とかCONSUL EVENTとかつかうといい
イベント発生させるとほかのノードに伝搬する
WATCHという機能でconfの更新とかできる
gossipだとベストエフォート
イベントよりはtemplateがいいらしい
--------------------------------------
@kazeburo
ISUCON４優勝者のかた
アプリを変更せずに予選突破したときに何したのか
もしmy.cnfを変更しなかったら？
my.cnfに1行追加してさらに高得点をねらう
isucon4のあぷり、いすこん銀行のログイン画面
MySQLからみると
ログインログの書き込み
innodb_baffer_pool_size=1Gついか
innodb_flush_log_at_trx_commit=2にしてみた→すごいこうか
innodb_flush_method⁼O_DIRECT あんまかわらず、マニュアルにはないnosyncでどーんとスコアあがる
innodb_doublewrite０あまりかわらず
------------------------------------------
@neofact
NVMFSの話とか
FusionI/Oのひと、買収されてSanDiskという会社になるみたいです
フラッシュメモリの特性の紹介など
最近大容量のもあるけど性能がおちる
OpenNVMプロジェクト
ソフトウェアコントロールでの差別化
それにたいするAPIを公開することでより高速な処理をということで
各種プロダクトと開発がすすんでいるところ
アトミックライト、NVMコンプレッション
NVMFSとは不揮発性メモリに最適化したファイルシステム
ATOMIC WRITEとか詳しい話は春ごろのイベントで
---------------------------------
桑野さん
@kuwa_tw
NVMFSためしてみた
速度と圧縮のいいとこどり
Percona5.6で
ROW_FORMAT=PAGE_CONNPRESSIONとかやるとつかえる
RWは8割、ROだと６割くらい
書き込み回数で徐々に断片化するというかんじ
実データ、45%圧縮できてる
CPUおかわりUserがあたまうちに
データ量が増えるテーブルとかヒストリとかバックアップとか
CPUバウンドなところにはいれずらい
データ量がほしいところにはいいかも
---------------------------------------
@do_aki もしもという会社のひと
N:1レプリケーション 進捗どうですか
2秒ごとにマスタを切り替えてる
MySQLlabsにもある
プログラム刷新してテストをかいた
動的に入れ替えるようにした
MHA対応は進捗ゼロ、以上
RaspberryPiとMySQLというはなしをします
B+というモデルを会社にもらった
100mbps
N:1れぷり普通にうごく
コンパイルしてみたら8.5時間かかった
clusterやってるひとがいた
おもしろかった
----------------------------------------
@kamipo
MySQLとActiveRecodeそのご
ActiveRecodeのMySQL対応は放置される傾向にある
メンテナがみんなポスグレ派
毎日がんばってプルリクしたら6個マージされて10個放置
forMysqlとかいたらぜんぶほうち
どんなバグがおきたかというとintのレンジチェックが入ったせいで
保存できなくなったけどマージされたので今はつらくない
いろいろバックポートしたジェムを作ってくれたそうです。すごい。
----------------------------------
@rkajiyama
なかのひと
会場の件、ごめんなさいとのこと
PlanetMySQL、ブログ登録おねがいしますとのこと
英語版は乗ってる
@planetmysqlで告知される
多言語対応をしてる、画面右上に国旗が乗ってる
jp.planet.mysql.com
jp.planetmysql.org
@planetmysql_jpでツイートされる
jpどうなってるか、文字化けしてる。
文字化け修正中です
化けてないやつもある
文字化け回避策@yoku0825
InnDBDeepTalk#2というのがあるらしい（日程未定）
スピーカー特典紹介とじゃんけん争奪戦が。
------------------------------------
というわけで今回も面白かったです。ありがとうございました。
スライドとかのリンクはあとでつぶやかれたら貼ると思います。
誤字脱字もあとでなおしますたぶん。
では見ていただいてありがとうございました。
