On Tue, Aug 2, 2016 at 07:30:22PM -0700, Alfred Perlstein wrote: > So for instance, let's say there is a bug in the master's write to disk. > The logical replication acts as a barrier from that bad write going to the > slaves. With bad writes going to slaves then any corruption experienced on > the master will quickly reach the slaves and they too will be corrupted. > > With logical replication a bug may be stopped at the replication layer. At > that point you can resync the slave from the master. > > Now in the case of physical replication all your base are belong to zuul and > you are in a very bad state. > > That said with logical replication, who's to say that if the statement is > replicated to a slave that the slave won't experience the same bug and also > corrupt itself. > > We may be saying the same thing, but still there is something to be said for > logical replication... also, didnt they show that logical replication was > faster for some use cases at Uber?
I saw from the Uber article that they weren't going to per-row logical replication but _statement_ replication, which is very hard to do because typical SQL doesn't record what concurrent transactions committed before a new statement's transaction snapshot is taken, and doesn't record lock order for row updates blocked by concurrent activity --- both of which affect the final result from the query. So, for statement replication, it is not a question of whether the code has bugs, but that the replay is not 100% possible in all cases, unless you switch to some statement-row-lock hybrid ability. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
