1. Master if variable gtid_deployment_step changes dynamically may generate invalid binary log like the extract attached.
This may be considered as a feature request, but still may be easy to fix.
I expect if you ensure all writes to master stopped before changing this variable would resolve this issue. If you flush binary log before doing change I see no reason for new binary log to be corrupted.
2. Slave SQL thread crash when it tries to apply such binary log.
If I try to apply it to the master using SQL interface there is no crash:
mysqlmtr -P13001 test < bug1516919-1.sql
ERROR 1837 (HY000) at line 67: When @@SESSION.GTID_NEXT is set to a GTID, you must explicitly set it to a different value after a COMMIT or ROLLBACK. Please check GTID_NEXT variable manual page for detailed explanation. Current @@SESSION.GTID_NEXT is 'ac2dfc05-0fc7-11e7-bf16-30b5c2208a0f:480780'.
I see two issues here.
1. Master if variable gtid_deployment _step changes dynamically may generate invalid binary log like the extract attached.
This may be considered as a feature request, but still may be easy to fix.
I expect if you ensure all writes to master stopped before changing this variable would resolve this issue. If you flush binary log before doing change I see no reason for new binary log to be corrupted.
2. Slave SQL thread crash when it tries to apply such binary log.
If I try to apply it to the master using SQL interface there is no crash:
mysqlmtr -P13001 test < bug1516919-1.sql 0fc7-11e7- bf16-30b5c2208a 0f:480780' .
ERROR 1837 (HY000) at line 67: When @@SESSION.GTID_NEXT is set to a GTID, you must explicitly set it to a different value after a COMMIT or ROLLBACK. Please check GTID_NEXT variable manual page for detailed explanation. Current @@SESSION.GTID_NEXT is 'ac2dfc05-
Bug confirmed.