MySQLサーバの冗長構成を考える - rain －しとしと降る雨の夜に

MySQLサーバに何かトラブルがあって停止してしまった場合。
停止する直前までのデータをとっておけば、復旧が楽になる。

通常スケジュールされたバックアップなどでは、1時間に1回とか30分に1回とか。
スケジュールで行うともっと細かい頻度で書き込まれたデータのバックアップは出来ない。

DBのレプリケーション(複製)を常に行っておけば、
マスターのDBと同じデータが格納されたスレーブのDBが出来上がる。

MySQLにはレプリケーションの方法がいくつか存在する。
どの方法が良いか比較したいと思う。

個人的な要件に基づいて比較しているので、世間一般的にどうかは分かりません…。

スレーブ側に障害が発生したとしても、マスター側に障害が発生したとしても、
復旧した時にデータの整合性を求めるなら、
復旧するDB側へ残ったDBのデータを丸々コピーした方が良い、ということらしい。

というのも、マスター側にしか存在しないデータというのが出来にくいだけで、
出来ないわけじゃないから、マスタースレーブ間でデータの整合性が無くなっている可能性もある。
ということみたい。

具体的な方法は見つけられなかったが、
マスター側を復旧するならスレーブ側のDBを丸々ダンプしてマスター側DBにいれる。
その上でレプリケーションを開始すればよい。

バックアップの手法は通常のMySQLと同じように多数存在する。
レプリケーション構成だからといって違うわけではなさそう。

レプリケーション構成であるメリットは
スレーブ側からバックアップを取れば、ロックしていても構わないということくらい。

マスターとの差分が出るかも知れないのなら、
マスター側からバックアップを取るべき？

ストレージエンジンの種類によって
使えるツールと使えないツールがあるということらしい。
MySQLデータのバックアップ方法 | OSDN Magazine

漢(オトコ)のコンピュータ道: MySQL Cluster 7.2見参！Webでも使える熱いヤツがやってきた。
ストレージエンジンの一つ。
InnoDBやMyISAMもストレージエンジンであり、
MySQL Clusterのストレージエンジンとは同居出来ない。

オンメモリで動作する仕組みらしいので、
大容量のメモリを搭載している必要がある。
ここはネックになりそう。

管理ノード、データノード、SQLノードの3つの役割を持つノードで構成される。
最小構成台数は2台。
サーバAに管理ノード、SQLノード、データノード。
サーバBにSQLノード、データノード。
といった形で構成される。

現在必要としている機能は semi-synchronous replication で実現可能。
MySQLCluster にすると使っているストレージエンジンから変えなくてはならない。

ということから考えても semi-synchronous replication を選択しても問題無さそう。

MySQLの冗長構成と一言で言っても沢山の構成パターンがあるのだと分かって良かった。