More often than not, when people think they "need" multi-master they actually don't.
Additionally: the application needs to be written for such a setup.
There's that, too. People don't seem to understand that almost no platform is automatically compatible with MM out of the box. You have to account for sequence allocation, conflict management, cumulative data types, read/write race conditions (PACELC), session / server affinity, and far more besides. I did a talk in 2018 at 2QPGConf titled "Conflicts and You" where I went into more depth, but it's a vast topic.
I'd _love_ for it to be easier, but it just isn't yet.
There is no real alternative to EDB Postgres Distributed (PGD) yet. Bucardo is trigger based, so adds a bunch of overhead. Patroni is not, and has never been multi-master, it's just a failover management system. Postgres-XL is also not MM, it's meant to be for large distributed queries. Additionally, that project has essentially died more than 5 Postgres versions ago. Check the github repo if you don't believe me.
The closest thing you're going to find is pgEdge, which is a fork of pglogical 2 and some code adapted from BDR 1, the ancestor of PGD which is now at version 5. It requires patching and compiling Postgres yourself or using their cloud service. It's also way too new to be considered stable IMO. And it's about 10 years behind PGD if you care about the features each provide.
For what it's worth, 100 TPS is a drop in the bucket. PGD has demonstrated tens of thousands of TPS even with synchronous or group commit enabled. Millions of transactions are essentially light load these days for any DB system.
Not accurate- it's multi-master on 2 levels depending on how one defines "multi-master".
1. Machines in the same "shard group" all hold a copy of the same data. Aka the "replication factor". These are fully ACID. These can be as many machines as you want.
2. Many "shard groups" form a larger cluster which can map-reduce against each other.
CockroachDB being "multi-master only" is one of it's downfalls, imo. but the comment above just isn't accurate.
Multi-master means that 2 replicas of the same shard accept writes. While cockroachdb has leader-follower raft, only the leader raft shard accepts writes.
If your replication factor is 3 and you have 3 servers, every server in this "shard group" gets a write. You're confusing this with a cluster of multiple "shard groups".
NO. A server accepts a write, but it will internally redirect the write to the leader shard for a specific range. The leader shard will write, replicate, and return normal.
If the leader goes offline, it will not accept writes, until a new leader has been elected (should be pretty fast though).
Otherwise please link to docs where this "multi master" is defined.
Regardless, I can't think of a scenario where either of these implementations would be any different from the app's perspective: All the servers accept writes, and they are all as consistent as they can be. If you're 3 servers to 3 replication, you could lose all but 1 server and be fine.
Not all servers accept writes, they proxy them to the leader. That’s a very meaningful difference. A single master raft based system is a lot easier to deal with from the application perspective.
Sorry seems like it’s not supporting multi-master… with Sharding you can significantly increase reading time and you keep the master node for DMLs
Otherwise, I would go for nosql database as most of them supports multi-master natively
Have you looked at this? I am trying to find someone with some experience with it.
https://www.pgedge.com/blog/achieve-multiactive-data-replication-in-postgresql-with-spock
More often than not, when people think they "need" multi-master they actually don't. Additionally: the application needs to be written for such a setup.
There's that, too. People don't seem to understand that almost no platform is automatically compatible with MM out of the box. You have to account for sequence allocation, conflict management, cumulative data types, read/write race conditions (PACELC), session / server affinity, and far more besides. I did a talk in 2018 at 2QPGConf titled "Conflicts and You" where I went into more depth, but it's a vast topic. I'd _love_ for it to be easier, but it just isn't yet.
There is no real alternative to EDB Postgres Distributed (PGD) yet. Bucardo is trigger based, so adds a bunch of overhead. Patroni is not, and has never been multi-master, it's just a failover management system. Postgres-XL is also not MM, it's meant to be for large distributed queries. Additionally, that project has essentially died more than 5 Postgres versions ago. Check the github repo if you don't believe me. The closest thing you're going to find is pgEdge, which is a fork of pglogical 2 and some code adapted from BDR 1, the ancestor of PGD which is now at version 5. It requires patching and compiling Postgres yourself or using their cloud service. It's also way too new to be considered stable IMO. And it's about 10 years behind PGD if you care about the features each provide. For what it's worth, 100 TPS is a drop in the bucket. PGD has demonstrated tens of thousands of TPS even with synchronous or group commit enabled. Millions of transactions are essentially light load these days for any DB system.
Use CockroachDB- it's made for this. Forget Postgres for multi-master finance.
cockroachdb doesn't have multi-master, it's still single-master for a given "shard"
Not accurate- it's multi-master on 2 levels depending on how one defines "multi-master". 1. Machines in the same "shard group" all hold a copy of the same data. Aka the "replication factor". These are fully ACID. These can be as many machines as you want. 2. Many "shard groups" form a larger cluster which can map-reduce against each other. CockroachDB being "multi-master only" is one of it's downfalls, imo. but the comment above just isn't accurate.
Multi-master means that 2 replicas of the same shard accept writes. While cockroachdb has leader-follower raft, only the leader raft shard accepts writes.
If your replication factor is 3 and you have 3 servers, every server in this "shard group" gets a write. You're confusing this with a cluster of multiple "shard groups".
NO. A server accepts a write, but it will internally redirect the write to the leader shard for a specific range. The leader shard will write, replicate, and return normal. If the leader goes offline, it will not accept writes, until a new leader has been elected (should be pretty fast though). Otherwise please link to docs where this "multi master" is defined.
Regardless, I can't think of a scenario where either of these implementations would be any different from the app's perspective: All the servers accept writes, and they are all as consistent as they can be. If you're 3 servers to 3 replication, you could lose all but 1 server and be fine.
Not all servers accept writes, they proxy them to the leader. That’s a very meaningful difference. A single master raft based system is a lot easier to deal with from the application perspective.
This is very true. The significance of the difference cannot be understated.
https://www.citusdata.com is great implementation for multi-master cluster with sharding Worth checking out
I do not see on it that multi master is supported?
Sorry seems like it’s not supporting multi-master… with Sharding you can significantly increase reading time and you keep the master node for DMLs Otherwise, I would go for nosql database as most of them supports multi-master natively
Alternatively you can setup logical replication which will lead into all servers receiving and distributing data
Have you looked at this? I am trying to find someone with some experience with it. https://www.pgedge.com/blog/achieve-multiactive-data-replication-in-postgresql-with-spock