41–50 of 71 posts
[0]: http://www.cybertec.at/en/products/agg-parallel-aggregations...
Holy crap, I am scared! Please, please, please read the fine print and ensure you understand the design tradeoffs as well as your application's requirements before blindly using this. The moment I heard multi-master I thought Paxos, Raft or maybe virtual synchrony. Hmm, nothing in the documentation. Maybe a new consensus protocol was written from scratch then? That should be interesting! No, none of that either - thi…
What's your use case here? Do you really want multi-master/bi-directional replication, or do you want distributed transactions? Why would an app want to connect to both masters, this isn't sharding?
Earlier quoted context omitted.
Do you know of any relational products which offer high-throughput, low-latency, high-availability transaction processing using perfectly synchronous multi-master replication?
Doesn't Oracle offer such an option?
Earlier quoted context omitted.
> I am sure there are use-cases where the risk of this design is acceptable (or necessary), but ensure you have a plan for dealing with data inconsistencies! I'd argue most non-financing applications would find these risks acceptable. This form of Multi-Master is what most people writing web-based applications actually are looking for. It simplifies having fail-over, at the costs you mentioned, but those aren't a maj…
>acting like there aren't any is blatantly ignoring many types of workloads. I agree in principle, and if you have the knowledge and means to understand/mitigate the risk, this warning isn't aimed at you ;) It is aimed at the ignorant, not the negligent e.g the engineer I was 15 years ago - who didn't know what he didn't know and would've chosen BDR simply for its master-master promise without understanding what I am…
Replication is a problem that n00bs aren't going to touch on their startup site. They're only going to use it when they have hundreds of thousands/millions of users already.
Earlier quoted context omitted.
Just curious, what Postgres features are you missing on MySQL? I had only used MySQL until a year or two ago, and wondered what I was missing since Postgres seems to get more love/hype from the developer community for whatever reason. Now using Postgres in production, there are few if any features that I notice our team using which don't exist in MySQL (maybe Json landed in Postgres first is one big one?). One thing…
transactional DDL => if your application often has schema update and you use a tool like Doctrine for PHP / Alembic for python, when a downgrade or upgrade fail on MySQL in the middle became the create index was already taken by someone who "hot-fixed" the database and that now you're in an inconsistent state and you have to clean stuff by hand you will regret to not be on PostgreSQL where it will have simply rollbac…
The default SQL mode also changed to be strict in 5.7, preventing silent overflows and other oft-complained-about write behaviors. Using a strict SQL mode has been recommended best practice for quite a long time anyway.
MySQL certainly has its flaws, and there are a number of useful features that are present in pg but missing in MySQL. But the gap is smaller than many people realize.
Holy crap, I am scared! Please, please, please read the fine print and ensure you understand the design tradeoffs as well as your application's requirements before blindly using this. The moment I heard multi-master I thought Paxos, Raft or maybe virtual synchrony. Hmm, nothing in the documentation. Maybe a new consensus protocol was written from scratch then? That should be interesting! No, none of that either - thi…
Do you know of any relational products which offer high-throughput, low-latency, high-availability transaction processing using perfectly synchronous multi-master replication?
However all work best when the DCs are within a few milliseconds of each other and you have a reasonably reliable Internet connection. (AWS within one region qualifies.)
Most people are still better off with Active Master-Standby Master setups overall.
Holy crap, I am scared! Please, please, please read the fine print and ensure you understand the design tradeoffs as well as your application's requirements before blindly using this. The moment I heard multi-master I thought Paxos, Raft or maybe virtual synchrony. Hmm, nothing in the documentation. Maybe a new consensus protocol was written from scratch then? That should be interesting! No, none of that either - thi…
It is amazing to see the number of projects based on Postgres mentioning that they are trying to achieve multi-master with their own restrictions: * Postgres-R is not multi-master, got discontinued in 2010, and lots most of its meaning after WAL-shipping has been added in-core with hot-standby. http://www.postgres-r.org/ * Postgres-XC, that says to do multi-master, the first project based on PostgreSQL that I heard o…
Earlier quoted context omitted.
Just curious, what Postgres features are you missing on MySQL? I had only used MySQL until a year or two ago, and wondered what I was missing since Postgres seems to get more love/hype from the developer community for whatever reason. Now using Postgres in production, there are few if any features that I notice our team using which don't exist in MySQL (maybe Json landed in Postgres first is one big one?). One thing…
transactional DDL => if your application often has schema update and you use a tool like Doctrine for PHP / Alembic for python, when a downgrade or upgrade fail on MySQL in the middle became the create index was already taken by someone who "hot-fixed" the database and that now you're in an inconsistent state and you have to clean stuff by hand you will regret to not be on PostgreSQL where it will have simply rollbac…
- table elimination/join removal (MariaDB supports it but MySQL doesn't)
- asynchronous protocol (the new X Protocol supports it but not the standard protocol)
- table functions (for example the generate_series function which is very useful in PostgreSQL)
- LISTEN/NOTIFY (a built-in pub-sub mechanism)
- WITH (Common Table Expressions)
- Window aggregations (very useful for reporting and stats)
- Row Level Security (introduced in PostgreSQL 9.5; very useful for multi-tenant applications)
Earlier quoted context omitted.
Do you know of any relational products which offer high-throughput, low-latency, high-availability transaction processing using perfectly synchronous multi-master replication?
Doesn't Oracle offer such an option?
This is the case as you can't guarantee consistency without coordination between the servers (or you won't know what order to make operations visible in the case of multi-master, or whether a transaction has even been successfully applied by a slave when replicating master-slave), which at a bare minimum involves one round-trip (sending a transaction, and waiting for confirmation that it has been applied; assuming no conflicts requiring additional effort to reconcile).
You can pipeline some stuff to partially avoid actual delays, but you can't avoid the signalling, and for many applications it has disastrous effect on throughput when certain tables/rows are highly contended.