Bug #90823 mysql 5.7.22, M-M replication error
Submitted: 10 May 2018 11:22 Modified: 12 Jul 2018 11:00
Reporter: Jhon Lee Email Updates:
Status: Can't repeat Impact on me:
Category:MySQL Server: Replication Severity:S1 (Critical)
Version:mysql 5.7.22 OS:Red Hat (6.9)
Assigned to: CPU Architecture:x86 (vmware)
Tags: 1782, master-master, MM, replication

[10 May 2018 11:22] Jhon Lee
master-master replication
M1 execute:  optimize table forbiddenservice.t_fb_forbiddentypeï¼›
M2: show slave status\G;
        Last_SQL_Errno: 1782
        Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction 'NOT_YET_DETERMINED' at master log mysqlBin.000008, end_log_pos 50992. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
M2 error log:
[ERROR] Slave SQL for channel '234235': Worker 1 failed executing transaction 'NOT_YET_DETERMINED' at master log mysqlBin.000008, end_log_pos 50992; Error '@@SESSION.GTID_NEXT cannot be set to ANONYMOUS when @@GLOBAL.GTID_MODE = ON.' on query. Default database: ''. Query: 'optimize table forbiddenservice.t_fb_forbiddentype', Error_code: 1782.
[Warning] Slave SQL for channel '234235': The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details). Error_code: 1756
[Note] Error reading relay log event for channel '234235': slave SQL thread was killed.

How to repeat:
re-execute optimize table DBNAME.TABLENAME;

Suggested fix:

replication fix:
1. stop slave;
    set gtid_next='xxxxxxx:N';
    begin; commit;
    set gtid_next='AUTOMATIC';

2. reconfig replication;
3. star salve;
[11 Jun 2018 3:20] Jhon Lee
[25 Jun 2018 2:17] Jhon Lee
100% repeat
[12 Jul 2018 11:00] MySQL Verification Team
Hello Jhon Lee,

Thank you for the report.
I could not reproduce this issue at our end using simple master-master setup. Could you please provide configuration details from both the master environments, schema and subset of data to reproduce this issue at our end? If you can provide more information, feel free to add it to this bug and change the status back to 'Open'.

Thank you for your interest in MySQL.

[12 Jul 2018 11:01] MySQL Verification Team
test results

Attachment: 90823_5.7.22.results (application/octet-stream, text), 73.73 KiB.