Slave info show GTID information not binlog file & position

MySQL & MariaDB Percona XtraBackup
1

I’m running MySQL 5.7. GTID is currently turned off, but, in the past has been in a few OFF_PERMISSIVE states, it’s (GTID) never been fully enabled or ON.

I’m using to try and rebuild a new slave, but, whenever I use --slave-info I get a GTID rather than the expected binlog file and position.

SET GLOBAL gtid_purged=‘44c0008b-4453-11e6-9065-000f53396de0:1-8’;
CHANGE MASTER TO MASTER_AUTO_POSITION=1

The following files are generated:
[LIST]
[]xtrabackup_binlog_info
[]xtrabackup_checkpoints
[]xtrabackup_info
[]xtrabackup_logfile
[*]xtrabackup_slave_info
[/LIST]
Master and slaves all show similar:

show variables like “%gtid%”;
±---------------------------------±----------+
| Variable_name | Value |
±---------------------------------±----------+
| binlog_gtid_simple_recovery | ON |
| enforce_gtid_consistency | OFF |
| gtid_executed_compression_period | 1000 |
| gtid_mode | OFF |
| gtid_next | AUTOMATIC |
| gtid_owned | |
| gtid_purged | |
| session_track_gtids | OFF |
±---------------------------------±----------+
8 rows in set (0.00 sec)

The GTID is in gtid_executed and slave_master_info on the slaves.

Is there something else I need to do to purge / remove these from the tables, somewhere else, to get this to provide the information the standard binlog file and position?

2

I’ve gone through the steps here [url]https://avdeo.com/2015/02/03/disabling-gtid-in-mysql-replication/[/url] to ensure GTID is off, and, the processes on master don’t say binlog dump GTID - and they don’t. Yet still I get GTID in the --slave-info.

Do I need to turn GTID on then OFF or is there something I can flush?

3

This was fixed by running a RESET MASTER on the slave. The pseudo process followed was: [LIST=1]
[]Disable GTID
[]
[]
[]Select from mysql.slave_master_info
[]
[]
[] … (information from slave status and table earlier)
[]
[/LIST] When the xtrabackup was then run again, the standard FILE and POSITION was present.

Each slave is built with all master information and binary logs, and, has been migrated across hosting companies in the past so has been chained - I suspect this has contributed the issue.