I was asked about the difference between master_use_gtid = slave_pos or current_pos. This comes up often, and I thought the below text, which I used to answer the question earlier, might be helpful. Ian, do you think you could incorporate this in some form into the GTID documentation in the knowledgebase? Hope this helps, - Kristian. ----------------------------------------------------------------------- First, consider a slave S2 replicating from a master S1. We stop S2, and then later restart it. Where should it resume replication? Clearly at the point of the last transaction replicated before stopping, which is @@gtid_slave_pos. Now suppose we take down S1 for maintenance and promote S2 as the new master. So we are doing direct transactions on S2. Later we take S1 back up, and now we connect S1 as a slave to S2. Where should S1 start replicating? Clearly at the point of the last transaction in S1's binlog, which is the last transaction made while S1 was the master. This is @@gtid_binlog_pos. Now suppose the user does STOP SLAVE on S1, does a direct transaction on the slave S1, then START SLAVE. That direct transaction was only intended locally, and it is not on the master S2. So when S1 reconnects, it needs to connect at its @@gtid_slave_pos this time, not at the @@gtid_binlog_pos. So we see, only the user knows if a direct transaction made on a server is meant as a cluster-wide transaction, or a local transaction only. And the "correct" behaviour is _different_ depending on this. Normally, direct local transactions in the slave binlog are considered sloppy, because of all the possibilities for errors they introduce. So it is recommended to run slaves in read-only mode, and set @@sql_log_bin=0 if doing local transactions. And gtid_strict_mode=1 is provided to enforce this recommended mode of operation. In this case, user can use current_pos, which will automatically use either @@gtid_slave_pos or @@gtid_binlog_pos, whatever is appropriate. However, some (or many) users like to "be sloppy" and do direct transactions on a slave not intended as master transactions. And for those we provide gtid_strict_mode=0 and master_use_gtid=slave_pos. This makes slave connect always use the position of the last replicated transaction, ignoring any local transactions in the binlog. In this case, when a master is changed to be a slave, it is necessary to manually set @@gtid_slave_pos=@@gtid_binlog_pos. Explicitly marking the updates on the old master to be intended as master transactions, not local transactions. -----------------------------------------------------------------------