Bug #69045 replication was broken while executing flush tables

• Submitted: 24 Apr 2013 2:01
• Modified: 6 May 2013 10:11
• Reporter: zhai weixiang (OCA)
• Status: Closed
• Category: MySQL Server: Replication
• Severity: S3 (Non-critical)
• Version: 5.6.11
• OS: Any
• CPU Architecture: Any

[24 Apr 2013 2:01] zhai weixiang

Description:
I have configured the master and slave using the same configure file.

enforce_gtid_consistency = ON
gtid_mode = ON

after executing 'flush tables' on master , the replication was broken:

Last_SQL_Error: Error 'Cannot execute statements with implicit commit inside a transaction when @@SESSION.GTID_NEXT != AUTOMATIC or @@SESSION.GTID_NEXT_LIST != NULL.' on query. Default database: ''. Query: 'flush tables'

I noticed some details in the changelog of 5.6.11:

Executing a statement that performs an implicit commit but whose changes are not logged when gtid_next is set to any value other than AUTOMATIC is not permitted. Now in such cases, the statement fails with an error

so, this is an expected behavior  on master ,  but it's really very rude  to simply broken the replication.

How to repeat:
using default option and execute 'flush tables' or 'flush privileges ' or any other 'flush operation' on master server.

Suggested fix:
I don't know

[24 Apr 2013 12:57] MySQL Verification Team

Hello zhai weixiang,

Thank you for the report.
Verified as described.

Thanks,
Umesh

[6 May 2013 10:11] Jon Stephens

Thank you for your bug report. This issue has been committed to our source repository of that product and will be incorporated into the next release.

If necessary, you can access the source repository and build the latest available version, including the bug fix. More information about accessing the source trees is available at

    http://dev.mysql.com/doc/en/installing-source.html

[6 May 2013 10:13] Jon Stephens

Fixed in 5.6+. Documented in the MySQL 5.6.12 and 5.7.2 changelogs as follows:

        Issuing FLUSH TABLES on a GTID enabled master caused replication
        to fail. It was found that this was introduced by the fix for
        Bug #16062608, which disallowed statements that perform an
        implicit commit but whose changes are not logged when gtid_next
        is set to any value other than AUTOMATIC. The changes made in
        that fix have been reverted, and such statements are no longer
        disallowed.

Also updated portions of the Manual covering these statements/versions.

Closed.