Experimental scenario description and purpose:
The master-slave mode of GTID is currently one master and one slave. I hope to add another slave to make a mode of one master and two slaves. Since the tested database is not large, back up the data through mysqldump. If the database is relatively large, you can find a way to build a new slave through the backup of other slaves.
1. Backup master
mysql> FLUSH TABLE WITH READ LOCK; Query OK, 0 rows affected (0.01 sec)
[root@qht131 backup]# mysqldump -u root -p --lock-all-tables --master-data=2 --flush-logs --all-databases --triggers --routines --events > full.sql
[root@qht131 backup]# scp full.sql 172.17.61.133:/u01/backup
Record the current gtid:
mysql> show global variables like 'gtid_%'; +----------------------------------+-------------------------------------------+ | Variable_name | Value | +----------------------------------+-------------------------------------------+ | gtid_executed | 8d8746fb-2cc6-11e8-b1b6-000c295c63e0:1-11 | | gtid_executed_compression_period | 1000 | | gtid_mode | ON | | gtid_owned | | | gtid_purged | | +----------------------------------+-------------------------------------------+ 5 rows in set (0.09 sec)
If it is Xtrabackup, the Xtrabackup_binlog_info file contains the information of global.gtid_purged='XXXXXX:XXXX'.
2. Build the database on the new slave and restore the backup of the Master
2.1. Library building method: https://blog.csdn.net/jolly10/article/details/79566640
2.2. Restore full backup:
[root@qht133 backup]# mysql -uroot -p < full.sql
2.3 Modify /etc/my.cnf on the new slave and enable gtid
[root@qht133 backup]# cat /etc/my.cnf [mysqld] socket = /usr/local/mysql/mysql.sock character_set_server= utf8 init_connect= 'SET NAMES utf8' basedir= /usr/local/mysql datadir= /u01/mysql socket = /u01/mysql/mysql.sock log-error= /u01/log/mysql/mysql_3306.err pid-file= /u01/mysql/mysqld.pid lower_case_table_names = 1 sql_mode= STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION secure-file-priv = /u01/backup gtid_mode=on #Enable gtid enforce_gtid_consistency=on #Force gtid consistency server-id=10003 #server id skip_slave_start=1 #Do not automatically apply the recovery process after the standby database is turned on #log_bin = /u01/mysql/mysql_bin #skip-grant-tables #innodb_flush_log_at_trx_commit=1 #sync_binlog=1 relay-log=/u01/mysql/slave_relay_bin expire_logs_days=10 relay_log_recovery=on relay_log_info_repository=TABLE
Restart the database:
[root@qht133 backup]# service mysql restart Shutting down MySQL.. [ OK ] Starting MySQL.. [ OK ]
3. In order to check the correctness of the new slave replication, do some operations on the master to see if the slave can synchronize correctly.
mysql> use l5m Database changed mysql> select count(*) from test_emp; +----------+ | count(*) | +----------+ | 1099000 | +----------+ 1 row in set (0.67 sec) mysql> delete from test_emp limit 1000; Query OK, 1000 rows affected (0.08 sec) mysql> select count(*) from test_emp; +----------+ | count(*) | +----------+ | 1098000 | +----------+ 1 row in set (0.18 sec) mysql> commit; Query OK, 0 rows affected (0.00 sec) mysql> show global variables like 'gtid_%'; +----------------------------------+-------------------------------------------+ | Variable_name | Value | +----------------------------------+-------------------------------------------+ | gtid_executed | 8d8746fb-2cc6-11e8-b1b6-000c295c63e0:1-12 | | gtid_executed_compression_period | 1000 | | gtid_mode | ON | | gtid_owned | | | gtid_purged | | +----------------------------------+-------------------------------------------+ 5 rows in set (0.01 sec)
4. Start replication on the new slave:
First check the current gtid:
mysql> show global variables like 'gtid_%'; +----------------------------------+-------------------------------------------+ | Variable_name | Value | +----------------------------------+-------------------------------------------+ | gtid_executed | 8d8746fb-2cc6-11e8-b1b6-000c295c63e0:1-11 | | gtid_executed_compression_period | 1000 | | gtid_mode | ON | | gtid_owned | | | gtid_purged | 8d8746fb-2cc6-11e8-b1b6-000c295c63e0:1-11 | +----------------------------------+-------------------------------------------+ 5 rows in set (0.00 sec)
The new slave library is recovered from the master, and gtid_purged now has a value of 1-11 automatically, and there is no need to manually execute reset master; set global gtid_purged = 'xxxxx', it seems that mysql5.7 has strengthened this aspect again! ( @@global.gtid_purged can be dynamically set only when @@global.gtid_executed is empty. Therefore, @@global.gtid_executed can be cleared by RESET MASTER. )
Just start copying as follows:
mysql> change master to
-> master_host='172.17.61.131',
-> master_port=3306,
-> master_user='repl',
-> master_password='repl',
-> master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.07 sec)
mysql> start slave;
mysql> show global variables like 'gtid_%'; +----------------------------------+-------------------------------------------+ | Variable_name | Value | +----------------------------------+-------------------------------------------+ | gtid_executed | 8d8746fb-2cc6-11e8-b1b6-000c295c63e0:1-12 | | gtid_executed_compression_period | 1000 | | gtid_mode | ON | | gtid_owned | | | gtid_purged | 8d8746fb-2cc6-11e8-b1b6-000c295c63e0:1-12 | +----------------------------------+-------------------------------------------+ 5 rows in set (0.01 sec)
Verify that the data modified on the master is synchronized after full backup:
mysql> use l5m; Database changed mysql> select count(*) from test_emp; +----------+ | count(*) | +----------+ | 1098000 | +----------+ 1 row in set (0.40 sec)
There is no problem, the data is synchronized to the new slave.
refer to:
https://www.cnblogs.com/zejin2008/p/7705473.html
http://www.cnblogs.com/luckcs/articles/6295992.html