レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - （ひ）メモ
MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う！」「ここがおかしい！」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基本構成、方針 2台＋1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ
MySQL レプリケーションの設定 - とみぞーノート
1.2 レプリケーションの動作レプリケーションでは最初にDBの内容を同期させた後、Masterサーバーで実行された更新系のクエリ(UPDATEとか)をSlaveに渡してSlaveでも同じクエリを実行していくことで、DBを同期させている(図1)。 Master側で実行された更新系クエリはバイナリログに蓄えられており、Slave側が接続してきたら、前回の接続からの変更分をSlave側に送信する。Slave側は受け取ったクエリを一旦リレーログに蓄えて順次クエリを実行してDBを同期させていく。リプリケーション動作にはBinlogDump,I/O,SQLの3つのスレッドが連携して動作する。 2.設定手順 (Master-Slave構成) 2.1 Master側の設定の確認Master側ではバイナリログを採取しておく必要があるので、Master側のmy.cnfにlog-binの設定が入っていることを確
MySQLレプリケーションを安全に利用するための10のテクニック
MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA（高可用性） ディザスタリカバリ（サイト間レプリケーション） BI（レポーティングetc） という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション
Tomcatでフェイルオーバー（比較） - 気の向くままに・・・
（細かい設定はさておき）Tomcatでサポートされている３種類のセッション情報の共有化に関して試してみたわけですが・・・その比較を。Tomcat easy clustering configurationに詳細にまとめられていますが、個人的な意見も交えつつ。なお、フェイルオーバーに関連した細かい設定等に関しては、気が向けば改めてまとめるかもしれません。 【PersistenceManagerを利用】 PersistenceManager+FileStoreおよびPersistenceManager+JDBCStoreの組み合わせを用いた場合、セッション情報の保管が行われるまで若干のタイムラグが発生してしまいます。他にも、いくつかの不利な点があります。 設定でセッション保管の間隔を短縮することは可能だが、最低でも１秒以上の間隔は必要。当然ながら、間隔を短くしすぎるとリソースの消費は激しくなる
[ThinkIT] 第1回：Tomcatによるクラスタリングの実現 (3/4)
Tomcatサーバにリクエストを転送したけれどもTomcatがダウンしていた場合、mod_jkはクラスタ内の次のサーバにリクエストを割り当て、クライアントに異常事態が発生したことを気づかせないような自然なフェイルオーバーを実現します。 一度ダウンと判定されたサーバに対してはその後リクエストを振らないようになりますが、mod_jkは一定周期でサーバの生死確認を行うので、その時に正常稼動を再度確認できれば、またロードバランスの対象とします。 スティッキーセッションを使うことで、セッションを利用するアプリケーションの場合でも同じサーバにアクセスし続けることでセッションを維持できていたのですが、そのサーバがダウンしてしまったら、mod_jkは別のサーバにリクエストを割り振るしかありません。当然その新しく割り当てられたサーバはセッション情報を持っていないため、処理を継続することができなくなり、新規セ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
