Más contenido relacionado
Similar a My sqlのha構成について (20)
My sqlの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. 1位:SharedDisk(DRBDプロトコルCの場合)
2位:AmazonRDSとMHAとmysqlfailover同列
3位: Heartbeat1+mon+mysql
※SharedDiskは書きこむ場所が同じのまま引き継がれるのでデータロストが他より起こりにくいです。
MHAとmysqlfailoverは最新のバイナリログを判別し反映する機能を持っている為
SemiSyncReplicationと組み合わせるとデータロストをより防ぐことが可能です。非同期の
replicationとVIPの付替えのみの場合は最もデータロストが発生しやすくなります。replicationは
そもそも非同期な仕組みです。RDSはバックエンドの仕組みが不明なため推測で2位としました。
- 11. 1位: MHAとmysqlfailover同列
2位:AmazonRDSとSharedDisk(DRBDプロトコル
Cの場合)とHeartbeat1+mon+mysql同列
※F/O後にシングルになるかどうか、slaveへの参照スケーラビリティが保てるかどうか
のみを判別基準としています。
- 12. 1位: MHAとmysqlfailover同列
2位:AmazonRDSとSharedDisk(DRBDプロトコル
Cの場合)とHeartbeat1+mon+mysql同列
※slaveが存在する場合、F/O後シングルになる構成では整合性を担保したslaveの復旧の
ためにMasterからのデータdumpを必要とするため、データ容量に応じたサービス停
止時間が必要となります。(※ストレージエンジンにもよります)
- 15. 1位: Heartbeat1+mon+mysql
2位: MHAとmysqlfailover
3位: AmazonRDSとSharedDisk
※用意するノード数が少なくコストがかからない順になります。管理サーバはノードよりマシンス
ペックが低くすみますが、DBサーバの待機系は稼働系と同様のスペックが必要となります。
- 16. 要注意ポイント メリット デメリット
Replication(GTID) マスタスレーブ間で一意のGTIDを用いる為
よりトランザクションセーフでクラッシュ
セーフに、マルチスレッドスレーブ、バイ
ナリログのグループコミット、チェックサ
ムの追加
GTIDが有効な場合、MyISAM等トランザク
ションセーフでない仕組みは使用不可能(バ
イナリログに記録できない)
データの扱い バッファプールのダンプとリストアが可能
に、テーブルスペースの可搬性向上、オン
ラインでDDL(CreateIndex他)可能に、
NoSQL API、オプティマイザ改善
Mysqldumpで旧バージョンのデータを扱う
際に--set-gtid-purged=OFF必須、
SQLモードのデフォルト値変更による挙動
の変化
パスワード管理 平文での表示を抑制する仕組み 難読化レベルであり復号化可能
パフォーマンス スレッドの同時実行性能向上
単純なクエリが高速に、SSD最適化
参照専用トランザクションで参照が高速化
サーバパラメータに変更がない場合やアプ
リや環境次第で遅くなるという情報もある
PerformanceSchema OptimizaTraceが可能に
ブロックされたホスト等特定可能に他パ
フォーマンス統計情報の取得
約1割ほどのオーバーヘッドが生じる
その他の主なメリット デフォルト設定の最適化、パーティショニングの改善