This has been fixed using pglogical starting from 9.4. This means that for the size of Uber, upgrading to a new release was really problematic. Long running transactions will be killed by Postgres since they block the WAL thread and this can be a problem since application developers may not be aware of the problem especially if using an ORM that isn’t transparent in transaction boundaries.Īgain because replication works in the physical level, database updates have to happen at the same time for all nodes or else replication can not work.
Combined with Postgres design to block database updates if they affect rows open by a transaction it can seriously affect long running transactions. Replicas have to apply the same WAL (Write Ahead Log) writes as the master. Postgres also lacks true replica MVCC support.
Calculating the number of entries affected was not possible and because replication happens at the physical layer, there was the risk of ruining the database indexes. This was caused because of missing marking some entries as inactive as they should had been. Consequently, the write amplification issue leaks into replication causing multiple updates to be transferred over wire for simple updates, which can cause major issues in disaster recovery scenarios where data centers may be far away from each other and bandwidth cannot be cheap or readily available.Īlso, during a routine upgrade, a Postgres 9.2 bug caused data corruption in some tables. HOT(Heap-Only-Tuples) feature can alleviate this issue and may be a solution in some use cases.
POSTGRES VS MYSQL UBER UPDATE
The write amplification happens because an update to a single row that touches indexes needs to update all indexes resulting in many writes to the disk which can be an even bigger issue when using SSDs.
Uber’s main problem stems from the write amplification issue in Postgres. In a recent blog post, Uber detailed why they have chosen to replace PostgreSQL with MySQL.
0 kommentar(er)
