Обсуждение: Upcoming hot standby replication question
Hello, I'd like to ask about the asynchronous nature of upcoming replication implementation in 9.0 - what guarantees does it give with regards to delays and latency? E.g. do COMMITs "finish" and return to the caller before or after the data is sent to the slave? (being asynchronous, they probably don't wait for the other side's confirmation, right?).
Hi, Le 09/04/2010 16:10, Ivan Voras a écrit : > [...] > I'd like to ask about the asynchronous nature of upcoming replication > implementation in 9.0 - what guarantees does it give with regards to > delays and latency? E.g. do COMMITs "finish" and return to the caller > before or after the data is sent to the slave? (being asynchronous, they > probably don't wait for the other side's confirmation, right?). > Before data is sent. So, yes, they don't wait. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
Ivan Voras wrote: > I'd like to ask about the asynchronous nature of upcoming replication > implementation in 9.0 - what guarantees does it give with regards to > delays and latency? E.g. do COMMITs "finish" and return to the caller > before or after the data is sent to the slave? (being asynchronous, they > probably don't wait for the other side's confirmation, right?). > Exactly--synchronous replication, the only way to enforce that data is on the slave before completing the COMMIT, was postponed from this release. It should make it into 9.1 as an option, but it will always be expensive to turn on. What is in 9.0 is eventual consistency. If your slave is keeping up with traffic being sent by the master, it should receive each incremental commit shortly after it's made. In practice, slaves should only lag some number of seconds behind the master. But there are zero guarantees that will be the case, or that latency will be bounded at all. Recommended practice is to carefully monitor how much latency lag there is on the standby and trigger alerts if it exceed your expectations. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
On 9 April 2010 18:21, Greg Smith <greg@2ndquadrant.com> wrote: > Ivan Voras wrote: >> >> I'd like to ask about the asynchronous nature of upcoming replication >> implementation in 9.0 - what guarantees does it give with regards to >> delays and latency? E.g. do COMMITs "finish" and return to the caller >> before or after the data is sent to the slave? (being asynchronous, they >> probably don't wait for the other side's confirmation, right?). >> > > Exactly--synchronous replication, the only way to enforce that data is on > the slave before completing the COMMIT, was postponed from this release. It > should make it into 9.1 as an option, but it will always be expensive to > turn on. > > What is in 9.0 is eventual consistency. If your slave is keeping up with > traffic being sent by the master, it should receive each incremental commit > shortly after it's made. In practice, slaves should only lag some number of > seconds behind the master. But there are zero guarantees that will be the > case, or that latency will be bounded at all. Recommended practice is to > carefully monitor how much latency lag there is on the standby and trigger > alerts if it exceed your expectations. Ok, but I imagine there should be a difference between COMMITs returning before or after the actual data is sent over the network (though admittedly socket buffering could make it hard to distinguish). In addition to that, how about a compromise: COMMITs returning when the remote side ACKs acceptance but before it passes data to storage? Just thinking out lout.
Ivan Voras wrote: > Ok, but I imagine there should be a difference between COMMITs > returning before or after the actual data is sent over the network > (though admittedly socket buffering could make it hard to > distinguish). > To be clear here: there is no direct connection whatsoever between the clients doing commits and the transmission to the standby in 9.0. They are completely decoupled from one another, done by separate processes. The client doing the commit has no idea what's the WAL sender process will do later in order to replicate its results. > In addition to that, how about a compromise: COMMITs returning when > the remote side ACKs acceptance but before it passes data to storage > This is what's referred to as semi-synchronous replication, a term popularized by its implementation in MySQL: http://code.google.com/p/google-mysql-tools/wiki/SemiSyncReplicationDesign http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html The planned design for PostgreSQL 9.1: http://wiki.postgresql.org/wiki/Streaming_Replication Breaks the possibilities down into four levels: async: Current model, never wait for the standby recv: Wait for the standby to receive the data into memory (AKA semi-synchronous) fsync: The standby must have committed the data to disk such that it won't be lost in case of a crash (AKA synchronous) apply: That data must actually be fully processed and available for queries against the standby -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us