2点：なぜCAP定理にRDBMSパーティションが許容できないのですが、なぜそれが利用可能ですか？私はCAP定理にCAであるRDBMSについては理解していない
1）これは、RDBMSがであると言いませんパーティショントレラントが、どのようにMongoDBなど他の技術よりもトレラントRDBMS 任意の少ないパーティションですカサンドラ？私たちがCAやAPを作るためにCAをあきらめるRDBMSの設定はありますか？
2）CAPはどのように使用できますか？それはマスタースレーブの設定ですか？マスターが死ぬときと同じように、奴隷は引継ぎを引き受けるのですか？
私はDBアーキテクチャとCAP定理の初心者ですので、私に同行してください。
Ans 1. RDBMSはマスター・スレーブ・アーキテクチャーに従い、パーティション・トレラントでない理由を示します。マスターがダウンした場合、何も起こりません（書き込みではなく読み込みません）.Candandraノードはすべて独立しているため、あるノードがダウンした場合、他のノードがそれを処理します。
Ans 2.CAPは、すべてのノードが独立している場合に利用できます。 1つのノードがダウンすると、他のノードがそれを処理する必要があります。
多くのデータベースは実際には構成が異なり、設定によってはCA、CP、APなどの3つのデータベースを同時に使用することはできません。データベースによっては、実際には3つすべてをサポートするように努力していますが、それでも特定の方法で優先順位を付けています。
例えば、MySQLは設定によってはCPとCAになります。デフォルトでは、データはスレーブに複製されるマスタースレーブパラダイムに従うため、CAです。スレーブのセットがマスターへの接続を失ったため、独自のスレーブセットで2つのマスターを作成する新しいマスターを選ぶことを決定した場合、パーティションの許容差は犠牲になります。
ただし、MySQLにはクラスタ構成の別の構成もあります。 CPは可用性を優先して優先順位を付けます。すべてのデータを提供するのに十分なライブノードがない場合、クラスタはシャットダウンします。
他のCAP定理の組み合わせを満足させるためのMySQLの設定は多分あるかもしれませんが、全体的には、あなたのシステムに必要なものに依存していると言いたいのです。時にはデータベースがある構成に対して優れているため、特定の構成を使用する際に発生する可能性のある問題の種類を確認するのが最適です。
CAP定理の実装に関しては、さまざまなデータベースとCAP定理の優先順位をどのように実装するかを詳しく見てみることをお勧めします。例をあまりにも多くの異なる実装方法があります。一般に、マスタースレーブモデルは、CAシステム、APシステムのハッシュリングなどに使用されます。
MongoDBはマスタースレーブ設定にも従いますが、なぜパーティション耐性と見なされますか？ – Glide
パーティション許容はネットワークダウン、その他のシステムエラーです。以前はmysqlが1台のマシンにセットアップされていたため、ネットワークダウンする機会がないか、システムエラーが発生したため、1つのノードがネットワークダウンやシステムエラーなどにより応答しない可能性があります。しかし、mongodbでは、別の-2マシンでセットアップすることができます。なぜなら、それはPartition Tolerantも考慮したからです。しかし、最近ではmysqlもパーティションに耐性があると考えています。 –
MySQLがPartition Tolerantとも見なされる場合、それはCAPと見なされますか？ （すなわち、すべての3つの一貫性があり、利用可能であり、* AND *パーティション耐性） – Glide