2013-10-26
MySQL Casual Talks vol. 5 に行ってきたので、自分なりのメモと資料へのリンク。
途中、アラートが鳴り始めて確認してたりしてメモが適当なところがあるが仕方なしｗ
かなりのスピードでじゃんじゃんプレゼンが進んで行ったが、どれも面白い・役立つ内容ばかりで、楽しいひと時でした。発表者の皆様、会場の提供や調整などしてくださった@myfinder さんはじめとする皆様、ありがとうございました。自分の隣でビール缶を次々と「カシュッ」と空けていた@oranie さんのような余裕を持ちつつ、次回は自分も何かネタを提供できるといいなあ。
@yuryu さん GTIDを使い始めてやめた話
GTID - 全てのトランザクションを一意に識別、一貫性保証
マスタを切り替えると、マスタのUUIDが変わるのでGTIDが2個になる
利点
change master to … master_auto_position=1で簡単にレプリをはれる
mysql workbenchのmysqlfailoverとか使える
欠点
クラスタ全部GTID有効にする必要
MyISAM使用不可
HAしたいならMHAでいいんじゃね？
バグ
GTID有効でFLUSH LOGSするとレプリ停止(5.6.11のみ)
stop/start slaveするとトランザクションがスキップされる可能性あり
ネットワーク切断でトランザクションスキップの可能性
結局、本格的に使うには時期尚早なので辞めました、ということ
クックパッでは5.5のサーバを5.6にバージョンアップしたり最初から使ったり
レプリしてクエリ流してコンフィグいじり始めた
EBSでスナップショット取ったボリュームを5.6マシンにぶら下げてmysql_upgrade実行
Kage
リクエストをコピーしてsandbox環境に流す仕組み(ユーザへはproductionからの結果が返る)
レスポンスのdiffも取れる
バックエンドを5.6にして違いを確認
バージョン違い、設定違いのサーバを並べて比較
開発用DBを先に新しくしてリリース前に新環境を試す
バグ確認用(最新) → 検証用(1つ前) → 本番用(安定版)
各バージョンが入ったAMIを用意しておいてすぐ起動できるようにしてある
GTID有効だとsql_slave_skip_counter使えない
AWSだと色んな検証がCasualにできる
bugs は見ましょう！5.6で遅くなるところもあるので、得意な部分から本番投入していっている
@yoshi_ken さん 5.0 Tritonnから5.6 mroongaへの移行
技評の記事 の裏話旧構成 マスタはDRBDでミラー、スレーブにレプリ
5.6スレーブを追加してそこに孫をぶら下げて旧環境を切り離し
本番環境のアクセスログから抜き出したURLを使ってテスト
テスト中に見つけたmroongaのバグはすぐに修正してもらえた
HWトラブル
マスタ死亡、起動しない、焦げ臭い！さらにもう一台も焦げた。。
GTIDよりsemi sync repl + MHAがいいのでわ
innodb_file_per_tableでなかったのでダンプしてバージョンアップした
memcached APIはバグで使えなかった
@yoku0825 さん アプリ担当が出してきたDDLがドイヒーな話
すごい心が痛い&共感出来る内容だったけどテンポ早すぎてメモできなかったｗ
MariaDB 10からもGTIDが使えるようになった(ただしMySQLとは結構違う)
ログ用テーブル
インデックス名はidx_カラム名_カラム名_…とすると長いけどexplainのときに分かりやすい
フレームワークが作る通りではなくDBの特性を考える
SQL文を見るだけでどのインデックスを使うかなどの意図が分かる名前付け
プレゼン資料
この辺りトラブル発生してメモがおろそか
いろんなMySQLをインストールして使い分ける仕組み
percona serverのmysqldumpにはkeyを消してダンプして作り直すオプションがある
fbの5.6にはlogical key readのオプションがある
@do_aki さん multi master replication
MySQL Casual定番の内容
change masterを2秒ごとに切り替えてマルチマスタ
5.7では標準でできるようになった
過去に色々な方法でマルチマスタを試みている人がいるww
@RKajiyama さん 5.7 Multi-source replication
labsにはDMR以前のものがありますよ
hadoop applier for mysql
JSON UDF
Multi source replication
MySQL Utilities Fabric
Fabric + multi source replication + multi thread slaveの組み合わせ良さげ
プレゼン資料
GitDDL::Migrator, SQLTranslator(SQLFairy)
ブランチごとにテーブルやカラムが違うと大変
テーブル構成の違いなどが表示できる
ブランチを行ったり来たりしながらalterしたりできる
App::RunCron
perlのラッパー、レポータを書くと色々できる
cronのログってnullに捨てちゃうけど困るよね
cronlog
cronの処理をラップしてエラー処理が可能
13年運用されてるデータベース
レコードをCSVにしてload infile
シェルスクリプトで自動化
4時間以内に終わらせるという時間制約
loadを高速化する工夫
ジョブフローの最適化(jenkins build flow plugin)
ジョブフローをGroovyで書ける(並列実行などなども可)
データ移行自体をCIする(1クリックデータ移行！)
/var/lib/mysql以下の並列rsync
@monry さん Amazon RDS
マスタ1台、スレーブ5台
物理サーバが1台13万以上ならRDSの方が安い(3年償却)
@chobi_e さん ストレージエンジンを作ってみた
2013-10-01
MyNA(日本MySQLユーザ会)会 2013年9月
先週のMySQL Cluster Casual Talksに続いて、週末にかけて行われたMySQL Connect で発表された最新情報を聞けるということで、MyNA会に参加してきた。基調講演の内容は既に報道されていたので(Publickey (1) , (2) , (3) )ある程度分かっていたが、一番うれしかったのはMySQL Fabricのデモが見られたこと。MySQL Utilitiesの機能でシャーディングができるようになるということでどんな感じか見てみたかったので、(ラボ版で一部動かないところがまだあるということだったが)興味深かった。発表者のみなさま、会場を提供していただいたOracleのみなさまなど関係者の方々ありがとうございました。
@RKajiyama さん MySQL Connect基調講演の概要
いつOracleはMySQLを殺すのかと言われてきた → うわさを打ち消すために3年半の間大量のリリースをしてきた
チーム全体も増員、特に品質管理チーム
DMR(Development Milestone Release)というやり方
リリース候補版になったコンポーネントを含んだリリース
18から24ヶ月ごとにメジャーリリースしたい
Webや組み込み系に強いDBとしてOracleにとっても価値 がある
現在もLinux系の最も重要なスキル＝MySQL
今もユーザは多数
5.7.2 DMRの発表
Release noteが超長かった＝たくさんの更新が含まれている
InnoDBパフォーマンス向上 explain for connectionで別セッションのexplain
Optimzerの結果をWorkbenchでさらに詳しく
performance schema改善
tmpテーブルがInnoに
同じDB内でのマルチスレッドレプリケーション
5.7の以後のバージョンでの予定
MySQL Utilities 1.3
MySQL Utilities 1.4から
Fabric
アプリから意識せずにシャーディングできる
Connectorが接続を受けて振り分ける
レンジかハッシュ、リシャーディング
いちいさん@Gree, いけださん@SCSK MySQL Connectの感想
Oracle OpenWorld、JavaOneと一緒にやってる
SFのホテルいくつも貸し切り、道路も閉鎖して休憩スペースに
FacebookのMySQLの話 まつのぶさん MySQL 5.6@Facebook
5.1にパッチ当てたのを使っている
圧縮、クラッシュセーフスレーブ、フラッシングの高速化など
シャドウサーバ
5.5を飛ばして5.6へ
GoogleがMySQLをやめてMariaDBに全面移行する というのは、XLDBというカンファレンスでの話を元にした記者の煽り記事
MySQL json UDFs
カラムにJSONをつっこんだものをファンクションで処理できる
ラボ版のMySQL Utilities に搭載された新機能マスタにスレーブがぶら下がってる構成
アプリからConnectorを使ってアクセスする
ConnectorはFabricに問い合わせ先を確認してからシャードにアクセス state storeに情報保存
スキーマの情報などだけもってデータは持たない
グローバルグループ
アクセス時にRWかROを指定すると、Fabricが自動でマスタあるいはスレーブにアクセスを振る lab版は罠だらけ なので気をつけよう。。開発者の方のブログ が役に立つ
赤井さん GNU 30周年とMySQL
GNUプロジェクトが始まって30年
MySQLの成長はGNUの恩恵を受けた
GNUへのリスペクトを忘れないように しよう
2013-09-27
MySQL Cluster Casual Talks
一応仕事でMySQLをよく触っている身として、軽く検証はしてみたものの、担当している業務では参照メインのDBが多いこともあって実運用では使ったことがなかったMySQL Cluster。改めて利点も欠点も聞いておきたいと思ったのと、会社からすぐ近くのGMOさんが会場ということもあって参加してみた。
MySQL Clusterの本も書かれている@nippondanjiこと奥野さんから、MySQL Clusterは何に向いていて、どう使えばよさを引き出せるのかを聞いたうえで、そのサポートを受けながら4年間運用されている@tsakuradaさんの実運用上のハマりどころを聞くことで、どういうところにMySQL Clusterを使えばいいのかイメージが浮かんだので、非常に今後の役に立ちそう。
発表者のみなさま、会場提供していただいたGMOのみなさまありがとうございましたm(__)m さくらのクラウド2万円分クーポンももらったし、GMOクラウドのキャラクタのシールもたくさんもらったので宣伝しますｗ
既にまとめはgarage-kid さんが書いてくれている ので、これは個人的なポイントのまとめ。
@RKajiyama さん MySQL Cluster大地に立つ！「5.6とは違うのだよ、5.6とは！」
MySQL Clusterの概要
使用しているユーザ
元々はモバイル通信の位置情報をリアルタイムかつ高可用性を持って保存するためにできた
SQLインタフェースは昨今ゲーム業界などで使われ始めてから追加されてきた機能
艦○れでも使われている？
@nippondanji さん カジュアルにMySQL Clusterを使ってみようデータノード、SQLノード、管理ノードの3種類からなる
1台だけならndb(MySQL Clusterのエンジン)よりInnoDBの方が速い
ただしNDB APIを使うならClusterの方が圧倒的に速い
ノードを増やすとスケールしていく点に優位性があるが、いつでも速くなるとは限らない(後述)
新しいバージョン使いましょう
シェアードナッシング型
データノードは2台ペアでノードグループを構成
データをフラグメントに分けて、それをノードグループ内で同期レプリする
RAID10的な感じでグループ内で1台落ちてもデータは保全される
InnoDBとは特性が違う & いつでもノードを増やせばスケールするとは限らない
主キーを使った検索 → データノード数に応じてスケール
(少数の行を取ってくる)スキャンは苦手
データがノードに分散しているので複数ノードをスキャンする必要があるため
フェッチするレコードが多いと並列処理できるので早くなる
Engine Condition Pushdown : where句部分を丸ごとデータノードに渡して並列処理して高速化する仕組み
sysbenchをただ走らせると遅いのはこのせい
ユーザ定義パーティション
スキャンを高速化させる仕組み
2つのテーブルの関連を考慮してデータノードへの分散を定義すれば、読み書きを特定のノードに抑えられるので高速に
レプリケーション
ndbに不得意な処理があるならInnoDB のスレーブを作るという手もあるデータノードが書き込みしたことをSQLノードに通知し、それをbinlogに書き込んでスレーブに送るという仕組み
通知を受け取るのがbinlog injector thread
インメモリDBだけど永続化処理が多いのでディスク書き込み多い＝速いディスクがいい blobを別テーブルに保存するのでJOIN的処理が発生して遅くなる
NoSQLインタフェースを使えば爆速
各種言語のインタフェースあり
InnoDBのmemcachedインタフェースよりMySQL Clusterの方が現時点では賢い
まとめ(MySQL Clusterの使いどころ)
大量の更新をさばきたい
HA機能が欲しい
高速JOINしたい
@tsakurada さん MySQL Clusterと丸４年の付き合いを振り返ってのよもやま話と、Version 7.3への期待（もっとユーザが増えるといいな～）使用開始時の期待と使ってみたギャップ、現在の期待
インメモリだから速いはず
参照に関していえばFIO+InnoDBでも変わらないかも
スケールアウト簡単
高可用性
ライセンスがGPLでオープンソース
7.3でInnoとの互換性が上がって期待
サーバの構成
SQLノードと管理ノードは同居してもよい、データノード2台と合わせて最低4台からが現実的
データが多いならデータノードを増やす(が制約はあるので注意)
アクセスが多いならSQLノードを増やす。制約は少ないので割と簡単
せっかくのMySQL ClusterなんだからHW構成上もSPOFを減らそう
クエリがキャンセルされた時それを検出して後続処理をやるアプリ作り込み必須
InnoDBとの組み合わせ
Innoと同じ感覚でテーブル設計してもよいか？
場合による。最近のバージョンではやってみる価値あり
InnoDBスレーブとの組み合わせ
ハマりどころ(資料が詳しいのでそちら参照)
GCP Stop
ローリングリスタート
ボトルネックが見えづらい
データのライフサイクルを考えよう
リストアが大変
4年間でだいぶ地雷を踏んだのでもう大丈夫ｗ 皆さんMySQL Cluster使いましょう
@yyamasaki1 さん MySQL Cluster Auto-InstallerのデモAuto-Installer簡単なので使いましょう
ブラウザベースでぽちぽちやればインストール可能
初期パラメータをいくつかいじった方がいい
@yoku0825 さん ウチがNDBCLUSTERを使わない理由をもう一度考えるMySQL Clusterというと紛らわしいので、NDB Clusterと言いましょう<table border=0>
</table>
