Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MySQLの冗長化 2013-01-24

36,182 views

Published on

<SKILL BASECAMP 2013>
MySQLの冗長化~無停止運用を実現するには~
http://www.pasonatech.co.jp/entry/index.jsp?mode=2&d=on&no=3756

Published in: Technology

MySQLの冗長化 2013-01-24

  1. 1. MySQLの冗長化~無停止運用を実現するには~ 株式会社ハートビーツ 運用エンジニア 松崎 慶彦
  2. 2. © MATSUZAKI Yoshihiko 2013.1.24自己紹介• 松崎 慶彦 (MATSUZAKI Yoshihiko)• 株式会社ハートビーツ 運用エンジニア ▫ MSP(サーバ運用・監視)の会社 ▫ 24時間有人監視を提供している ▫ ベンダ非依存なサーバ運用(どこでもやる)• 普段やっている業務 ▫ サービス特性に合ったインフラの設計・構築 ▫ サービス特性に合った運用の設計 ▫ すでに動いているサービスの移設
  3. 3. © MATSUZAKI Yoshihiko 2013.1.24MySQL• 世界シェアトップのオープンソースRDBMS• 導入が楽• 枯れているので運用も楽• 十分に高速• 開発が活発でどんどん新機能が増えている
  4. 4. © MATSUZAKI Yoshihiko 2013.1.24MySQLの最新情報 http://dev.mysql.com/
  5. 5. © MATSUZAKI Yoshihiko 2013.1.24MySQLを使う上で大事なこと• ちゃんとしたスキーマ設計• ちゃんとしたクエリ設計▫ パフォーマンスはほとんどここで決まる
  6. 6. © MATSUZAKI Yoshihiko 2013.1.24MySQL冗長化についての要望• 動作を速くしてほしい!• 負荷を下げてほしい!• 無停止にしてほしい!• データをロストさせたくない!• 無停止でバックアップを取りたい!• いざというときにスケールさせたい!• でもアプリはなるべく変更したくない……▫ スキーマやクエリはなかなか変えられない
  7. 7. © MATSUZAKI Yoshihiko 2013.1.24MySQLの冗長化手段• MySQL Cluster• DRBD• MySQL Replication
  8. 8. © MATSUZAKI Yoshihiko 2013.1.24MySQL Cluster• 監視・起動・停止・復旧まで自動でやってくれる• クラスタウェアが不要でmysqldだけで動作する• マスターの負荷分散ができる• トランザクション分離レベルやインデックスの制限がある ▫ スキーマ設計・クエリ設計での配慮が必要になる
  9. 9. © MATSUZAKI Yoshihiko 2013.1.24トランザクション分離レベル• 待ち時間と一貫性のトレードオフ ▫ 分離レベルが高いほど一貫性が強く待ち時間が長くなる• 分離レベルが低いと起きる現象 ▫ Dirty Read  並列実行されている別トランザクションによる 未コミットの更新を読み込んでしまう ▫ Non-Repeatable Read  並列実行されている別トランザクションによる コミット済みのレコード変更を読み込んでしまう ▫ Phantom Read  並列実行されている別トランザクションによる コミット済みのレコード追加・削除を読み込んでしまう
  10. 10. © MATSUZAKI Yoshihiko 2013.1.24トランザクション分離レベル• SERIALIZABLE ▫ 他トランザクションのコミットの影響を受けない• REPEATABLE READ ▫ 参照中レコードのみ他トランザクションの影響を受けない ▫ Phantom Read• READ COMMITTED ←MySQL Clusterで使用できるのはこれのみ ▫ 他トランザクションのコミット済みデータを読み込む ▫ Non-Repeatable Read, Phantom Read• READ UNCOMMITTED ▫ 他トランザクションの未コミットデータを読み込む ▫ Dirty Read, Non-Repeatable Read, Phantom Read
  11. 11. © MATSUZAKI Yoshihiko 2013.1.24DRBD• ネットワーク越しにブロックデバイスをミラーリング ▫ ネットワークのレイテンシの影響を受けやすい• コア機能がカーネルモジュール ▫ クラウドでは採用しにくい• Failoverの仕組みを別に用意する必要がある
  12. 12. © MATSUZAKI Yoshihiko 2013.1.24MySQL Replication• マスターで実行したSQLをスレーブでも実行することで データを複製する• 最も導入が簡単• スキーマやクエリの制限もほとんどない• Failoverの仕組みを別に用意する必要がある
  13. 13. © MATSUZAKI Yoshihiko 2013.1.24Replication
  14. 14. © MATSUZAKI Yoshihiko 2013.1.24レプリケーションの仕組み
  15. 15. © MATSUZAKI Yoshihiko 2013.1.24レプリケーションの仕組み
  16. 16. © MATSUZAKI Yoshihiko 2013.1.24レプリケーションの仕組み
  17. 17. © MATSUZAKI Yoshihiko 2013.1.24レプリケーションの仕組み
  18. 18. © MATSUZAKI Yoshihiko 2013.1.24レプリケーションの仕組み
  19. 19. © MATSUZAKI Yoshihiko 2013.1.24ログポジション• スレーブがバイナリログを読み込み始める位置▫ CHANGE MASTER文で指定する
  20. 20. © MATSUZAKI Yoshihiko 2013.1.24ログポジションを誤ると…• データが抜け落ちてしまう▫ 抜け落ちたデータへのUPDATEやDELETEで壊れる
  21. 21. © MATSUZAKI Yoshihiko 2013.1.24ログポジションを誤ると…• データが二重で更新されてしまう▫ UNIQUEなキーを含んでいると失敗して壊れる
  22. 22. © MATSUZAKI Yoshihiko 2013.1.24レプリケーションの注意点• スレーブに書き込むと壊れる▫ スレーブのread_onlyを有効にする• ログポジションに十分気を付ける▫ 不整合が起きるまでエラーがないので気付けない マスターが更新されていない状態で取得する▫ なるべく自分で入力しない  mysqldump --master-data▫ GTID (after MySQL 5.6)• 壊れたら再構築するしかないので慎重に…
  23. 23. © MATSUZAKI Yoshihiko 2013.1.24準同期レプリケーション• 準同期 (Semi-Synchronous) ▫ I/Oスレッドは同期 ▫ SQLスレッドは非同期• after MySQL 5.5• スレーブへのバイナリログ転送が保証される
  24. 24. © MATSUZAKI Yoshihiko 2013.1.24準同期レプリケーションの仕組み
  25. 25. © MATSUZAKI Yoshihiko 2013.1.24準同期レプリケーションの仕組み
  26. 26. © MATSUZAKI Yoshihiko 2013.1.24準同期レプリケーションの仕組み
  27. 27. © MATSUZAKI Yoshihiko 2013.1.24準同期レプリケーションの仕組み
  28. 28. © MATSUZAKI Yoshihiko 2013.1.24準同期レプリケーションの仕組み
  29. 29. © MATSUZAKI Yoshihiko 2013.1.24準同期レプリケーションの注意点• 複数台のスレーブがある場合 1台がAckを返した時点でCOMMIT完了になる ▫ 用途に応じて構成を決める• マスターはAckを待っている間COMMITが止まる ▫ スレーブ障害がマスターに伝播する可能性がある ▫ rpl_semi_sync_master_timeoutを短くする  Webサーバのタイムアウト時間  ブラウザのタイムアウト時間
  30. 30. © MATSUZAKI Yoshihiko 2013.1.24Failover
  31. 31. © MATSUZAKI Yoshihiko 2013.1.24簡単なFailover構成の一例
  32. 32. © MATSUZAKI Yoshihiko 2013.1.24簡単なFailover構成の一例
  33. 33. © MATSUZAKI Yoshihiko 2013.1.24簡単なFailover構成の一例
  34. 34. © MATSUZAKI Yoshihiko 2013.1.24簡単なFailover構成の一例
  35. 35. © MATSUZAKI Yoshihiko 2013.1.24簡単なFailover構成の一例
  36. 36. © MATSUZAKI Yoshihiko 2013.1.24Failoverの基本的な流れ• マスターの障害を検知• マスターを仮想IPから除外• マスターとのレプリケーションを停止• (新マスターに昇格するスレーブを決定)• (新マスターのログポジションを保存)• 新マスターに仮想IPを切り替え• (残りのスレーブを新マスターに接続)• MySQLとは別に実装する必要がある
  37. 37. © MATSUZAKI Yoshihiko 2013.1.24MySQLまわりのFailover• マスターの障害を検知• マスターを仮想IPから除外• マスターとのレプリケーションを停止• (新マスターに昇格するスレーブを決定)• (新マスターのログポジションを保存)• 新マスターに仮想IPを切り替え• (残りのスレーブを新マスターに接続)
  38. 38. © MATSUZAKI Yoshihiko 2013.1.24MySQLまわりのFailover• MySQL MHA ▫ マスターがダウンしたら最新のスレーブをマスターにする ▫ ManagerとNode(各DB)の構成でやや構築コストが高い• mysqlfailover (after MySQL 5.6) ▫ マスターがダウンしたら最新のスレーブをマスターにする ▫ Pythonで書かれたMySQL公式のFailoverスクリプト• 自前 ▫ 最新のスレーブ判別は準同期レプリケーションで代用可能 ▫ そんなに複雑な処理でもないのでわりと簡単に書ける
  39. 39. © MATSUZAKI Yoshihiko 2013.1.24仮想IPアドレスまわりのFailover• マスターの障害を検知• マスターを仮想IPから除外• マスターとのレプリケーションを停止• (新マスターに昇格するスレーブを決定)• (新マスターのログポジションを保存)• 新マスターに仮想IPを切り替え• (残りのスレーブを新マスターに接続)
  40. 40. © MATSUZAKI Yoshihiko 2013.1.24仮想IPアドレスまわりのFailover• LVS (keepalived) ▫ keepalived自身の冗長化が簡単にできる ▫ ヘルスチェックがTCPぐらいしかないので作り込みが必要 ▫ スケールする構成にしやすい• Pacemaker ▫ スケールする構成にできない• HAProxy ▫ HAProxy自身の冗長化が自力でできない• MySQL Proxy ▫ MySQL Proxy自身の冗長化が自力でできない ▫ 正式版リリースではない
  41. 41. © MATSUZAKI Yoshihiko 2013.1.24Failoverの注意点• 最新のデータがどこにあるかを把握する ▫ 準同期レプリケーション (after MySQL 5.5) ▫ 更新系クエリの経路を常に1つに維持する• 復旧前の誤ったサービス復帰を防止する ▫ reset slave ▫ skip-slave-start ▫ chkconfig mysqld off• 書き込み可能な状態にする ▫ スレーブを昇格させるときにread_onlyを外す
  42. 42. © MATSUZAKI Yoshihiko 2013.1.24LVS (keepalived)
  43. 43. © MATSUZAKI Yoshihiko 2013.1.24LVS (keepalived)• 仮想IPへのアクセスを別のサーバに振り分ける• 自分自身のFailoverができる• 自前のスクリプトでヘルスチェックができる ▫ 要求定義に応じた柔軟なヘルスチェック ▫ 障害発生時にFailoverを発動したりもできる• 一つの仮想IPへのアクセスを複数のサーバに振 り分けられる ▫ 単純なラウンドロビンだけでなく接続数を見て ロードバランシングしたりもできる
  44. 44. © MATSUZAKI Yoshihiko 2013.1.24LVS (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 ↑ } 自前のスクリプトでヘルスチェック }}
  45. 45. © MATSUZAKI Yoshihiko 2013.1.24スケールアウト
  46. 46. © MATSUZAKI Yoshihiko 2013.1.24簡単なスケールする構成の一例(スケールする構成への変更前)
  47. 47. © MATSUZAKI Yoshihiko 2013.1.24簡単なスケールする構成の一例(スケールする構成への変更後)
  48. 48. © MATSUZAKI Yoshihiko 2013.1.24簡単なスケールする構成の一例(更新系Failover)
  49. 49. © MATSUZAKI Yoshihiko 2013.1.24簡単なスケールする構成の一例(更新系Failover)
  50. 50. © MATSUZAKI Yoshihiko 2013.1.24簡単なスケールする構成の一例(更新系Failover)
  51. 51. © MATSUZAKI Yoshihiko 2013.1.24簡単なスケールする構成の一例(更新系Failover)
  52. 52. © MATSUZAKI Yoshihiko 2013.1.24簡単なスケールする構成の一例(中段スレーブ障害での参照系Failover)
  53. 53. © MATSUZAKI Yoshihiko 2013.1.24簡単なスケールする構成の一例(中段スレーブ障害での参照系Failover)
  54. 54. © MATSUZAKI Yoshihiko 2013.1.24簡単なスケールする構成の一例(中段スレーブ障害での参照系Failover)
  55. 55. © MATSUZAKI Yoshihiko 2013.1.24簡単なスケールする構成の一例(スレーブ障害での切り離し・Failover)
  56. 56. © MATSUZAKI Yoshihiko 2013.1.24簡単なスケールする構成の一例(スレーブ障害での切り離し・Failover)
  57. 57. © MATSUZAKI Yoshihiko 2013.1.24簡単なスケールする構成の一例(スレーブ障害での切り離し・Failover)
  58. 58. © MATSUZAKI Yoshihiko 2013.1.24簡単なスケールする構成の一例(スレーブ障害での切り離し・Failover)
  59. 59. © MATSUZAKI Yoshihiko 2013.1.24簡単なスケールする構成の一例(スレーブ障害での切り離し・Failover)
  60. 60. © MATSUZAKI Yoshihiko 2013.1.24スケールアウトの注意点• 現用系に影響を与えないようにする• server_idがユニークであることを担保する ▫ 同じserver_idのスレーブがぶら下がると壊れる ▫ LAN内でユニークな値を使用する ▫ オートスケールなら自動で書き換える ▫ 手動なら書き換える前に接続しないようにする  skip-slave-start  chkconfig mysqld off• Replicationで実行される更新系の負荷は分散できない ▫ SQLスレッドはシングルスレッドなのでスケールアップでも無理  マスターの分割
  61. 61. © MATSUZAKI Yoshihiko 2013.1.24スケールアウトの注意点• 無停止で稼働中のスレーブを増やす▫ mysqldump --single-transaction --master-data  MyISAMでやるとテーブルロックで障害になる▫ 仮想化基盤の機能でクローン  データの一貫性を保証する必要がある• 理想はクローン用のスタンバイ機▫ サービスに組み込まない▫ 一貫性のあるクローンが影響なく素早く取れる▫ 予算と相談……
  62. 62. © MATSUZAKI Yoshihiko 2013.1.24実運用
  63. 63. © MATSUZAKI Yoshihiko 2013.1.24実運用で大切なこと• データサイズ ▫ 大きくなるとスケールが難しくなる  ダンプ時間  リストア時間  クローン時間 ▫ 目安は大きくても20GB程度  マスター分割  不要データの定期削除 ▫ バイナリログのサイズ ▫ InnoDBログのサイズ
  64. 64. © MATSUZAKI Yoshihiko 2013.1.24実運用で大切なこと• とにかく事前にテストをする▫ すべてのDBサーバのダウンについて検証する▫ 実際のスキーマ・実際の負荷で検証する• 何を重視するか探って設計の着地点を見つける▫ 無停止性▫ データロストの回避▫ 運用コスト▫ 予算▫ スケジュール
  65. 65. © MATSUZAKI Yoshihiko 2013.1.24まとめ• 完全な無停止(停止時間ゼロ)はできない▫ どんな構成でもだいたい十数秒はかかる▫ できるだけ迅速に復旧できる体制作り  サーバだけでなく人も• さまざまな条件の中で落とし所を見つける▫ 条件は技術的なことだけではない
  66. 66. © MATSUZAKI Yoshihiko 2013.1.24ご清聴ありがとうございました。

×