In Cassandra vs Mongo debate, it is said that as mongo has master-slave architecture so it has a single point of failure(master) as when master fails, slave nodes take time to decide for new master, hence a window for downtime.
With Cassandra we don't have this problem as all nodes are equal. But then Cassandra too has a system wherein nodes use gossip protocol to keep themselves updated. In gossip protocol a minimum number of nodes are needed to take part. Suppose if one of the participating node goes down, then a new node needs to replace it. But it would take time to spawn a new replacement node, and this is a situation similar to master failure in mongo.
So what's the difference between 2 as far as single point of failure is concerned?
CodePudding user response：
Your assumptions about Cassandra are not correct so allow me to explain.
Gossip does not require multiple nodes for it to work. It is possible to have a single-node cluster and gossip will still work so this statement is incorrect:
In gossip protocol a minimum number of nodes are needed to take part.
For best practice, we recommend 3 replicas in each data centre (replication factor of 3) so you need a minimum of 3 nodes in each data centre. With a replication factor of 3, your application can survive a node outage for consistency levels of ONE, LOCAL_ONE or the recommended LOCAL_QUORUM so these statements are incorrect too:
Suppose if one of the participating node goes down, then a new node needs to replace it. But it would take time to spawn a new replacement node, and this is a situation similar to master failure in mongo.
The only ways to introduce single points-of-failure to your Cassandra cluster are:
- deploying multiple instances on a single physical host (not recommended)
- using shared storage (e.g. SAN, NAS, NFS) for all nodes (not recommended)
As a side note, a friendly warning that other users may vote to close your question because comparisons are usually frowned upon since the answers are often based on opinions. Cheers!
CodePudding user response：
Also your assumptions about MongoDB are not correct.
Master-Slave replication has been removed in MongoDB version 4.0 (current version is 5.0), nowadays it uses Replica Sets
Typically you connect to a Replica Set rather than a single Replica Set member. When the current PRIMARY goes down, then a new PRIMARY will elected and your application will re-connect automatically and retries write operations to the new PRIMARY. It may hang for a few seconds but it should continue running.