My sqlのha構成について

6,223 views

Published on

社内というか部内向けに説明した資料です。

Published in: Technology
  • 4枚目のスライドのMHAのデメリットは作者の方が5.6もサポートしたというツイートを見かけましたので現在は解消された模様です。
    https://twitter.com/matsunobu/statuses/335249816760246273
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

My sqlのha構成について

  1. 1. ~メリット・デメリット等~
  2. 2.  形あるものは必ず壊れるのでリカバリが必要 止められないサービスなら切り替わる必要がある 復旧にかかる時間を自動化により削減したい サービス断時間を少なく抑え機会損失を防ぐ 復旧操作の自動化により人によるオペーレーションの不確実性を緩和 復旧時の人的リソースを削減できる データの保全性を向上※HA構成はバックアップの代用にはなりません(オペレーションミスもレプリケーションされるためです)
  3. 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. 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後の構成はシングル構成復旧の計画停止必要
  5. 5. LVS1LVSDBMasterHertbeat1+monDBSlave2DBSlave1Hertbeat1VIPwebwebwebwebwebwebwritereadreplreadreplLVS1LVSDBMasterHertbeat1+monDBSlaveDBnewMasterHertbeat1VIPwebwebwebwebwebwebwritereadreplreadrepl××××F/O
  6. 6. LVS1DBMasterMHAnodeAdminMHAmanagerDBSlaveMHAnodeDBSlaveMHAnodeVIPwebwebwebwebwebwritereadreplreplreadLVSchkLVS1DBMasterMHAnodeAdminMHAmanagerDBnewMasterMHAnodeDBSlaveMHAnodeVIPwebwebwebwebwebwrite readreplreadLVS※切り替えた後に、managerも落ちますF/O
  7. 7. LVS1DBMasterMHAnodeAdminfailoverconsoleDBSlaveMHAnodeDBSlaveMHAnodeVIPwebwebwebwebwebwritereadreplreplreadLVSchkLVS1DBMasterDBnewMaster DBSlaveVIPwebwebwebwebwebwrite readreplreadLVSF/OchkAdminfailoverconsole
  8. 8. DBMasterHertbeat3DBSlaveHertbeat3VIPwebwebread/writeSharedDisk排他制御F/ODBMasterHertbeat3DBSlaveHertbeat3VIPwebwebread/writeSharedDisk
  9. 9. AWS CloudAZ(データセンタ)ARDS DBInstanceRDS DB InstanceStandby(Multi-AZ)RDS DBInstance ReadReplicaAZ(データセンタ)BReplicationMulti-AZDataShareF/OAWS CloudAZ(データセンタ)ARDS DBInstanceRDS DBInstance ReadReplicaAZ(データセンタ)BReplication×
  10. 10.  1位:SharedDisk(DRBDプロトコルCの場合) 2位:AmazonRDSとMHAとmysqlfailover同列 3位: Heartbeat1+mon+mysql※SharedDiskは書きこむ場所が同じのまま引き継がれるのでデータロストが他より起こりにくいです。MHAとmysqlfailoverは最新のバイナリログを判別し反映する機能を持っている為SemiSyncReplicationと組み合わせるとデータロストをより防ぐことが可能です。非同期のreplicationとVIPの付替えのみの場合は最もデータロストが発生しやすくなります。replicationはそもそも非同期な仕組みです。RDSはバックエンドの仕組みが不明なため推測で2位としました。
  11. 11.  1位: MHAとmysqlfailover同列 2位:AmazonRDSとSharedDisk(DRBDプロトコルCの場合)とHeartbeat1+mon+mysql同列※F/O後にシングルになるかどうか、slaveへの参照スケーラビリティが保てるかどうかのみを判別基準としています。
  12. 12.  1位: MHAとmysqlfailover同列 2位:AmazonRDSとSharedDisk(DRBDプロトコルCの場合)とHeartbeat1+mon+mysql同列※slaveが存在する場合、F/O後シングルになる構成では整合性を担保したslaveの復旧のためにMasterからのデータdumpを必要とするため、データ容量に応じたサービス停止時間が必要となります。(※ストレージエンジンにもよります)
  13. 13. HAの仕組みでのパフォーマンス差は判別不能です。※パフォーマンスはハードおよびソフトウェアの性能と物理的な構成に依存します。一般的にはバージョンが高いほうが書きこみ性能やロックやCPUスケール性能等がよく、slaveが多いほうが参照性能が高く、メモリが多くてストレージのI/O性能がよいハードだと全体的なパフォーマンスがよく、非同期な仕組みのほうがより高速です。
  14. 14.  1位: Heartbeat1+mon+mysql 2位:AmazonRDS 3位: SharedDisk 4位: MHA 5位: mysqlfailover※弊社での運用期間が長く障害対応回数が多く慣れている順です。
  15. 15.  1位: Heartbeat1+mon+mysql 2位: MHAとmysqlfailover 3位: AmazonRDSとSharedDisk※用意するノード数が少なくコストがかからない順になります。管理サーバはノードよりマシンスペックが低くすみますが、DBサーバの待機系は稼働系と同様のスペックが必要となります。
  16. 16. 要注意ポイント メリット デメリットReplication(GTID) マスタスレーブ間で一意のGTIDを用いる為よりトランザクションセーフでクラッシュセーフに、マルチスレッドスレーブ、バイナリログのグループコミット、チェックサムの追加GTIDが有効な場合、MyISAM等トランザクションセーフでない仕組みは使用不可能(バイナリログに記録できない)データの扱い バッファプールのダンプとリストアが可能に、テーブルスペースの可搬性向上、オンラインでDDL(CreateIndex他)可能に、NoSQL API、オプティマイザ改善Mysqldumpで旧バージョンのデータを扱う際に--set-gtid-purged=OFF必須、SQLモードのデフォルト値変更による挙動の変化パスワード管理 平文での表示を抑制する仕組み 難読化レベルであり復号化可能パフォーマンス スレッドの同時実行性能向上単純なクエリが高速に、SSD最適化参照専用トランザクションで参照が高速化サーバパラメータに変更がない場合やアプリや環境次第で遅くなるという情報もあるPerformanceSchema OptimizaTraceが可能にブロックされたホスト等特定可能に他パフォーマンス統計情報の取得約1割ほどのオーバーヘッドが生じるその他の主なメリット デフォルト設定の最適化、パーティショニングの改善
  17. 17.  メリット:コミットごとにトランザクションを一意に識別するIDを生成するのでトランザクションセーフである デメリット:バイナリログのフォーマットが異なるほか運用もこれまでと全く異なる(skipできない他)、トランザクションセーフでないストレージエンジン(MyISAMやMemory)やクエリ(Create..Select、CreateTemporaryTable、DropTemporaryTable)は使用不可能(バイナリログに記録できない)

×