狠狠撸

MySQLの冗長化
～無停止運用を実現するには～

株式会社ハートビーツ運用エンジニア松崎慶彦

? MATSUZAKI Yoshihiko 2013.1.24

自己紹介
? 松崎慶彦 (MATSUZAKI Yoshihiko)
? 株式会社ハートビーツ運用エンジニア
? MSP(サーバ運用?監視)の会社
? 24時間有人監視を提供している
? ベンダ非依存なサーバ運用(どこでもやる)
? 普段やっている業務
? サービス特性に合ったインフラの設計?構築
? サービス特性に合った運用の設計
? すでに動いているサービスの移設


MySQL
? 世界シェアトップのオープンソースRDBMS
? 導入が楽
? 枯れているので運用も楽
? 十分に高速
? 開発が活発でどんどん新機能が増えている


MySQLの最新情報

http://dev.mysql.com/


MySQLを使う上で大事なこと
? ちゃんとしたスキーマ設計
? ちゃんとしたクエリ設計
? パフォーマンスはほとんどここで決まる


MySQL冗長化についての要望
? 動作を速くしてほしい！
? 負荷を下げてほしい！
? 無停止にしてほしい！
? データをロストさせたくない！
? 無停止でバックアップを取りたい！
? いざというときにスケールさせたい！
? でもアプリはなるべく変更したくない……
? スキーマやクエリはなかなか変えられない


MySQLの冗長化手段
? MySQL Cluster
? DRBD
? MySQL Replication


MySQL Cluster
? 監視?起動?停止?復旧まで自動でやってくれる
? クラスタウェアが不要でmysqldだけで動作する
? マスターの負荷分散ができる
? トランザクション分離レベルやインデックスの制限がある
? スキーマ設計?クエリ設計での配慮が必要になる


トランザクション分離レベル
? 待ち時間と一貫性のトレードオフ
? 分離レベルが高いほど一貫性が強く待ち時間が長くなる
? 分離レベルが低いと起きる現象
? Dirty Read
? 並列実行されている別トランザクションによる
未コミットの更新を読み込んでしまう
? Non-Repeatable Read
コミット済みのレコード変更を読み込んでしまう
? Phantom Read
コミット済みのレコード追加?削除を読み込んでしまう


トランザクション分離レベル
? SERIALIZABLE
? 他トランザクションのコミットの影響を受けない
? REPEATABLE READ
? 参照中レコードのみ他トランザクションの影響を受けない
? Phantom Read
? READ COMMITTED ←MySQL Clusterで使用できるのはこれのみ
? 他トランザクションのコミット済みデータを読み込む
? Non-Repeatable Read, Phantom Read
? READ UNCOMMITTED
? 他トランザクションの未コミットデータを読み込む
? Dirty Read, Non-Repeatable Read, Phantom Read


DRBD
? ネットワーク越しにブロックデバイスをミラーリング
? ネットワークのレイテンシの影響を受けやすい
? コア機能がカーネルモジュール
? クラウドでは採用しにくい
? Failoverの仕組みを別に用意する必要がある


MySQL Replication
? マスターで実行したSQLをスレーブでも実行することで
データを複製する
? 最も導入が簡単
? スキーマやクエリの制限もほとんどない
? Failoverの仕組みを別に用意する必要がある


Replication


レプリケーションの仕組み


ログポジション
? スレーブがバイナリログを読み込み始める位置
? CHANGE MASTER文で指定する


ログポジションを誤ると…
? データが抜け落ちてしまう
? 抜け落ちたデータへのUPDATEやDELETEで壊れる


ログポジションを誤ると…
? データが二重で更新されてしまう
? UNIQUEなキーを含んでいると失敗して壊れる


レプリケーションの注意点
? スレーブに書き込むと壊れる
? スレーブのread_onlyを有効にする
? ログポジションに十分気を付ける
? 不整合が起きるまでエラーがないので気付けない
マスターが更新されていない状態で取得する
? なるべく自分で入力しない
? mysqldump --master-data
? GTID (after MySQL 5.6)
? 壊れたら再構築するしかないので慎重に…


準同期レプリケーション
? 準同期 (Semi-Synchronous)
? I/Oスレッドは同期
? SQLスレッドは非同期
? after MySQL 5.5

? スレーブへのバイナリログ転送が保証される


準同期レプリケーションの仕組み


準同期レプリケーションの注意点
? 複数台のスレーブがある場合
1台がAckを返した時点でCOMMIT完了になる
? 用途に応じて構成を決める
? マスターはAckを待っている間COMMITが止まる
? スレーブ障害がマスターに伝播する可能性がある
? rpl_semi_sync_master_timeoutを短くする
? Webサーバのタイムアウト時間
? ブラウザのタイムアウト時間


Failover


簡単なFailover構成の一例


Failoverの基本的な流れ
? マスターの障害を検知
? マスターを仮想IPから除外
? マスターとのレプリケーションを停止
? (新マスターに昇格するスレーブを決定)
? (新マスターのログポジションを保存)
? 新マスターに仮想IPを切り替え
? (残りのスレーブを新マスターに接続)
? MySQLとは別に実装する必要がある


MySQLまわりのFailover


MySQLまわりのFailover
? MySQL MHA
? マスターがダウンしたら最新のスレーブをマスターにする
? ManagerとNode(各DB)の構成でやや構築コストが高い
? mysqlfailover (after MySQL 5.6)
? マスターがダウンしたら最新のスレーブをマスターにする
? Pythonで書かれたMySQL公式のFailoverスクリプト
? 自前
? 最新のスレーブ判別は準同期レプリケーションで代用可能
? そんなに複雑な処理でもないのでわりと簡単に書ける


仮想IPアドレスまわりのFailover


仮想IPアドレスまわりのFailover
? LVS (keepalived)
? keepalived自身の冗長化が簡単にできる
? ヘルスチェックがTCPぐらいしかないので作り込みが必要
? スケールする構成にしやすい
? Pacemaker
? スケールする構成にできない
? HAProxy
? HAProxy自身の冗長化が自力でできない
? MySQL Proxy
? MySQL Proxy自身の冗長化が自力でできない
? 正式版リリースではない


Failoverの注意点
? 最新のデータがどこにあるかを把握する
? 準同期レプリケーション (after MySQL 5.5)
? 更新系クエリの経路を常に1つに維持する
? 復旧前の誤ったサービス復帰を防止する
? reset slave
? skip-slave-start
? chkconfig mysqld off
? 書き込み可能な状態にする
? スレーブを昇格させるときにread_onlyを外す


LVS (keepalived)


LVS (keepalived)
? 仮想IPへのアクセスを別のサーバに振り分ける
? 自分自身のFailoverができる
? 自前のスクリプトでヘルスチェックができる
? 要求定義に応じた柔軟なヘルスチェック
? 障害発生時にFailoverを発動したりもできる
? 一つの仮想IPへのアクセスを複数のサーバに振
り分けられる
? 単純なラウンドロビンだけでなく接続数を見て
ロードバランシングしたりもできる


LVS (keepalived)の設定例
virtual_server 192.168.0.1 3306 {
delay_loop 6 Failover時以外はスレーブに
lb_algo wrr
アクセスが行かないように
lb_kind DR
protocol TCP
↓sorry_serverで設定する
sorry_server 192.168.0.102 3306
real_server 192.168.0.101 3306 {
weight 1
MISC_CHECK {
misc_path "/path/to/mysql-check.sh 192.168.0.101"
misc_timeout 60 ↑
}
自前のスクリプトでヘルスチェック
}
}


スケールアウト


簡単なスケールする構成の一例
（スケールする構成への変更前）


（スケールする構成への変更後）


（更新系Failover）


（中段スレーブ障害での参照系Failover）


（スレーブ障害での切り離し?Failover）


スケールアウトの注意点
? 現用系に影響を与えないようにする
? server_idがユニークであることを担保する
? 同じserver_idのスレーブがぶら下がると壊れる
? LAN内でユニークな値を使用する
? オートスケールなら自動で書き換える
? 手動なら書き換える前に接続しないようにする
? skip-slave-start
? chkconfig mysqld off
? Replicationで実行される更新系の負荷は分散できない
? SQLスレッドはシングルスレッドなのでスケールアップでも無理
? マスターの分割


スケールアウトの注意点
? 無停止で稼働中のスレーブを増やす
? mysqldump --single-transaction --master-data
? MyISAMでやるとテーブルロックで障害になる
? 仮想化基盤の機能でクローン
? データの一貫性を保証する必要がある
? 理想はクローン用のスタンバイ機
? サービスに組み込まない
? 一貫性のあるクローンが影響なく素早く取れる
? 予算と相談……


実運用


実運用で大切なこと
? データサイズ
? 大きくなるとスケールが難しくなる
? ダンプ時間
? リストア時間
? クローン時間
? 目安は大きくても20GB程度
? マスター分割
? 不要データの定期削除
? バイナリログのサイズ
? InnoDBログのサイズ


実運用で大切なこと
? とにかく事前にテストをする
? すべてのDBサーバのダウンについて検証する
? 実際のスキーマ?実際の負荷で検証する
? 何を重視するか探って設計の着地点を見つける
? 無停止性
? データロストの回避
? 運用コスト
? 予算
? スケジュール


まとめ
? 完全な無停止（停止時間ゼロ）はできない
? どんな構成でもだいたい十数秒はかかる
? できるだけ迅速に復旧できる体制作り
? サーバだけでなく人も
? さまざまな条件の中で落とし所を見つける
? 条件は技術的なことだけではない


ご清聴ありがとうございました。

狠狠撸

MySQLの冗長化 2013-01-24

Recommended

More Related Content

What's hot (20)

Viewers also liked (11)

Similar to MySQLの冗長化 2013-01-24 (20)

Recently uploaded (13)

MySQLの冗長化 2013-01-24