レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - （ひ）メモ
MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う！」「ここがおかしい！」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基本構成、方針 2台＋1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ
Heartbeatでかんたんクラスタリング（4）：ミラーリングツール「DRBD」によるデータ保護 (1/3) - ＠IT
1つの例として「SAN」（Storage Area Network）があります。データを格納するストレージ自体が冗長化されている製品も多いですし、サーバをSANに接続するためのHBA（Host Bus Adapter）を二重化することも可能ですが、コストもかさみます。 現在ならば、SCSIブロックをIP化してしまう「iSCSI」も選択肢として挙げられるでしょう。ですが最近までiSCSIは、「iSCSi接続を確立するためのイニシエータが不安定だ」などといわれることもありました。また、データを共有する「NFS」（Network File System）を用いてほかのサーバにデータを保存することもできます。しかし外部にデータを置くとなると、どうしても、その分コストも高くなってしまいます。 最もコストを抑える方法を考えた場合に浮上してくる選択肢がDRBDです。Heartbeatによるサービスの冗長
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
