回答:
MongoDBはデフォルトで強い整合性があります。書き込みを行ってから読み取りを行った場合、書き込みが成功したとすると、読み取った書き込みの結果をいつでも読み取ることができます。これは、MongoDBがシングルマスターシステムであり、すべての読み取りがデフォルトでプライマリに送信されるためです。オプションでセカンダリからの読み取りを有効にすると、MongoDBは最終的に整合性がとれ、古い結果を読み取ることが可能になります。
MongoDBは、レプリカセットの自動フェイルオーバーによって高可用性も実現します。http：//www.mongodb.org/display/DOCS/Replica+Sets
Luccasの投稿に同意します。MongoDBがCP / AP / CAであるとは言えません。これは、データベース/ドライバーの構成と障害の種類の両方に応じて、実際にはC、A、Pの間のトレードオフであるためです。より詳細な説明。
Scenario | Main Focus | Description
---------------------------|------------|------------------------------------
No partition | CA | The system is available
| | and provides strong consistency
---------------------------|------------|------------------------------------
partition, | AP | Not synchronized writes
majority connected | | from the old primary are ignored
---------------------------|------------|------------------------------------
partition, | CP | only read access is provided
majority not connected | | to avoid separated and inconsistent systemsMongoDBは、単一の接続または正しい書き込み / 読み取りの懸念レベル（実行速度が低下します）を使用する場合に、強い整合性があります。これらの条件を満たさなくなると（特に、セカンダリレプリカから読み取る場合）、MongoDBは最終的に整合性が取れた状態になります。
MongoDBは、レプリカセットを通じて高可用性を実現します。プライマリーがダウンするか、他のものが使用できなくなるとすぐに、セカンダリーは新しいプライマリーを決定し、再び使用可能になります。これに欠点があります：古いプライマリで行われますが、セカンダリに同期されませんでしたすべての書き込みがされますバックをロールとロールバック・ファイルに保存された、とすぐにそれがセットに再接続するよう（旧プライマリがセカンダリであります今）。したがって、この場合、可用性を確保するために一貫性がある程度犠牲になります。
上記のレプリカセットを使用することで、MongoDBはパーティションの許容範囲も実現します。レプリカセットのサーバーの半分以上が相互に接続されている限り、新しいプライマリを選択できます。どうして？2つの分離したネットワークが両方とも新しいプライマリを選択できないようにするため。十分なセカンダリが相互に接続されていない場合でも、セカンダリから読み取ることはできますが（一貫性は保証されません）、書き込むことはできません。このセットは、一貫性を保つために実際には利用できません。
華麗な新品ともいくつか現れたカイルによって素晴らしい実験をこのフィールドにCまたはAとしてMongoDBの、および他のデータベースを標識する場合、あなたは注意する必要があります
もちろん、CAPはデータベースが何を支配しているかを多くの言葉なしで追跡するのに役立ちますが、たとえばCAPのCは原子の一貫性（線形化可能性）を意味することを忘れがちです。そして、これは分類しようとするときに理解するのに多くの苦痛を引き起こしました。したがって、MongoDB以外にも強い整合性が得られますが、これがCであるという意味ではありません。このように、この分類を行う場合は、疑いを残さないように実際にどのように機能するかについても詳しく説明することをお勧めします。
Pモンゴについてはよくわかりません。状況を想像してください：
ここでの問題は、ダンプファイルのサイズが制限されていることと、長期間パーティションを使用していた場合、データが永久に失われる可能性があることです。
あなたがそれが起こる可能性は低いと言えます-そうではありませんが、クラウドで考えられているよりも一般的である場合を除きます。
この例が、データベースに文字を割り当てる前に非常に慎重になる理由です。非常に多くのシナリオがあり、実装は完全ではありません。
Mongoの今後のリリースでこのシナリオが対処されているかどうかを誰かが知っている場合は、コメントしてください！（私はしばらくの間起こっていたすべてをフォローしていません。）
MongoDBは、パーティションがある場合は常に、可用性よりも整合性を選択します。つまり、パーティション（P）がある場合、可用性（A）よりも一貫性（C）が選択されます。
これを理解するために、MongoDBがレプリカセットを機能させる方法を理解しましょう。レプリカセットには、プライマリノードが1つあります。データをコミットする唯一の「安全な」方法は、そのノードに書き込み、そのデータがセット内の大部分のノードにコミットするのを待つことです。（書き込みを送信すると、w = majorityのフラグが表示されます）
パーティションは、次の2つのシナリオで発生します。
基本的に、パーティションが発生し、MongoDBが何をすべきかを決定する必要があるときはいつでも、可用性よりも一貫性を選択します。システムがそれらの書き込みを安全に完了できると考えるまで、システムへの書き込みの受け入れを停止します。
Mongodbは、一貫性とパーティションの許容範囲を提供します。
これは、分散（NoSQL）データベースのコンテキストでは、一貫性と可用性の間で常にトレードオフが発生することを意味します。これは、分散システムは常にパーティショントレラントであるためです（つまり、パーティショントレラントでなければ、分散データベースではありません）。
整合性 -システムは最終的に整合性を保ちます。データは遅かれ早かれあらゆる場所に伝播しますが、システムは入力を受け取り続け、次のトランザクションに移る前にすべてのトランザクションの整合性をチェックしていません。
可用性 -デフォルトでは、Mongo DBクライアント（MongoDBドライバー）は、すべての読み取り/書き込み要求をリーダー/プライマリノードに送信します。これにより、システムの一貫性は保たれますが、利用できなくなります。リーダーがクラスターから切断された場合、新しいリーダーが選出されるまで数秒かかります。そのため、その間は書き込みと読み取りができなくなります。