僕らのmysql5.6移行記(仮)
DESCRIPTION
MySQL Casual Talks#5で発表した資料ですTRANSCRIPT
僕達のMySQL5.6移行記
星野 豊 (@con_mame)
クックパッド株式会社 インフラストラクチャー部
AWS / MySQL / Redshift / DataStore etc...
http://d.conma.me/
http://facebook.com/conmame
5.6
使ってますか？
5.6.10 or 5.6.13
or
5.6.14
MySQL on EC2
and
RDS
NEW
NEW
update
update
Management tools
Development
Analysis (exclude secure
table / with mysql-
audit)
Move to 5.6 on AWS
5.6.6～ (2012/8/7)
cookpad 主要DBを5.6に
update
Replicationをしつつ本番で
流れるクエリを流す
5.6 新機能のConfiguration
を試していく
cookpad 主要DBを5.6に
update
Replicationをしつつ本番で
流れるクエリを流す
5.6 新機能のConfiguration
を試していく
意外と素直に進んだ！！！
cookpad 主要DBを5.6に
update
Replicationをしつつ本番で
流れるクエリを流す
5.6 新機能のConfiguration
を試していく
意外と素直に進んだ！！！
最初だけ意外と素直に進んだ！！！
Upgrade
5.6 DB群を用意してswitch
メンテナンスでmysql_upgrade
replication
OLDMaster
OLDSlave
OLDSlave
5.6Master
5.6Slave
replication
5.6Slave
replication
OLDMaster
OLDSlave
OLDSlave
5.6Master
5.6Slave
replication
5.6Slave
EBS Snapshotを
作成して5.6群を
作成
replication
OLDMaster
OLDSlave
OLDSlave
5.6Master
5.6Slave
replication
5.6Slave
検証
正常にmysql_upgradeが出来るか
既存スキーマ・クエリでwarningとか出ないか
パフォーマンス
レプリケーションはうまいこと行くか
新機能・パラメータどうするか
アプリケーションサーバなどのライブラリ
運用
BUG
正常にmysql_upgradeが出来るか
既存スキーマ・クエリでwarningとか出ないか
パフォーマンス
レプリケーションはうまいこと行くか
新機能・パラメータどうするか
アプリケーションサーバなどのライブラリ
運用
BUG
アプリケーションサーバなどのライブラリ・
動作
libmysql / mysql2 gem / log
パフォーマンス
slow query / レスポンス速度 / CPU /
memory
既存スキーマ・クエリでwarningとか出ないか
新パラメータとかでDEPRECATEDなものがな
いか
Kage
https://github.com/cookpad/kagehttps://rubygems.org/gems/kage
OLDDB M
proxy
kage
app newapp
OLDDB S
5.6DB M
5.6DB S
OLDDB M
proxy
kage
app newapp
OLDDB S
5.6DB M
5.6DB S
ライブラリ
アプリケーションの動作
OLDDB M
proxy
kage
app newapp
OLDDB S
5.6DB M
5.6DB S
ライブラリ
アプリケーションの動作
warning
チューニング・動作
実際のリクエストで発行されるクエリでテストが行える
漏れが少なくread / writeを実際に動作をさせながら
確認出来る
DB自体の負荷試験は別途行う
テストが行い易くアプリケーション・DB各レイヤーで問
題を見つけやすい・直しながらテスト出来る
他にも
開発・検証用のDBとしてバージョン・設定を変えて動作
させる
開発中のクエリは実際に使用される事が予測される
今後のバージョンアップで問題が出ないか確認しやす
い
バージョンを上げた場合にindexの使われ方が変わるな
どを見つけやすい
MySQLのパフォーマンス向上により調査クエリが高速化
することも
用意している環境
超検証用 (5.6.14 / 5.7.x) -> 主にcon_mame用
検証用 (5.6.13) -> 開発用DB / 調査用DB
本番 (5.6.x) -> 本番 / CI
役割
超検証用 -> BUG調査や新機能・チューニング検証用
検証用 -> 本番データをレプリケーションして開発中
や調査用のクエリを受け付けさせて様子を見る。問題
があれば超検証用インスタンスで調査
replication
productionMaster
5.6 or 5.5 or older...
超検証用 検証用 本番
5.6.10 5.6.11 5.6.12 5.7.x5.6.13
EBS SnapshotとAMIで問題が起こったバー
ジョンを直ぐに起動して調査
本番サーバのEBSは一定
時間おきにSnapshotが
とられている
正常にmysql_upgradeが出来るか
既存スキーマ・クエリでwarningとか出ないか
パフォーマンス
レプリケーションはうまいこと行くか
新機能・パラメータどうするか
アプリケーションサーバなどのライブラリ
運用
BUG
5.6
GTID
運用負荷が意外と大きい
http://d.conma.me/entry/2013/04/23/203036
デフォルト値の変更や非推薦な物
explicit_defaults_for_timestamp
binlog_checksum とかとか
http://dev.mysql.com/doc/refman/5.6/en/upgrading-
from-previous-series.html
Performance Schemeメモリ食いまくり
ピークタイムでレプリケーションエラー起こったら
この手順は…
5.6
5.5
BUG (体験済の一部orz)
mysql.slave_master_info is not updated http://
bugs.mysql.com/bug.php?id=69135
A regression in 5.6 crash recovery atomicity
http://bugs.mysql.com/bug.php?id=68932
memory leak with innodb memcached plugin for stale
connection http://bugs.mysql.com/bug.php?id=68530
replication was broken while executing flush
tables http://bugs.mysql.com/bug.php?id=69045
Invalid use of GRANT command breaks replication
http://bugs.mysql.com/bug.php?id=68892
Conclusion
5.6はそろそろ気軽に使えるようになった
GTID... / Performance Scheme....
AWS上で検証するなら、Casualに検証できる
EBS Snapshot / AMI
検証はしっかりと
Kage便利
5.6はそろそろ気軽に使えるようになった
GTID... / Performance Scheme....
AWS上で検証するなら、Casualに検証できる
EBS Snapshot / AMI
検証はしっかりと
Kage便利
http://bugs.mysql.com/
見てますよね？
Thank you!!