Clusterの基本的な挙動を確認しました。今度は障害時の挙動を見てみましょう。現在の状態はこんな感じ。}}なお、いちいちIPアドレスやホスト名を書くのも分かりづらいので、192.168.2.224から順に1号機~3号機、と呼ぶことにしましょう。R/Wになっている1号機をダウンさせます。mysqld.service2号機で状態を見てみましょう。}}勘悪く、R/Oの方にアクセスしてしまったようですね。代わりに3号機がR/Wになってます。ここでルーター経由で更新をかけましょう。password:成功したか確認。|+----+---------------------+無事入りましたね。さあでは1号機を起動しましょう。mysqld.serviceR/Wになっている3号機で状態確認。}}どうやら勝手に起動したらクラスタにJOINするわけではないようですね。cluster.help()とたたいてみたところでは、rejoinInstanceというのがあるので、これを使ってみましょう。これはマニュアルの一番下にも記載がありますね。1045)mysql-js>・・・?。‘root‘@’innodb-cluster3’とはどういうことだ。そもそも自分でicrootユーザのパスワード聞いてきたじゃないか。調べてみると、これは既知のバグでした。・・・これは絶望的かもしれない。やり取り用のユーザをrootにしておけばいいのかもしれないけど、そこから作り直すのはイヤだ。なんとかならんか・・・?ヘルプを見ると、パスワードはrejoinInstanceのオプションで渡すこともできるとのこと。1045)mysql-js>短けえ夢だったなぁ・・・。あきらめて作り直すか・・・。|+----+---------------------+よしよし。これで1.R/Wサーバの障害2.RouterによるR/W処理の引継ぎ3.障害サーバ復旧後の再JOINまで確認できたわけだ。基本的な挙動はこれでOKですね。更新中だとどうか?こんなシェルを用意してみた。fidone要はINSERTを続けるだけ。mysqldさあどうなったか。数秒止まって処理は再開したようにみえたが。ホスト名をみても、autoincrementのidカラムをみても、2号機から3号機に処理を引き継いでいることが分かる。時刻を見ると、フェイルオーバーにわずか3秒しかかかっていないことが分かる。これだけ早いと気になるのは誤検知に過敏すぎることですが、これはハートビートの仕組みがわからないことにはなんとも言えない。次はそのへんを調べてみたいところですね。これで簡単な挙動確認は一通りおしまいです。あとは、死活監視の仕組みが気になります。調べるのは大変かも知れないですが。コメントをキャンセルメールアドレスが公開されることはありません。*サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。Ushio駆け出しのMySQLエンジニア。OSSを仕事で扱っています。themehall.com。