MySQLの冗長化 2013-01-24

34,602 views
34,143 views

Published on

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

Published in: Technology
1 Comment
141 Likes
Statistics
Notes
No Downloads
Views
Total views
34,602
On SlideShare
0
From Embeds
0
Number of Embeds
1,108
Actions
Shares
0
Downloads
270
Comments
1
Likes
141
Embeds 0
No embeds

No notes for slide

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ご清聴ありがとうございました。

×