On 12/31/10, Simon Riggs <si...@2ndquadrant.com> wrote: > On Fri, 2010-12-31 at 09:27 +0100, Stefan Kaltenbrunner wrote: > >> Maybe it has been discussed but I still don't see way it makes any >> sense. If I declare a standby a sync standby I better want it sync - not >> "maybe sync". consider the case of a 1 master and two identical sync >> standbys - one sync standby is in the same datacenter the other is in a >> backup location say 15km away. >> Given there is a small constant latency to the second box (even if you >> have fast networks) the end effect is that the second standby will NEVER >> be sync (because the local one will always be faster) and you end up >> with an async slave that cannot be used per your business rules? > > Your picture above is a common misconception. I will add something to > the docs to explain this. > > 1. "sync" is a guarantee about how we respond to the client when we > commit. If we wait for more than one response that slows things down, > makes the cluster more fragile, complicates the code and doesn't > appreciably improve the guarantee.
Whether it is more fragile depends on if you look at up-time fragility or durability fragility. I think it can appreciably improve the guarantee. > > 2. "sync" does not guarantee that the updates to the standbys are in any > way coordinated. You can run a query on one standby and get one answer > and at the exact same time run the same query on another standby and get > a different answer (slightly ahead/behind). That also means that if the > master crashes one of the servers will be ahead or behind. You can use > pg_last_xlog_receive_location() to check which one that is. If at least one of the standbys is in the same smoking crater as the primary, then pg_last_xlog_receive_location on it is unlikely to respond. The guarantee goes away precisely when it is needed. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
