MySQL HA reloaded@IGN Entertainmentに行ってきました

ここのところ、ビッグデータだ、Hadoopだ、MongoDBだ、Cassandraだっていう世の中ですが、
まぁRDBMSは最終的にっていうか、いくつになっても使い続けるんだろうなぁって気がしています。
　
自分はDB屋さんではないですが、なんとなく今やってる事が最適解じゃないように思うけど、じゃあどうすりゃイイの？っていうのが
心の奥底でくすぶっているのもあって↓に行ってみることにしました。(名前からしてソソられますよね)
MySQL HA reloaded – old tricks and cool new tools to guarantee high availability
　
■ 会場(IGN Entertainmentさん)
鉄拳あるし他にもアーケードゲームがチラホラある遊び心のあるナイスなオフィス。

今日はピザではなく、チキン的なスゲー辛いｗ

そんなこんなではじまるよーってコミュニティの主催者っぽい人から、
他と同じようにｘｘがスポンサーになってくれて感謝してます的な。

　
　
■ MySQL HAの話
SkySQLのIVAN ZORATTIさん。イタリア人とかかな？英語のアクセントが独特だけどゆっくりで聞きやすかったです。
お題は↓こんな感じ
– A bit of theory
– High availability solutions
– famous last words
　
　
■ SkySQL
90%の従業員はオリジナルのMySQLの人たち、エンプラ系のコンサルとかトレーニングで稼いでるらしい。
扱ってる周辺プロダクトとか知らないのばっかりだったなぁ。

　
　
■ High Availabilityとは？
90%なのか、99.9%なのか、99.99%なのか、、、99.9999%なのか、的な。
100%はキツイよねぇ。年間何分とかって計算するとFive ninesも結構頑張らないと。
Fault-tolerantとかSwitchover/Failoverとか用語についてサラっと。

DowntimeとかSPOFってのはこういう事だよなんていうベーシックなところも。

一個のラックにサーバ突っ込んでラックが逝っちゃってーなんていうエピソードとか。
自然災害とかそういうのもあるしね、と。
　
ってことで、どうやってHigh Availabilityなシステムをどうやってデザインするか？と。

　
AvailabilityとScalabilityどっち大事？とか、お金もかかるし、DBだけ良けりゃいいってもんじゃないし。
もっかいSLAを見直しましょう、と。

そんなこんなで概要的なお話は終わって、いよいよMySQLに関する話。
　
　
■ High Availability Solutions with MySQL
↓こんな感じで堅牢かなって言う事で、詳細を説明しますよ、と。
SharedNothingなDistributedCluster＞地理的に離れたレプリケーション＞Active/PassiveなCluster＞普通のReplication

　
　
– Replication
binlogとrelaylogとか。伝播遅延があるんだよんって。
Antelope vs Barracuda(ファイルフォーマット。Barracudaがコンパクション機能があるそうで)
Multiple-engineには気をつけろ、と。MySQLだけがinnodbと他のストレージエンジンを併用できるんだけど、注意が必要。
Rolling Upgradesしてくのが定石。設定変えて再起動とかなったときに。
　
　
– Multi-Master replication Manager(通称MMM)
あんま評判よくないみたい。Perlのスクリプトらしいんだけど。

　
　
– Master High Availability(通称MHA)
会場でも使った事ある人全然いないけど結構いいよ、と。
Promotion to Masterがとてもスムーズでstableなソリューションだそうです
Master-Masterは出来ないってのがポイント。Master IP Failover。

　
　
– Percona MySQL Replication Manager
Based on Pacemakerって事なんだけど、Pacemakerもなんだか知らず。。
MMMに似てて、MHAを補うっていう感じなんですかね。
URLは→http://www.percona.com/software/
　
　
– Tungsten Repicator
GPLライセンス。マルチマスタで、スキーマごとにマルチスレッドでパラレルなレプリケーションが出来るらしい。

　
　
– Tungsten Enterprise
商用でReplicator+Monitor。
Client Connector with R/W split and load balancing。ほほぅ、って感じ。

　
　
– Syncronous Replication with DRBD
Active/Passive DRBDはMySQLやSunが手厚くやってたのにOracleがねぇ、、みたいな。
Writeのパフォーマンスに気をつけましょうな。InnoDBでしか使えません。

InnoDBのバッファプールがどうの？って質問があって → おっしゃる通りでconsiderしなきゃだよ、と。

　
　
– Syncronous Replication with Galera
Multi-masterでNo SPOFだぜぃ、と。
JDBCコネクタはお利口だからイイ感じに動くそうで。
あとは、なんかあんまよくわからなかったけどスケールしにくいって言ってたのかな。。

　
　
– SchoonerSQL
Not Open Source。最新なソリューション。レイテストなプロダクトは注意が必要的な。
Synchronous Master-Slave replication for InnoDB

　
　
– Active/Passive Clusters through Shared Storage
イケてる共有ディスクを使う、割りと一般的な感じだやね、と。
とにかく金かかるし、あんまり最近の人は好まない。

自分のいる会社でもよくみかける感じ。

仮想化とか。

　
　
– Geographical Replication for Desaster Recovery
バックアップ用のデータセンターで、なんかあったらネットワークをリダイレクトするとか。
　
　
　
– MySQL Cluster
difficultだけど、使いこなせればナイスだね、と。インデックスはメモリ上。
Lowレイテンシで早い。全ての要素がRedundant。複数クラスタをコンバイニングするのがナイスなソリューションだぜ、と。
GPLだからソースもみれるし。

　
　
– Client-based Failover and Proxies
Connector/Jとか、mysqlnd_ms for PHPとか、ScaleBaseとか。
＃もうちょい突っこんだ話聞きたかったけど、データベースの勉強会だったからクライアント側はあんまり質問も出ず…

　
　
– last words
How many nines?っていう表現。Everything must be automatic。
MySQLクラスタはナイスだけど移行するの大変だから、そこの見極めをちゃんとしましょうね、と。

　
　
以下、質問のやりとりとかで耳に入ってきたネタ達。
—
そんなにガッツリしたのじゃなければ(5台くらいなら)、普通のReplicationで良ければそれがベストなソリューションだけど、
それでダメな場合はDRBDとかが良さげだけどInnoDBしか使えなかったりするから気をつけようね。
あと、50台のMySQLサーバなら1人のDBAで面倒みれるし、俺やってるぜ的な発言とか。
　
—
Oracleはローンチ直前まで情報出してくれなかったりしてツライやねぇ。
端々にOracleに対するちょっとした小言が入ってて、そういう雰囲気なんだなってのが伺える感じでした。
　
—
ファイルのサイズ小さくしたいんだけど、innoDBでファイルサイズをコントロール出来ない。rsyncでホゲホゲしてっからさー的な。
Oracleも一緒だけど、その辺はちょっと出来ないのでパーティション化するしかない。
　
—
Rolling Upgrade
Typical Approach For Master/Slave
→50台のスキーマ変更をローリングでやってる。MySQLそのものをアップデートではない。
　お前はスゲー忙しいのか？自動でスクリプトにやらせてるのか？なんて議論になってきて、
　なんか白熱してよくわかんなくなっちゃった…。HA Proxy(TCP LoadBalancer)だDynamicDNSだアレヤコレヤと…ｗ
　
—
IGN Entertainmentさんはイロイロとネタが豊富な感じで楽しげだったなぁ。

ガッツリスターウォーズとか。

　
　