ここのところ、ビッグデータだ、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さんはイロイロとネタが豊富な感じで楽しげだったなぁ。
ガッツリスターウォーズとか。
