Announcement

Announcement Module
Collapse
No announcement yet.

Too many GTID when executing show slave status On Mysq 5.6

Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Too many GTID when executing show slave status On Mysq 5.6

    Hi ,

    I have a problem with mysql 5.6 when GITD mode is ON.

    Executed_Gtid_Set: 45fc3ac6-b6b9-11e2-a509-00163e00215f:1-720912678:720912680-720912681:720912683-720912684:720912686:720912688-720914434:720914436-720914437:720914439-720914440:7...
    This goes on with hundereds of values.

    Would you please tell me how to solve problem ?

    Thanks so much.


  • #2
    Hi,

    It seems, there are gaps in the executed transactions. Have you ignored transactions or skipped them? In that case, mysql instead of showing a range, shows hundred of ranges. I think, the only way to clean that mess is, to recreate the slave OR reset slave.

    Comment


    • #3
      hi niljoshi

      thanks for your reply .

      How to skip it ? if skip it , replication can be executed with new master??
      I mean with new master we don't know which GTID will be excuted next

      Comment


      • #4
        Like niljoshi said it looks like you're using --replicate-do-db and/or --replicate-ignore-db settings on the slave. In this case not all of the master transactions are executed on the slave, that's why there're 'holes' in executed_set and its length is constantly growing.

        If you do indeed ignore some databases in replication then consider the possibility to not log them in the first place on the master (if you don't need them). I.e. use --binlog-do-db and/or --binlog-ignore-db on the master instead. Then all of the transactions logged on master will be executed on slave.
        There'll be no holes in the range (at least that's what I think will happen, I haven't tested it, but it seems logical to increase the GTID counter for those transactions only that are logged).
        Last edited by just1fix; 04-17-2014, 05:27 AM.

        Comment


        • #5
          thanks just1fix

          I didn't use --replicate-do-db and/or --replicate-ignore-db at my.cnf.


          Maybe that problem happen as the below context :

          When we have a SELECT command executed.
          The SESSION TEMPORARY TABLE in PROCEDURE was established.
          The Temporary often created with engine MEMORY, if many connections had been establishing , Memory will over and engine auto be switch to MYISAM.

          But MyISAM with GTID has a bug like here http://dev.mysql.com/doc/refman/5.6/...trictions.html


          LIKE this,and in many connetctions establishing.

          (MYISAM engine + GTID problem is here?)
          CREATE PROCEDURE xxxx()
          BEGIN
          -- it waste??
          CREATE TEMPORARY TABLE zzzz(
          tmpid BIGINT NOT NULL AUTO_INCREMNET,
          sum_counter BIGINT DEFAULT 0,
          PRIMARY KEY(tmpid)
          )ENGINE = MEMORY;
          -- auto extend MYISAM at over memory table limit
          INSERT INTO zzzz(sum_counter) SELECT SUM(id) FROM users WHERE status=1;

          -- result to record set
          SELECT * FROM zzzz;
          END

          Comment

          Working...
          X