Why Uber Engineering Switched from Postgres to MySQL (2016)

Re:Why Uber Engineering Switched from Postgres to MySQL (2016) by chousuke on Saturday February 27, 2021 @10:33AM (#26285455)

In streaming (physical) replication, PostgreSQL sends the WAL only, and it's applied on the replica; no "sending of queries" is involved, or even possible; with physical replication, the secondary has to keep itself identical with the primary, otherwise replication will fail. This is why you can't use physical replication across major versions, since they can't be bit-for-bit identical.

In more recent versions there's "logical replication", which sort of "sends the queries", in that the secondary node has its own database state that does not have to be exactly identical with the primary, allowing for replication across major versions.

In my opinion though, unless you really need logical replication for some reason, stick with streaming replication. It's much easier to understand and there are fewer failure modes.

[ Parent | on HN ]

Re:Why Uber Engineering Switched from Postgres to MySQL (2016) by amenonsen on Saturday February 27, 2021 @10:49AM (#26285559)

> In more recent versions there's "logical replication", which sort of "sends the queries"

What it sends is not the queries, but a logical description of the changes to each row that were made by running the query. So an UPDATE that changes N rows would generate N changes to be applied to the corresponding rows (usually identified by primary key) on the logical replica, not a single update that had to be "re-executed".

[ Parent | on HN ]