My sqlのha構成について
•
29 likes•7,543 views
社内というか部内向けに説明した資料です。
Report
Share
Related slideshows
My sqlのha構成について
- 2. 形あるものは必ず壊れるのでリカバリが必要 止められないサービスなら切り替わる必要がある 復旧にかかる時間を自動化により削減したい サービス断時間を少なく抑え機会損失を防ぐ 復旧操作の自動化により人によるオペーレーション の不確実性を緩和 復旧時の人的リソースを削減できる データの保全性を向上 ※HA構成はバックアップの代用にはなりません （オペレーションミスもレプリケーションされるためです）
- 3. 従来の冗長構成(heartbeat+mon+mysql) MHA(mysql5.5まで) mysqlfailover(Mysql5.6以降) (費用的に)需要が少ないが以下構成も可能 • AmazonRDS（現在MySQL5.5まで、排他制御） • Heartbeat-v3+SharedDisk構成(排他制御) ※PostgreSQL,MySQL+VP+Spider,GaleraReplication等は取り扱い実績がございません ※負荷分散の扱い可能なのは、LVS,Haproxy,ELBになります。
- 4. 構成概要 メリット デメリット・制約 Heartbeat1+mon+mysql 管理ノード不要 最も実績有、慣れた運用 NW周りの監視F/Oの作りこみ不要 F/O後の構成はシングル 構成復旧の計画停止必要 F/O時のデータロスト有 MHA F/O後にreplication自動復旧 F/O後構成がシングルにならない（3台 以上の場合） 構成復旧の計画停止不要 DeNA等大手での運用実績がある 管理ノードが必要 Mysql5.5まで(2013/4現在) relay_log_purge=0必要 VIP管理は自作スクリプト 運用経験が浅い mysqlfailover F/O後にreplication自動復旧 F/O後構成がシングルにならない （3台以上の場合） 構成復旧の計画停止不要 管理ノードが必要 MySQL5.6以降でGTID有効必須 MyISAM他トランザクションセーフで ないエンジンとSQLは使用不可 VIP管理は自作スクリプト 検証のみで導入実績なし 公開情報が少なく—forceで切替 Heartbeat3+SharedDisk (DRBD)+mysql 管理ノード不要 F/O時のデータロストを防げる NW周りの監視F/Oの作りこみ不要 共有ディスクは排他制御のため待機 系にアクセス不能 F/O後の構成はシングル 構成復旧の計画停止必要 AmazonRDS 管理ノード不要 F/O時のデータロストを防げる MaltiAZ化でDR構成にできる DBA不要と言われポイントインタイムリ カバリがブラウザから可能 MaltiAZが有効でDiskI/O負荷が高い場 合にF/Oが生じやすい I/O共有で他環境の影響有 F/O後の構成はシングル 構成復旧の計画停止必要
- 9. AWS Cloud AZ（データセンタ）A RDS DB Instance RDS DB Instance Standby (Multi-AZ) RDS DB Instance Read Replica AZ（データセンタ）B Replication Multi-AZ DataShare F/O AWS Cloud AZ（データセンタ）A RDS DB Instance RDS DB Instance Read Replica AZ（データセンタ）B Replication ×
- 10. １位：SharedDisk（DRBDプロトコルCの場合） ２位：AmazonRDSとMHAとmysqlfailover同列 ３位： Heartbeat1+mon+mysql ※SharedDiskは書きこむ場所が同じのまま引き継がれるのでデータロストが他より起こりにくいです。 MHAとmysqlfailoverは最新のバイナリログを判別し反映する機能を持っている為 SemiSyncReplicationと組み合わせるとデータロストをより防ぐことが可能です。非同期の replicationとVIPの付替えのみの場合は最もデータロストが発生しやすくなります。replicationは そもそも非同期な仕組みです。RDSはバックエンドの仕組みが不明なため推測で2位としました。
- 11. １位： MHAとmysqlfailover同列 ２位：AmazonRDSとSharedDisk（DRBDプロトコル Cの場合）とHeartbeat1+mon+mysql同列 ※F/O後にシングルになるかどうか、slaveへの参照スケーラビリティが保てるかどうか のみを判別基準としています。
- 12. １位： MHAとmysqlfailover同列 ２位：AmazonRDSとSharedDisk（DRBDプロトコル Cの場合）とHeartbeat1+mon+mysql同列 ※slaveが存在する場合、F/O後シングルになる構成では整合性を担保したslaveの復旧の ためにMasterからのデータdumpを必要とするため、データ容量に応じたサービス停 止時間が必要となります。(※ストレージエンジンにもよります）
- 14. １位： Heartbeat1+mon+mysql ２位：AmazonRDS ３位： SharedDisk ４位： MHA ５位： mysqlfailover ※弊社での運用期間が長く障害対応回数が多く慣れている順です。
- 15. １位： Heartbeat1+mon+mysql ２位： MHAとmysqlfailover ３位： AmazonRDSとSharedDisk ※用意するノード数が少なくコストがかからない順になります。管理サーバはノードよりマシンス ペックが低くすみますが、DBサーバの待機系は稼働系と同様のスペックが必要となります。
- 16. 要注意ポイント メリット デメリット Replication(GTID) マスタスレーブ間で一意のGTIDを用いる為 よりトランザクションセーフでクラッシュ セーフに、マルチスレッドスレーブ、バイ ナリログのグループコミット、チェックサ ムの追加 GTIDが有効な場合、MyISAM等トランザク ションセーフでない仕組みは使用不可能(バ イナリログに記録できない) データの扱い バッファプールのダンプとリストアが可能 に、テーブルスペースの可搬性向上、オン ラインでDDL(CreateIndex他)可能に、 NoSQL API、オプティマイザ改善 Mysqldumpで旧バージョンのデータを扱う 際に--set-gtid-purged=OFF必須、 SQLモードのデフォルト値変更による挙動 の変化 パスワード管理 平文での表示を抑制する仕組み 難読化レベルであり復号化可能 パフォーマンス スレッドの同時実行性能向上 単純なクエリが高速に、SSD最適化 参照専用トランザクションで参照が高速化 サーバパラメータに変更がない場合やアプ リや環境次第で遅くなるという情報もある PerformanceSchema OptimizaTraceが可能に ブロックされたホスト等特定可能に他パ フォーマンス統計情報の取得 約１割ほどのオーバーヘッドが生じる その他の主なメリット デフォルト設定の最適化、パーティショニングの改善