# GTID Migration **URL:** \ **Category:** Percona Server for MySQL 5.6\ **Created:** [April 22, 2016, 11:17am UTC](https://forums.percona.com/t/gtid-migration/4856 "2016-04-22T11:17:15Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![andblais123](https://avatars.discourse-cdn.com/v4/letter/a/dbc845/32.png) [@andblais123](https://forums.percona.com/u/andblais123)\ **Post date:** [April 22, 2016, 11:17am UTC](https://forums.percona.com/t/gtid-migration/4856/1 "2016-04-22T11:17:15Z")
Little Background: masters running version 5.6.17-65.0-rel65.0-log no GTID enabled replicas running version 5.6.29-76.2-log We are looking to migrate all our servers to GTID. I have setup many of them already (getting ready for migration), basically I have an old master and setup a new slave to point to the master (without GTID). I set SET GLOBAL gtid\_deployment\_step = ON on the new replica before I sync up the replica using a backup that comes from xtrabackup. This all works fine, database sync’s up and catches up with no errors. I can see the GTID information in the show master status and show slave status information. What we found was after about a week to 3 weeks…it’s a bit hard to tell when, the GTID information seems to stop being used. The show master status and show slave status both stop showing GTID information. I can check GTID variables using show variables like ‘%version%’ and everything looks OK (except that the gtid\_executed is blank which is always blank even on a working server so not sure if this is actually a problem, on a functioning server gtid\_purged would have a GTID value)…IE I get: mysql\> show variables like ‘%gtid%’; ±--------------------------------±----------+ | Variable\_name | Value | ±--------------------------------±----------+ | binlog\_gtid\_simple\_recovery | OFF | | enforce\_gtid\_consistency | ON | | gtid\_deployment\_step | ON | | gtid\_executed | | | gtid\_mode | ON | | gtid\_next | AUTOMATIC | | gtid\_owned | | | gtid\_purged | | | simplified\_binlog\_gtid\_recovery | OFF | ±--------------------------------±----------+ We have rerun the same process on 7 different clusters and the oldest ones (5) seem to have lost GTID usage and the latest ones (2) we sync’ed up are still functioning as expected. I have also looked at the mysql logs and there is no indication of issues. Replication itself seams to work just fine…(the master binlog position on the replica matches the binlog position on the master). I have looked all over for a bug of this type but so far no hits. Any ideas or suggestions from you members? Many thanks, Andre ---
**Author:** ![jrivera](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/jrivera/32/13_2.png) [@jrivera](https://forums.percona.com/u/jrivera)\ **Post date:** [April 23, 2016, 6:20am UTC](https://forums.percona.com/t/gtid-migration/4856/2 "2016-04-23T06:20:03Z")
Can you paste full SHOW SLAVE STATUS\G from the replica in question? ---
**Author:** ![andblais123](https://avatars.discourse-cdn.com/v4/letter/a/dbc845/32.png) [@andblais123](https://forums.percona.com/u/andblais123)\ **Post date:** [April 25, 2016, 8:48am UTC](https://forums.percona.com/t/gtid-migration/4856/3 "2016-04-25T08:48:52Z")
Thank for you help Jrivera. As requested here is the slave status, normally I would have values for Retrieved\_Gtid\_Set and Executed\_Gtid\_Set: mysql\> show slave status \G; \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* Slave\_IO\_State: Waiting for master to send event Master\_Host: [db-master.hostname.com](http://db-master.hostname.com) Master\_User: repl Master\_Port: 3306 Connect\_Retry: 60 Master\_Log\_File: mysqld-bin.001440 Read\_Master\_Log\_Pos: 629057388 Relay\_Log\_File: mysqld-relay-bin.000294 Relay\_Log\_Pos: 629057583 Relay\_Master\_Log\_File: mysqld-bin.001440 Slave\_IO\_Running: Yes Slave\_SQL\_Running: Yes Replicate\_Do\_DB: Replicate\_Ignore\_DB: Replicate\_Do\_Table: Replicate\_Ignore\_Table: Replicate\_Wild\_Do\_Table: Replicate\_Wild\_Ignore\_Table: Last\_Errno: 0 Last\_Error: Skip\_Counter: 0 Exec\_Master\_Log\_Pos: 629057388 Relay\_Log\_Space: 629057836 Until\_Condition: None Until\_Log\_File: Until\_Log\_Pos: 0 Master\_SSL\_Allowed: No Master\_SSL\_CA\_File: Master\_SSL\_CA\_Path: Master\_SSL\_Cert: Master\_SSL\_Cipher: Master\_SSL\_Key: Seconds\_Behind\_Master: 0 Master\_SSL\_Verify\_Server\_Cert: No Last\_IO\_Errno: 0 Last\_IO\_Error: Last\_SQL\_Errno: 0 Last\_SQL\_Error: Replicate\_Ignore\_Server\_Ids: Master\_Server\_Id: 168160 Master\_UUID: f34d3ed9-eba6-11e3-8382-22000b2b010f Master\_Info\_File: /data/mysql/master.info SQL\_Delay: 0 SQL\_Remaining\_Delay: NULL Slave\_SQL\_Running\_State: Slave has read all relay log; waiting for the slave I/O thread to update it Master\_Retry\_Count: 86400 Master\_Bind: Last\_IO\_Error\_Timestamp: Last\_SQL\_Error\_Timestamp: Master\_SSL\_Crl: Master\_SSL\_Crlpath: Retrieved\_Gtid\_Set: Executed\_Gtid\_Set: Auto\_Position: 0 1 row in set (0.00 sec) ---
**Author:** ![andblais123](https://avatars.discourse-cdn.com/v4/letter/a/dbc845/32.png) [@andblais123](https://forums.percona.com/u/andblais123)\ **Post date:** [April 26, 2016, 9:34am UTC](https://forums.percona.com/t/gtid-migration/4856/4 "2016-04-26T09:34:05Z")
I thought I would try something with the replica that showed behaviors of having issues and chained another replica to it. The backup from 1st tier replica did not include GTID information (using innobackup) even though GTID is turned on and so I ran the change master command with CHANGE MASTER TO MASTER\_AUTO\_POSITION=1; with the binlog name in the backup but left the position out. Started the Slave and to my surprise the slave thread connected and show slave status shows Slave\_IO\_Running: yes and Slave\_SQL\_Running: yes, no errors and the Master\_Log\_File is correct and the Read\_Master\_Log\_Position keeps up with the 1st level replica. Looked completely clean to me except I expected it to have Retrieved\_Gtid\_Set and Executed\_Gtid\_Set to have values. The unexpected behaviour was this backup was from 3 days ago on a busy servers so I expected seconds behind to be in the days to catch up but it connected with 0 seconds behind. Expecting something is still wrong I decided to count lines in a busy table and found that the table was missing 40K rows. I ran the server for another day and the 40K row stayed consistent and the show slave status showed that the database was still following the master log position. I was able to connect a replica to a another server without error but in fact I had lost a lot of data…not cool.