3 ms·

it makes sure that the WAL is written on the slave before the transaction is committed on the master means that data integrity should be top notch. That's

• sph 16y ago
  The slaves may delay applying the transaction, but the data is already on the slave machine. As the article points out, the data gets written to the WAL on the slave before the transaction is committed on the master. The slave might not update the database from the WAL immediately, but the data is on the slave in case the master goes down. Basically, it means that there is the potential for replication lag and so you have to make sure you query from the master for just-updated data. However, it also means that if the master goes down, any data committed on the master is already on the slave in the WAL, just possibly not applied yet. So, it doesn't isolate you from replication lag, but it is a nice thing when it comes to making sure that the data remains intact even if a complete failure of the master occurs.
  • wiredfool 16y ago
    As the article points out, the data gets written to the WAL on the slave before the transaction is committed on the master Then the article is wrong, it doesn't. I can reboot or kill the slave and the master will still happily accept transactions. It's also pretty clear from tcpdump that the data only goes on commit, and it's one way from the master->slave.