Ok, I've pushed to 10.0-base a patch for MDEV-4820. revid:knielsen@knielsen-hq.org-20130816131025-etjrvmfvupsjzq83 As far as I can determine (and I checked quite carefully), this fixes all the problems you mentioned in the bug description and in your test cases. But I could have misunderstood something. Note that for the problem "For some reason at this point server 1 doesn't have any errors and doesn't replicate anything from server 2. Oops", the error is caught not when slave connects, but instead when the first event is received, which should be just as good. The reason is briefly explained in the changeset comment, and is to not re-introduce the bug MDEV-4485. The error message for "alternate future" I formulated like this: "Connecting slave requested to start from GTID %u-%u-%llu, which is not in the master's binlog. Since the master's binlog contains GTIDs with higher sequence numbers, it probably means that the slave has diverged due to executing extra errorneous transactions" I did not want to use the term "alternate future" as this seems to be not standard terminology. The MySQL manual uses the related term "diverge". I am not sure if you will be happy with the fix, but if not, please explain clearly if 1. You observe incorrect behavior (eg. lost transactions, alternate future not caught by error), and if so describe as clearly as possible how to reproduce; or 2. The behaviour is correct, but you are unhappy about the wording of the error messages, or how the code is implemented. - Kristian. PS. I hope it is clear that I greatly value your feedback. You and Elena are the only ones who have seriously worked to help improve the MariaDB GTID, and your input has already been very valuable.