mysql gtid setup_mysql-5.6 Gtid Master/slave SetUp

1.How to set up a new slave

The first thing that we need to know is that now Binary Logs and Position are not needed anymore with GTID enabled. Instead we need to know in which GTID is the master and set it on the slave. MySQL keeps two global variables with GTID numbers on it:

gtid_executed: it contains a representation of the set of all transaction logged in the binary log

gtid_purged: it contains a representation of the set of all transactions deleted from the binary log

So now, the process is the following:

take a backup from the master and store the value of gtid_executed

restore the backup on the slave and set gtid_purged with the value of gtid_executed from the master

The new mysqldump can do those tasks for us. Let’s see an example of how to take a backup from the master and restore it on the slave to set up a new replication server.

Shell

master > show global variables like 'gtid_executed';

+---------------+-------------------------------------------+

| Variable_name | Value                                     |

+---------------+-------------------------------------------+

| gtid_executed | 9a511b7b-7059-11e2-9a24-08002762b8af:1-13 |

+---------------+-------------------------------------------+

master > show global variables like 'gtid_purged';

+---------------+------------------------------------------+

| Variable_name | Value                                    |

+---------------+------------------------------------------+

| gtid_purged   | 9a511b7b-7059-11e2-9a24-08002762b8af:1-2 |

+---------------+------------------------------------------+

Now we take a backup with mysqldump from the master:

Shell

# mysqldump --all-databases --single-transaction --triggers --routines --host=127.0.0.1 --port=18675 --user=msandbox --password=msandbox > dump.sql

(mysqldump -h 127.0.0.1 -P3306 -u root –B clusterdb > /home/billy/mysql/clusterdb.sql)

It will contain the following line:

Shell

# grep PURGED dump.sql

SET @@GLOBAL.GTID_PURGED='9a511b7b-7059-11e2-9a24-08002762b8af:1-13';

Therefore during the dump recover process on the slave it will set GTID_PURGED to the GTID_EXECUTED value from the master.

So now, we just need to recover the dump and start the replication:

Shell

slave1 > show global variables like 'gtid_executed';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| gtid_executed |       |

+---------------+-------+

slave1 > show global variables like 'gtid_purged';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| gtid_purged   |       |

+---------------+-------+

slave1 > slave1> source test.sql;

[...]

slave1 > show global variables like 'gtid_executed';

+---------------+-------------------------------------------+

| Variable_name | Value                                     |

+---------------+-------------------------------------------+

| gtid_executed | 9a511b7b-7059-11e2-9a24-08002762b8af:1-13 |

+---------------+-------------------------------------------+

slave1 > show global variables like 'gtid_purged';

+---------------+-------------------------------------------+

| Variable_name | Value                                     |

+---------------+-------------------------------------------+

| gtid_purged   | 9a511b7b-7059-11e2-9a24-08002762b8af:1-13 |

+---------------+-------------------------------------------+

The last step is to configure the slave using the auto-configuration method of GTID:

Shell

slave1 > CHANGE MASTER TO MASTER_HOST="127.0.0.1", MASTER_USER="msandbox", MASTER_PASSWORD="msandbox", MASTER_PORT=18675, MASTER_AUTO_POSITION = 1;

2.How to restore a slave in a bad and fast way

Let’s imagine that our slave has been down for several days and the binary logs from the master have been purged. This is the error we are going to get:

Shell

Slave_IO_Running: No

Slave_SQL_Running: Yes

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

So, let’s try to solve it. First we have the bad and fast way, that is, point to another GTID that the master has in the binary logs. First, we get the GTID_EXECUTED from the master:

Shell

master > show global variables like 'GTID_EXECUTED';

+---------------+-------------------------------------------+

| Variable_name | Value                                     |

+---------------+-------------------------------------------+

| gtid_executed | 9a511b7b-7059-11e2-9a24-08002762b8af:1-14 |

+---------------+-------------------------------------------+

And we set it on the slave:

Shell

slave> set global GTID_EXECUTED="9a511b7b-7059-11e2-9a24-08002762b8af:1-14"

ERROR 1238 (HY000): Variable 'gtid_executed' is a read only variable

Error! Remember, we get the GTID_EXECUTED from the master and set is as GTID_PURGED on the slave.

Shell

slave1 > set global GTID_PURGED="9a511b7b-7059-11e2-9a24-08002762b8af:1-14";

ERROR 1840 (HY000): GTID_PURGED can only be set when GTID_EXECUTED is empty.

Error again, GTID_EXECUTED should be empty before changing GTID_PURGED manually but we can’t change it with SET because is a read only variable. The only way to change it is with reset master (yes, on a slave server):

Shell

slave1> reset master;

slave1 > show global variables like 'GTID_EXECUTED';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| gtid_executed |       |

+---------------+-------+

slave1 > set global GTID_PURGED="9a511b7b-7059-11e2-9a24-08002762b8af:1-14";

slave1> start slave io_thread;

slave1> show slave status\G

[...]

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

[...]

Now, if you don’t get any error like primary/unique key duplication then you can run the?pt-table-checksum?and?pt-table-sync.

3.How to restore a slave in a good and slow way

The good way is mysqldump again. We take a dump from the master like we saw before and try to restore it on the slave:

Shell

slave1 [localhost] {msandbox} ((none)) > source test.sql;

[...]

ERROR 1840 (HY000): GTID_PURGED can only be set when GTID_EXECUTED is empty.

[...]

Wop! It is important to mention that these kind of error messages can dissapear on the shell buffer because the restore of the dump will continue. Be cautious.

Same problem again so same solution too:

Shell

slave1> reset master;

slave1> source test.sql;

slave1> start slave;

slave1> show slave status\G

[...]

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

[...]