シナリオ1 - 飽和状態

5ノードのCouchbaseクラスタが、ネットワーク負荷に関して80〜90パーセントの合計容量で実行されているシナリオを想像してみてください。限界ではあるが、すべてうまく実行されています。今、ノードに障害が発生し、ソフトウェアが自動的にそのノードをフェイルオーバーすることを決定します。残りの4つのノードのすべてが、新たに増えた負荷を成功裏に処理できるということはありえないことです。そんなことをすれば、新たなノードが自動フェイルオーバーされることになるからです。これらの障害は、クラスタ全体の最終的な損失につながり得ます。1/5の要求が処理されない方が、まったく要求が処理されないより、より望ましいことははっきりしています。

大規模なソーシャルネットワーキングサイトのデータインフラストラクチャアーキテクトが、言っていました："もし半分のサーバーがダウンしても、まだ半分のユーザーにサービスを提供しているのなら、きわめてよくやっていると言えるのでないかな"（パラフレーズ）

これに対する解決策は、単一ノード障害をいったん許容し、新しいサーバをクラスタに追加すると同時に、障害が発生したノードを削除状態にマークしてからリバランスすることです。この方法では、クラスター全体がダウンするよりむしろ、簡単な部分的停止があります。ノ​​ードの障害をレプリカが引き継いで処理するのに十分な容量を確実に用意するという解決策もあります。

シナリオ2 - ネットワーク分断

ネットワーク分断がCouchbaseのクラスタ内で発生した場合、自動フェールオーバーにより、双方がお互いに自動的にフェイルオーバーしようとするでしょう。分断されたネットワークそれぞれが、全ドキュメント空間の責任を負おうとします。そしてそれらのクラスタ内部では1つのドキュメントIDに関して整合性が取れた状態となりますが、2つのネットワーク間でデータの不整合が発生し始めます。扱うデータやアクセスパターンの性質によっては、これらの差異を修復することは困難かもしれません。

二つの部分的なクラスタの一つが、すべてのトラフィックに対応できるほど十分に大きいと仮定すると、次の解決策があります。クラスタへのすべてのトラフィックをその一つの部分的なクラスタへ誘導し、その後、以前にアクセス可能だったマシン加え、元のクラスタサイズに復元する方法です。

シナリオ3 - ノードの動作不良

一つのノードがクラスタへの接続を失い（または、そう判定し）、そのノードが自動的にその他のクラスタをフェイルオーバーできる場合は、そのノードが独立したクラスタになってしまいます。その結果、上記と同様なパーティションの状況が再び発生します。

この場合、解決策は、接続の問題を持つノードをダウンさせ、クラスタの残りの部分に負荷を処理させることです。（使用可能な予備の容量があることを仮定しています）