ワォ!一気に上がりました。10000回出来るかどうかもチェック。行けるようになりましたー。接続を使い回してくれてるようです。パフォーマンスも接続を使いまわすことで一気に改善しました。なんで、そういう作りにしてなかったのか?っていうのが気になります。いうことかというと、Poolが保持しているMongoConnectionは生成された時点でReplicaSetのPrimaryを判定して保持しています。Failoverした直後、Poolが破棄されない限り接続エラーがおきて、正しくデータの書き込みができなくなるということでしょう。abを実行し、その最中にstepDownでFailoverしてみます。}).masterじゃないダニ!と言われ、書き込みできないエラーが発生しました。SafeModeじゃなくても同じようにエラーになることは確認済み。得意げにドヤ顔したところで、それはつまりDisconnectしなくなったからでしょ?と、おっしゃるとおりな理由でのエラーなんですけどね。Failoverした後もちゃんと接続が継続できるようにするために毎回Disconnectしてたわけですね。あちゃー、これはどうしたものか。今、解決策を思いつくような振りになってますけど、事前に調査してわかってることを書いてるだけなんで...。!つまり今回のエラーの原因はPoolから取り出したMongoConnectionがPrimary(Master)を指してないから例外が起きるわけです。MongoServer.Disconnectを呼ぶことでPoolのすべてのコネクションが破棄されるというのはソース見て確認済み。MongoDBに対する処理で例外が発生したらMongoServer.Disconnectを呼び出し、処理をリトライすることで、Failover後に決定したNodeに接続するようにしてあげればよい、という方法が取れましょう。MaxConnectionLifeTimeを短くしてみては?っていうのもあるでしょうが短すぎると接続エラーになりそうだし。用意したのが以下のようなリトライ実行するヘルパー。↓こいつでPool内の全コネクションクリアが走るはず。ここでイベントログに書き出すか、Exceptionを出力する必要がある。後続の処理に進んだら困るならException。ログなら進んでもいいかもねー。}}ダサくない!ダサくないよ!これでいいんだもん!このコードを書いてる途中、さすがに心配になったんですけど(これでいいのかっていうね)、そんなおり以下のページを見つけました。MongoRuby-1.4.1似たようなリトライさせてますね。もんで、いいってことで。これを使って実行する書き方は↓こう。データ追加したり...});GetSettingは設定を入れたものを返しましょう。サーバー名とかリトライ回数とか。これつかって丸っとしたもので、実行しつつFailoverさせてみます(abでエラーが出ないことを確認しました)。大成功!エラーも起きずFailover成功しました。データも欠落なくいけてます。この状態でのパフォーマスンスを測定してみます。遅くなったじゃん!っていう感じしますけど、あったまって無かったみたい。実質Disconnect削除のパフォーマンスと同じ数値でした。~、これだと~、なんていうかパンチが弱い。いいとは思うんだけど~。どこか早くできそうなところないかなー、とMongoSessionStateStoreのソースを見ているとありましたねー。Base64に変換してstringにしてるじゃないですか。コレいらなくない?BsonBinaryArray使えばbyte[]をそのまま入れることが出来るんじゃないのー?と、気になったので試した結果が↓こちら。