Michael Widenius <monty@askmonty.org> writes:
Why doing an insert + delete instead of one update?
This is described in more detail in my blog under "On crash-safe slave": http://kristiannielsen.livejournal.com/17008.html The basic problem with just one UPDATE is that this causes row lock contention when we get parallel replication, such as running group committed transactions in parallel, or the parallel replication patch of dingqi/Taobao. Suppose that we replicate transactions T1 and T2 in parallel. They both try to UPDATE the replication state. One will go first, say T1, and lock the row, causing T2 to have to wait. Only when T1 has committed will it release row locks, allowing T2 to do the update and later commit. So T1 and T2 can not commit in parallel. This makes group commit impossible, which is a huge performance hit in some workloads. Instead, the MDEV-26 design does a new insert for every change of the replication state. This avoids row locks, and allows group commit to work. Periodically we must then delete no longer needed rows, which can be done in batches, or every commit, or whatever. - Kristian.