在上一篇文章中,我们大概介绍了Mysql Group Replication的构架及集群搭建步骤。那么我们知道,一组优秀的集群环境有一个很必要的特性,那就是可拓展性。Group Replication的拓展性怎么样呢?我们设定如下几个场景,来看看Group Replicaiton是否方便拓展:
- 总执行的事务量较少,而且所有的binlog都保留完整。
- 总事务量较少,binlog只保留部分。
- 总事务量很大,binlog保留完整。
- 总事务量很大,binlog只保留部分。
我们在对以上几种场景进行分析
- 总事务量较少,binlog保留完整。那么我们可以直接应用所有binlog,来创建一个和现有环境相同的实例。
总事务量较少,binlog保留部分。此场景中binlog丢失,无法应用所有binlog来创建一个和现有环境相同的实例。那么我们要得到一个和现有环境相同的实例,只有复制一个现有环境中的实例,然后再将这个实例添加到集群。复制的方法我能想到的有如下几种:
- mysqldump
- xtrabackup
- 总事务量较多,binlog保留完整。我们可以和第一种环境一样,应用所有binlog来创建新实例。但是事务较多应用binlog需要非常多的时间。为了提高效率,我们还是采用复制实例的方式来创建新实例。
- 总事务较多,binlog只保留部分。这个场景和第二个场景差不多,我们也只能采用复制实例的方式来创建新的实例。
所以,除了第一个场景外,其它的最好还是备份前的的数据后,恢复到新的server上再开启同步,下面就做一下这个试验:
机器名 IP 角色
qht131 172.17.61.131 primary
qht132 172.17.61.132 secdnode1
qht133 172.17.61.133 secdnode2
qht134 172.17.61.134 secdnode3
1.检查当前mgr的状态:
mysql> select * from performance_schema.replication_group_members ; ±--------------------------±-------------------------------------±------------±------------±-------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | ±--------------------------±-------------------------------------±------------±------------±-------------+ | group_replication_applier | bb0dea82-58ed-11e8-94e5-000c29e8e89b | qht131 | 3306 | ONLINE | | group_replication_applier | bb0dea82-58ed-11e8-94e5-000c29e8e90b | qht132 | 3306 | ONLINE | | group_replication_applier | bb0dea82-58ed-11e8-94e5-000c29e8e91b | qht133 | 3306 | ONLINE | ±--------------------------±-------------------------------------±------------±------------±-------------+
建立一个表做测试数据:
mysql> drop table test_mgr; Query OK, 0 rows affected (0.05 sec) mysql> create table test_mgr (c1 int(11) primary key); Query OK, 0 rows affected (0.07 sec) mysql> insert into test_mgr values(1); Query OK, 1 row affected (0.01 sec)
将全库备份一下复制到目标新库:
[root@qht131 backup]# mysqldump -uroot -p --all-databases --triggers --routines --events --master-data=2 > dbdump.db
[root@qht131 backup]# scp dbdump.db 172.17.61.134:/u01/backup
备份之后再对数据库做一些操作:
mysql> insert into test_mgr values(2); Query OK, 1 row affected (0.00 sec) mysql> insert into test_mgr values(3); Query OK, 1 row affected (0.03 sec) mysql> select * from test_mgr; ±—+ | c1 | ±—+ | 1 | | 2 | | 3 | ±—+
2.qht134安装好数据库,将备份恢复过来:
[root@qht134 backup]# mysql -uroot -p < dbdump.db
3.配置my.cnf,配置文件注意server_id以及loose-group_replication_local_address和loose-group_replication_local_address。
[root@qht134 backup]# cat /etc/my.cnf [client] port = 3306 socket = /u01/mysql/mysql.sock [mysql] no-auto-rehash [mysqld] socket = /u01/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 server-id=10004 log_bin = /u01/mysql/mysql_bin #skip-grant-tables #innodb_flush_log_at_trx_commit=1 #sync_binlog=1 #expire_logs_days=10 #max_binlog_size=1073741824 #autocommit=off #long_query_time=15 #slow_query_log=on log_slave_updates = ON relay_log_info_repository = TABLE master_info_repository = TABLE transaction_write_set_extraction = XXHASH64 binlog_format = ROW binlog_checksum = NONE enforce_gtid_consistency = ON gtid_mode = ON loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" loose-group_replication_start_on_boot=off loose-group_replication_local_address= "172.17.61.134:33060" loose-group_replication_group_seeds= "172.17.61.131:33060,172.17.61.132:33060,172.17.61.133:33060,172.17.61.134:33060" loose-group_replication_bootstrap_group= off
重启数据库
[root@qht134 mysql]# service mysql start Starting MySQL… [ OK ]
4.修改原有节点的memeber信息:
在qht131,qht132,qht133以分别执行:
5.在新节点上建立复制用户
mysql> set global group_replication_group_seeds=‘172.17.61.131:33060,172.17.61.132:33060,172.17.61.133:33060,172.17.61.134:33060’; Query OK, 0 rows affected (0.02 sec)
mysql> set sql_log_bin=0; Query OK, 0 rows affected (0.00 sec) mysql> create user mgruser@’%’ identified by ‘mgruser’; ERROR 1396 (HY000): Operation CREATE USER failed for ‘mgruser’@’%'
mysql> set sql_log_bin=1; Query OK, 0 rows affected (0.00 sec)
对了,复制用户的信息都已经从mysqldump中恢复了过来,所以就不用重新建立了。
如果新节点不是备份恢复过来的,则需要重新建立复制用户。
6.安装复制插件以及启动新的复制节点
mysql> install plugin group_replication soname ‘group_replication.so’; #先show plugins;检查一下有没有安装好复制插件,如已安装好的话则跳过此步骤
mysql> change master to -> master_user=‘mgruser’, -> master_password=‘mgruser’ -> for channel ‘group_replication_recovery’; Query OK, 0 rows affected, 2 warnings (0.04 sec) mysql> start group_replication; Query OK, 0 rows affected (3.40 sec)
7.查询点节状态:
mysql> select * from performance_schema.replication_group_members ; ±--------------------------±-------------------------------------±------------±------------±-------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | ±--------------------------±-------------------------------------±------------±------------±-------------+ | group_replication_applier | bb0dea82-58ed-11e8-94e5-000c29e8e89b | qht131 | 3306 | ONLINE | | group_replication_applier | bb0dea82-58ed-11e8-94e5-000c29e8e89c | qht134 | 3306 | ONLINE | | group_replication_applier | bb0dea82-58ed-11e8-94e5-000c29e8e90b | qht132 | 3306 | ONLINE | | group_replication_applier | bb0dea82-58ed-11e8-94e5-000c29e8e91b | qht133 | 3306 | ONLINE | ±--------------------------±-------------------------------------±------------±------------±-------------+ 4 rows in set (0.04 sec)
发现qht134已成功加入了复制群组。
mysql> select * from test_mgr; ±—+ | c1 | ±—+ | 1 | | 2 | | 3 | ±—+ 3 rows in set (0.00 sec)
数据也同步到了最新的状态。
8.后续操作
为了下次qht131,qht132,qht133重启后的gr配置仍然有效,需要修改my.cnf的配置:
oose-group_replication_group_seeds= "172.17.61.131:33060,172.17.61.132:33060,172.17.61.133:33060,172.17.61.134:33060"
这样保证在重启数据库后,GR的配置是最新的。