我們知道，一組優秀的叢集環境有一個很必要的特性，那就是可擴充性。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 ;

±--------------------------±-------------------------------------±------------±------------±-------------+

±--------------------------±-------------------------------------±------------±------------±-------------+

±--------------------------±-------------------------------------±------------±------------±-------------+
1
建立一個表做測試資料：

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)
1
將全庫備份一下複製到目標新庫：
[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
1
備份之後再對資料庫做一些操作：

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 |

±—+
1

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
1
重啟資料庫
1

[root@qht134 mysql]# service mysql start

Starting MySQL… [ OK ]
1
4.修改原有節點的memeber資訊：
在qht131,qht132,qht133以分別執行：

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)
1
5.在新節點上建立複製使用者

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’@’%'
1

mysql> set sql_log_bin=1;

Query OK, 0 rows affected (0.00 sec)
1
對了，複製使用者的資訊都已經從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)
1
7.查詢點節狀態：

mysql> select * from performance_schema.replication_group_members ;

±--------------------------±-------------------------------------±------------±------------±-------------+

±--------------------------±-------------------------------------±------------±------------±-------------+

±--------------------------±-------------------------------------±------------±------------±-------------+

4 rows in set (0.04 sec)
1
發現qht134已成功加入了複製群組。

mysql> select * from test_mgr;

±—+

| c1 |

±—+

| 1 |

| 2 |

| 3 |

±—+

3 rows in set (0.00 sec)
1
資料也同步到了最新的狀態。
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"
1
這樣保證在重啟資料庫後，GR的配置是最新的。

轉自：https://blog.csdn.net/gaoyingying1992/article/details/84290736

Mysql增加節點

相關文章