立即登录 免费注册

PXC、MGR、MGC集群之新建、备份、恢复操纵步骤

代码 代码 1771 人阅读 | 0 人回复

<
导读  
              做者：沃趣-罗小波             提要：本文包含PXC、MGR、MGC散群之新建、备份、规复操纵步调详解，果篇幅较少，本文仅节与MGR部门内乱容。         
   若念理解完好文章，可至文终获得
  

关于PXC、MGC、MGR三种MySQL的散群复造架构妙技，实在正在更早之前，我做过一个视频版的 "PXC、MGC & MGR 道理取理论比照" 系列课程，但有部门同窗以为里边的内乱容短少具体操纵步调。以是，明天我便将PXC、MGR、MGC散群之新建、备份、规复操纵的具体步调收拾整顿出去分享给大家，期望能赞助大家更好天游玩PXC、MGC、MGR

   
    1、本文目次  
1、PXC1.1. 散群初初化1.1.1. 第一个节面(init)1.1.2. 第两个节面(sst)1.1.3. 第三个节面(backup recovery)1.2. 散群新删节面1.2.1. 利用备份散规复1.2.2. 齐量SST参加散群1.3. 单节面crash的规复1.4. 大都节面crash的规复1.4.1. crash节面数据已丧失且能够本天规复1.4.2. crash节面数据丧失1.5. 全部散群crash的规复1.5.1. 利用备份规复1.5.2. 利用crash节面的datadir数据卷停止规复2、MGC3、MGR   3.1. 散群初初化     3.1.1. 第一个节面(init)3.1.2. 第两个节面(齐量复造)3.1.3. 第三个节面(backup recovery)   3.2. 散群新删节面3.2.1. 利用备份散规复3.2.2. 齐量复造参加散群   3.3. 单节面crash的规复   3.4. 大都节面crash的规复3.4.1. crash节面数据已丧失且能够本天规复3.4.2. crash节面数据丧失   3.5. 全部散群crash的规复3.5.1. 利用备份规复3.5.2. 利用crash节面的datadir数据卷停止规复

   
    2、布景阐明      效劳器情况  

  •        kvm ip：10.10.30.162/163/164
  •        CPU：8 vcpus
  •        内乱存：16G
  •        磁盘：data 100G flash卡，binlog 100G flash卡

   数据库版本  

  •        MGC：MariaDB 10.2.12
  •        MGR：MySQL 5.7.21
  •        PXC：Percona-Xtradb-Cluster 5.7.21

   sysbench版本  

  •        sysbench 1.0.7
  •        制数目：8个表，单表500W数据量


   PS  

  •        PXC：为Percona Xtradb Cluster的缩写
  •        MGR：为MySQL Group Replication的缩写
  •        MGC：为MariaDB Galera Cluster的缩写

   
   
    3、本文节选：   
    3、MGR  3.1. 散群初初化

3.1.1. 第一个节面(init)



  • 数据库初初化（略）
  • 枢纽设置
  1. server_id=3306162
  2. sync_binlog=10000
  3. innodb_flush_log_at_trx_commit = 2
  4. binlog-checksum=NONE
  5. innodb_support_xa=OFF
  6. auto_increment_increment=3
  7. auto_increment_offset=1
  8. binlog_row_image=full
  9. transaction-write-set-extraction=XXHASH64
  10. loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
  11. loose-group_replication_single_primary_mode=OFF
  12. loose-group_replication_enforce_update_everywhere_checks=ON
  13. loose-group_replication_start_on_boot=on
  14. loose-group_replication_ip_whitelist=&#39;0.0.0.0/0&#39;
  15. loose-group_replication_local_address=&#39;10.10.30.162:24901&#39;
  16. loose-group_replication_group_seeds=&#39;10.10.30.162:24901,10.10.30.163:24901,10.10.30.164:24901&#39;
  17. loose-group_replication_bootstrap_group=OFF
  18. report_host=&#39;node1&#39;
复造代码


  • 设置hosts分析记载(有DNS即系效劳的情况无需设置)
  
  1. [root@localhost ~]# cat /etc/hosts                                                                                                                                                                                            
  2. ......
  3. 10.10.30.162 node1 mysql1
  4. 10.10.30.163 node2 mysql2
  5. 10.10.30.164 node3 mysql3
复造代码


  • 启动节面(非散群方法)
  1. # 存活节面截至组复造插件
  2. root@localhost : (none) 11:51:15> stop group_replication;
  3. Query OK, 0 rows affected (1 min 27.08 sec)
  4. root@localhost : sbtest 11:52:10> set global read_only=1;set global super_read_only=1;
  5. Query OK, 0 rows affected (0.00 sec)
  6. Query OK, 0 rows affected (0.00 sec)
  7. # 能够看到已提交事件被回滚
  8. root@localhost : sbtest 11:29:02> delete from sbtest1 where id=1;
  9. ......
  10. ERROR 3101 (HY000): Plugin instructed the server to rollback the current transaction.
复造代码


  • 创立复造战备份用户
  1. SET SQL_LOG_BIN=0;
  2. CREATE USER &#39;xtrabackup&#39;@&#39;localhost&#39; IDENTIFIED BY &#39;xtrabackuppass&#39;;
  3. GRANT SELECT, LOCK TABLES, SUPER, REPLICATION CLIENT, REPLICATION SLAVE, RELOAD, CREATE TABLESPACE, PROCESS ON *.* TO &#39;xtrabackup&#39;@&#39;localhost&#39;;
  4. grant DROP, CREATE, INSERT on mysql.ibbackup_binlog_marker to  &#39;xtrabackup&#39;@&#39;localhost&#39;;
  5. CREATE USER repl@&#39;%&#39; IDENTIFIED BY &#39;password&#39;;
  6. GRANT REPLICATION SLAVE ON *.* TO repl@&#39;%&#39; ;
  7. SET SQL_LOG_BIN=1;
  8. FLUSH PRIVILEGES; 
复造代码


  • 装置插件并设置group replication
  1. INSTALL PLUGIN group_replication SONAME &#39;group_replication.so&#39;;
  2. CHANGE MASTER TO MASTER_USER=&#39;repl&#39;, MASTER_PASSWORD=&#39;password&#39; FOR CHANNEL &#39;group_replication_recovery&#39;;
  3. FLUSH PRIVILEGES ;
复造代码


  • 启动散群组复造插件
  1. set global group_replication_bootstrap_group=ON;
  2. start group_replication;
  3. set global group_replication_bootstrap_group=OFF;
复造代码


  • 查抄散群组复造节面形态
  1. #检察形态能否为online
  2. root@localhost : (none) 03:39:20> SELECT * FROM performance_schema.replication_group_members;
  3. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  4. | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
  5. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  6. | group_replication_applier | 2d623f55-2111-11e8-9cc3-0025905b06da | node1      |        3306 | ONLINE      |
  7. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  8. 1 row in set (0.00 sec)
复造代码

PS：MGR更多的设置参数参考模板链接以下：
https://github.com/Percona-Lab/percona-docker/blob/master/pgr-57/node.cnf
3.1.2. 第两个节面(齐量复造)



  • 数据库初初化（略）
  • 枢纽设置
  1. server_id=3306163
  2. sync_binlog=10000
  3. innodb_flush_log_at_trx_commit = 2
  4. innodb_support_xa=OFF
  5. binlog-checksum=NONE
  6. auto_increment_increment=3
  7. auto_increment_offset=2
  8. binlog_row_image=full
  9. transaction-write-set-extraction=XXHASH64
  10. loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
  11. loose-group_replication_single_primary_mode=OFF
  12. loose-group_replication_enforce_update_everywhere_checks=ON
  13. loose-group_replication_start_on_boot=on
  14. loose-group_replication_ip_whitelist=&#39;0.0.0.0/0&#39;
  15. loose-group_replication_local_address=&#39;10.10.30.163:24901&#39;
  16. loose-group_replication_group_seeds=&#39;10.10.30.162:24901,10.10.30.163:24901,10.10.30.164:24901&#39;
  17. loose-group_replication_bootstrap_group=OFF
  18. report_host=&#39;node2&#39;
复造代码


  • 设置hosts分析记载(有DNS即系效劳的情况无需设置)
  
  1. [root@localhost ~]# cat /etc/hosts                                                                                                                                                                                            
  2. ......
  3. 10.10.30.162 node1 mysql1
  4. 10.10.30.163 node2 mysql2
  5. 10.10.30.164 node3 mysql3
复造代码


  • 启动节面(非散群方法)
  1. # 存活节面截至组复造插件
  2. root@localhost : (none) 11:51:15> stop group_replication;
  3. Query OK, 0 rows affected (1 min 27.08 sec)
  4. root@localhost : sbtest 11:52:10> set global read_only=1;set global super_read_only=1;
  5. Query OK, 0 rows affected (0.00 sec)
  6. Query OK, 0 rows affected (0.00 sec)
  7. # 能够看到已提交事件被回滚
  8. root@localhost : sbtest 11:29:02> delete from sbtest1 where id=1;
  9. ......
  10. ERROR 3101 (HY000): Plugin instructed the server to rollback the current transaction.
复造代码


  • 创立复造战备份用户
  1. SET SQL_LOG_BIN=0;
  2. CREATE USER &#39;xtrabackup&#39;@&#39;localhost&#39; IDENTIFIED BY &#39;xtrabackuppass&#39;;
  3. GRANT SELECT, LOCK TABLES, SUPER, REPLICATION CLIENT, REPLICATION SLAVE, RELOAD, CREATE TABLESPACE, PROCESS ON *.* TO &#39;xtrabackup&#39;@&#39;localhost&#39;;
  4. grant DROP, CREATE, INSERT on mysql.ibbackup_binlog_marker to  &#39;xtrabackup&#39;@&#39;localhost&#39;;
  5. CREATE USER repl@&#39;%&#39; IDENTIFIED BY &#39;password&#39;;
  6. GRANT REPLICATION SLAVE ON *.* TO repl@&#39;%&#39; ;
  7. SET SQL_LOG_BIN=1;
  8. FLUSH PRIVILEGES; 
复造代码


  • 装置插件并设置group replication
  1. INSTALL PLUGIN group_replication SONAME &#39;group_replication.so&#39;;
  2. CHANGE MASTER TO MASTER_USER=&#39;repl&#39;, MASTER_PASSWORD=&#39;password&#39; FOR CHANNEL &#39;group_replication_recovery&#39;;
  3. FLUSH PRIVILEGES ;
复造代码


  • 启动散群组复造插件
  1. reset master;
  2. start group_replication;
复造代码


  • 查抄散群组复造节面形态
  1. #检察形态能否为online
  2. root@localhost : (none) 03:45:24> SELECT * FROM performance_schema.replication_group_members;
  3. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  4. | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
  5. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  6. | group_replication_applier | 2d623f55-2111-11e8-9cc3-0025905b06da | node1      |        3306 | ONLINE      |
  7. | group_replication_applier | f64f9fb6-2da4-11e8-96bd-525400c33752 | node2      |        3306 | ONLINE      |
  8. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  9. 2 rows in set (0.00 sec)
复造代码


  • 检察节面复造提早取使用状况
  1. root@localhost : (none) 06:48:32> select * from performance_schema.replication_group_member_stats where MEMBER_ID=@@server_uuid\G;
  2. *************************** 1. row ***************************
  3.                       CHANNEL_NAME: group_replication_applier
  4.                           VIEW_ID: 15218000786938271:11
  5.                         MEMBER_ID: 0a1e8349-2e87-11e8-8c9f-525400bdd1f2
  6.       COUNT_TRANSACTIONS_IN_QUEUE: 287640 # 该字段显现当前领受到的relay log取当前使用到的relay log之间的事件差别
  7.         COUNT_TRANSACTIONS_CHECKED: 0
  8.           COUNT_CONFLICTS_DETECTED: 0
  9. COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
  10. TRANSACTIONS_COMMITTED_ALL_MEMBERS: 2d623f55-2111-11e8-9cc3-0025905b06da:1-2,
  11. aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-13779 # 该字段显现当前节面使用到的日记对应的GTID
  12.     LAST_CONFLICT_FREE_TRANSACTION: 
  13. 1 row in set (0.02 sec)
复造代码


  • PS：该方法必需包管散群中已有节面的binlog已施行过清算，一旦有清算，新减节面没法经由过程齐量binlog复造去参加散群
3.1.3. 第三个节面(backup recovery)



  • 起首，利用sysbench制作一些测试数据，然后，利用sysbench连续对散群倡议oltp压力
  1. # 创立数据库
  2. root@localhost : (none) 01:44:33> create database sbtest;
  3. Query OK, 1 row affected (0.00 sec)
  4. # 利用sysbench制数
  5. sysbench --db-driver=mysql --time=180 --threads=8 --report-interval=1 --mysql-socket=/home/mysql/data/mysqldata1/sock/mysql.sock --mysql-port=3306 --mysql-user=qbench --mysql-password=qbench --mysql-db=sbtest --tables=8 --table-size=5000000 oltp_read_write --db-ps-mode=disable prepare
  6. # 利用sysbench减压
  7. sysbench --db-driver=mysql --time=99999 --threads=8 --report-interval=1 --mysql-socket=/home/mysql/data/mysqldata1/sock/mysql.sock --mysql-port=3306 --mysql-user=qbench --mysql-password=qbench --mysql-db=sbtest --tables=8 --table-size=5000000 oltp_read_write --db-ps-mode=disable run
复造代码


  • 枢纽设置
  1. server_id=3306164
  2. sync_binlog=10000
  3. innodb_flush_log_at_trx_commit = 2
  4. innodb_support_xa=OFF
  5. binlog-checksum=NONE
  6. auto_increment_increment=3
  7. auto_increment_offset=3
  8. binlog_row_image=full
  9. transaction-write-set-extraction=XXHASH64
  10. loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
  11. loose-group_replication_single_primary_mode=OFF
  12. loose-group_replication_enforce_update_everywhere_checks=ON
  13. loose-group_replication_start_on_boot=on
  14. loose-group_replication_ip_whitelist=&#39;0.0.0.0/0&#39;
  15. loose-group_replication_local_address=&#39;10.10.30.164:24901&#39;
  16. loose-group_replication_group_seeds=&#39;10.10.30.162:24901,10.10.30.163:24901,10.10.30.164:24901&#39;
  17. loose-group_replication_bootstrap_group=OFF
  18. report_host=&#39;node3&#39;
复造代码


  • 设置hosts分析记载(有DNS即系效劳的情况无需设置)
  
  1. [root@localhost ~]# cat /etc/hosts                                                                                                                                                                                            
  2. ......
  3. 10.10.30.162 node1 mysql1
  4. 10.10.30.163 node2 mysql2
  5. 10.10.30.164 node3 mysql3
复造代码


  • 正在第两个节面长进止备份，并把备份传输到第三个节面上
  1. innobackupex --defaults-file=/etc/my.cnf --slave-info  \
  2. --user=xtrabackup --password=xtrabackuppass --no-timestamp \
  3. --stream=tar ./ | ssh root@10.10.30.164 "cat - > /archive/backup/backup_`date +%Y%m%d`.tar"
复造代码


  • 利用备份停止规复
  1. # innobackupex施行apply-log并move-back备份数据到datadir下
  2. [root@localhost backup]# tar xvf backup_20180322.tar
  3. [root@localhost backup]# innobackupex --apply-log ./
  4. [root@localhost backup]# rm -rf /data/mysqldata1/{undo,innodb_ts,innodb_log,mydata,binlog,relaylog,binlog,slowlog,tmpdir}/*
  5. [root@localhost backup]# innobackupex --defaults-file=/etc/my.cnf --move-back ./
  6. ......
复造代码


  • 一般启动节面
  1. chown mysql.mysql /data -R
  2. mysqld_safe --defaults-file=/etc/my.cnf --loose-group_replication_start_on_boot=off &
复造代码


  • 检察备份文件中GTID地位
  1. [root@localhost backup]# cat xtrabackup_binlog_info 
  2. mysql-bin.000147        103011527      2d623f55-2111-11e8-9cc3-0025905b06da:1-3,
  3. aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-87512845
复造代码


  • 登录数据库，施行重设gtid，并从头推起group replication
  1. root@localhost : (none) 01:38:35> reset master;
  2. Query OK, 0 rows affected (0.02 sec)
  3. root@localhost : (none) 01:39:25> set global gtid_purged=&#39;2d623f55-2111-11e8-9cc3-0025905b06da:1-3,aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-87512845&#39;;
  4. Query OK, 0 rows affected (0.00 sec)
  5. root@localhost : (none) 01:39:53> set global group_replication_start_on_boot=on;
  6. Query OK, 0 rows affected (0.00 sec)
  7. root@localhost : (none) 01:40:59> start group_replication;
  8. Query OK, 0 rows affected (2.66 sec)
复造代码


  • 查抄散群组复造节面形态
  1. #检察形态能否为online，
  2. root@localhost : (none) 11:16:52> SELECT * FROM performance_schema.replication_group_members;
  3. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  4. | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
  5. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  6. | group_replication_applier | 2d623f55-2111-11e8-9cc3-0025905b06da | node1      |        3306 | ONLINE      |
  7. | group_replication_applier | 859b114c-2e48-11e8-9eac-525400bdd1f2 | node3      |        3306 | RECOVERING  |
  8. | group_replication_applier | f64f9fb6-2da4-11e8-96bd-525400c33752 | node2      |        3306 | ONLINE      |
  9. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  10. 3 rows in set (0.00 sec)
  11. ......
  12. root@localhost : (none) 01:43:23> select * from performance_schema.replication_group_members;
  13. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  14. | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
  15. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  16. | group_replication_applier | 2d623f55-2111-11e8-9cc3-0025905b06da | node1      |        3306 | ONLINE      |
  17. | group_replication_applier | 62392979-2e5c-11e8-a389-525400bdd1f2 | node3      |        3306 | ONLINE      |
  18. | group_replication_applier | f64f9fb6-2da4-11e8-96bd-525400c33752 | node2      |        3306 | ONLINE      |
  19. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  20. 3 rows in set (0.00 sec)
复造代码

PS：假如是快照拷贝的数据，需求删除datadir/auto.cnf文件
3.2. 散群新删节面

3.2.1. 利用备份散规复



  •        无备份时的qps直线图
   
205431mnmxj35g0jmmofxk.jpg
  


  •        有备份时的qps直线图
   
205432js2ry9h3x99yii60.jpg
  

   PS：  
因为正在多线程复造下，利用xtrabackup备份读节面下几率会招致发作锁逝世征象(sysbench 128线程insert操纵百分百重现)，以是正在MGR架构上的备份只能思索正在写节面上备份（备选计划1：正在散群上挂一个主从架构的备库，利用xtrabackup的--safe-slave-backup选项正在减锁前截至SQL线程去制止锁逝世征象。备选计划2：假定三鼓写压力没有下，轮询线程疑息，发明备份线程锁恳求被锁逝世时，自动登录数据库kill失落减锁线程并测验考试从头备份），锁逝世征象以下  
   
205432bkg68gr60v0hkccn.jpg
  
3.2.2. 齐量复造参加散群



  •        参考3.1.2末节
  •        无新节面齐量复造参加散群时的qps直线图
   
205432b3nlcnspnnleeacp.jpg
  


  •        有新节面齐量复造参加散群时的qps直线图
   
205432x3461d3bhu6u3zmc.jpg
  


   PS：  齐量复造新减节面会触收流控，招致机能陡降，封闭流控机能可规复到一般形态，但需求一切节面同时封闭才见效
  1. root@localhost : (none) 06:52:16> set global group_replication_flow_control_mode=DISABLED;
  2. Query OK, 0 rows affected (0.01 sec)
复造代码
3.3. 单节面crash的规复



   做一些须要的查抄以后，测验考试间接以通例方法推起节面，假如不克不及一般推起大概crash节面数据丧失，则经由过程备份停止规复(具体步调参考3.1.3末节)。  
3.4. 大都节面crash的规复


   两种方法（针对最少有一个节面的真例可登岸，且散群不成用的状况）  

  •        假如crash节面可以本天规复(带着crash之前的数据间接推起真例)，则散群能够一般规复到可读写形态(即存活节面规复到>=N/2+1个，且皆准确从头参加到散群中)
  •        假如一切crash节面数据丧失，则没法从头参加散群，此时假如要规复散群，需求正在存活的节面上截至散群复造插件，使其离开散群变成可读写形态，然后再规复其他节面(利用xtrabackup备份存活节面数据做规复)

3.4.1. crash节面数据已丧失且能够本天规复

<ul class="list-paddingleft-2">
散群存活节面数 select * from performance_schema.replication_group_members;+---------------------------+--------------------------------------+-------------+-------------+--------------+| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |+---------------------------+--------------------------------------+-------------+-------------+--------------+| group_replication_applier | 0a1e8349-2e87-11e8-8c9f-525400bdd1f2 | node3      |        3306 | ONLINE      || group_replication_applier | 2d623f55-2111-11e8-9cc3-0025905b06da | node1      |        3306 | UNREACHABLE  || group_replication_applier | 506759a9-2e83-11e8-b454-525400c33752 | node2      |        3306 | UNREACHABLE  |+---------------------------+--------------------------------------+-------------+-------------+--------------+3 rows in set (0.00 sec)# 测验考试读写操纵## 读操纵root@localhost : (none) 10:15:10> use sbtestDatabase changedroot@localhost : sbtest 10:15:52> select * from sbtest1 limit 1;+----+---------+----------------------------------------------------------------------+-------------------------------------------------------------+| id | k      | c                                                                                                                      | pad                                                        |+----+---------+-----------------------------------------------------------------------+-------------------------------------------------------------+|  1 | 2507307 | 68487932199-96439406143-93774651418-41631865787-96406072701-20604855487-25459966574-28203206787-41238978918-19503783441 | 22195207048-70116052123-74140395089-76317954521-98694025897 |+----+---------+------------------------------------------------------------------------+-------------------------------------------------------------+1 row in set (0.01 sec)## 写操纵root@localhost : sbtest 10:25:43> delete from sbtest1 where id=1;  # 写操纵被壅闭！！没有是报错......[/code]

  • 另起一个mysql客户端，登录第三个节面真例中截至组复造插件
  1. [root@localhost ~]# ssh 10.10.30.162 "killall -9 mysqld mysqld_safe 2> /dev/null &";ssh 10.10.30.163 "killall -9 mysqld mysqld_safe &> /dev/null &";
复造代码


  • 第三个节面(存活节面)从头启动组复造插件
  1. # 检察散群成员形态
  2. root@localhost : (none) 10:15:09> select * from performance_schema.replication_group_members;
  3. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  4. | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
  5. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  6. | group_replication_applier | 0a1e8349-2e87-11e8-8c9f-525400bdd1f2 | node3      |        3306 | ONLINE      |
  7. | group_replication_applier | 2d623f55-2111-11e8-9cc3-0025905b06da | node1      |        3306 | UNREACHABLE  |
  8. | group_replication_applier | 506759a9-2e83-11e8-b454-525400c33752 | node2      |        3306 | UNREACHABLE  |
  9. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  10. 3 rows in set (0.00 sec)
  11. # 测验考试读写操纵
  12. ## 读操纵
  13. root@localhost : (none) 10:15:10> use sbtest
  14. Database changed
  15. root@localhost : sbtest 10:15:52> select * from sbtest1 limit 1;
  16. +----+---------+----------------------------------------------------------------------+-------------------------------------------------------------+
  17. | id | k      | c                                                                                                                      | pad                                                        |
  18. +----+---------+-----------------------------------------------------------------------+-------------------------------------------------------------+
  19. |  1 | 2507307 | 68487932199-96439406143-93774651418-41631865787-96406072701-20604855487-25459966574-28203206787-41238978918-19503783441 | 22195207048-70116052123-74140395089-76317954521-98694025897 |
  20. +----+---------+------------------------------------------------------------------------+-------------------------------------------------------------+
  21. 1 row in set (0.01 sec)
  22. ## 写操纵
  23. root@localhost : sbtest 10:25:43> delete from sbtest1 where id=1;  # 写操纵被壅闭！！没有是报错
  24. ......
复造代码


  • 如今，间接推起被强杀的两个节面
  1. # 存活节面截至组复造插件
  2. root@localhost : (none) 11:51:15> stop group_replication;
  3. Query OK, 0 rows affected (1 min 27.08 sec)
  4. root@localhost : sbtest 11:52:10> set global read_only=1;set global super_read_only=1;
  5. Query OK, 0 rows affected (0.00 sec)
  6. Query OK, 0 rows affected (0.00 sec)
  7. # 能够看到已提交事件被回滚
  8. root@localhost : sbtest 11:29:02> delete from sbtest1 where id=1;
  9. ......
  10. ERROR 3101 (HY000): Plugin instructed the server to rollback the current transaction.
复造代码


  • 检察散群形态
  1. root@localhost : (none) 12:30:20> set global group_replication_bootstrap_group=ON;
  2. Query OK, 0 rows affected (0.00 sec)
  3. root@localhost : (none) 12:33:25> start group_replication;
  4. Query OK, 0 rows affected (2.04 sec)
  5. root@localhost : (none) 12:33:29> set global group_replication_bootstrap_group=ON;
  6. Query OK, 0 rows affected (0.00 sec)
  7. root@localhost : sbtest 12:28:31> set global read_only=0;set global super_read_only=0; 
  8. Query OK, 0 rows affected (0.00 sec)
  9. Query OK, 0 rows affected (0.00 sec)
复造代码
PS：MGR中一旦呈现大都节面crash，即便正在datadir中数据已丧失也不克不及间接推起crash节面（散群节面内乱的残留事件酿成的数据抵触能够招致全部散群中一切节面的组复造插件非常截至），需求登录到存活节面先把散群复造插件截至，然后从头启动散群复造插件以后，再推起crash节面
3.4.2. crash节面数据丧失

<ul class="list-paddingleft-2">
散群存活节面数 select * from performance_schema.replication_group_members;+---------------------------+--------------------------------------+-------------+-------------+--------------+| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |+---------------------------+--------------------------------------+-------------+-------------+--------------+| group_replication_applier | 0a1e8349-2e87-11e8-8c9f-525400bdd1f2 | node3      |        3306 | ONLINE      || group_replication_applier | 2d623f55-2111-11e8-9cc3-0025905b06da | node1      |        3306 | UNREACHABLE  || group_replication_applier | 506759a9-2e83-11e8-b454-525400c33752 | node2      |        3306 | UNREACHABLE  |+---------------------------+--------------------------------------+-------------+-------------+--------------+3 rows in set (0.00 sec)# 测验考试读写操纵## 读操纵root@localhost : (none) 10:15:10> use sbtestDatabase changedroot@localhost : sbtest 10:15:52> select * from sbtest1 limit 1;+----+---------+--------------------------------------------------------------------------------------------+-------------------------------------------------------------+| id | k      | c                                                                                                                      | pad                                                        |+----+---------+---------------------------------------------------------------------------------------------+-------------------------------------------------------------+|  1 | 2507307 | 68487932199-96439406143-93774651418-41631865787-96406072701-20604855487-25459966574-28203206787-41238978918-19503783441 | 22195207048-70116052123-74140395089-76317954521-98694025897 |+----+---------+-----------------------------------------------------------------------------------------------+-------------------------------------------------------------+1 row in set (0.01 sec)## 写操纵root@localhost : sbtest 10:25:43> delete from sbtest1 where id=1;  # 写操纵被壅闭！！没有是报错......[/code]

  • 另起一个mysql客户端，登录第三个节面真例中截至组复造插件
  1. mysqld_safe --defaults-file=/etc/my.cnf &
复造代码


  • 第三个节面(存活节面)从头启动组复造插件
  1. # 检察散群成员形态
  2. root@localhost : (none) 10:15:09> select * from performance_schema.replication_group_members;
  3. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  4. | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
  5. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  6. | group_replication_applier | 0a1e8349-2e87-11e8-8c9f-525400bdd1f2 | node3      |        3306 | ONLINE      |
  7. | group_replication_applier | 2d623f55-2111-11e8-9cc3-0025905b06da | node1      |        3306 | UNREACHABLE  |
  8. | group_replication_applier | 506759a9-2e83-11e8-b454-525400c33752 | node2      |        3306 | UNREACHABLE  |
  9. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  10. 3 rows in set (0.00 sec)
  11. # 测验考试读写操纵
  12. ## 读操纵
  13. root@localhost : (none) 10:15:10> use sbtest
  14. Database changed
  15. root@localhost : sbtest 10:15:52> select * from sbtest1 limit 1;
  16. +----+---------+----------------------------------------------------------------------+-------------------------------------------------------------+
  17. | id | k      | c                                                                                                                      | pad                                                        |
  18. +----+---------+-----------------------------------------------------------------------+-------------------------------------------------------------+
  19. |  1 | 2507307 | 68487932199-96439406143-93774651418-41631865787-96406072701-20604855487-25459966574-28203206787-41238978918-19503783441 | 22195207048-70116052123-74140395089-76317954521-98694025897 |
  20. +----+---------+------------------------------------------------------------------------+-------------------------------------------------------------+
  21. 1 row in set (0.01 sec)
  22. ## 写操纵
  23. root@localhost : sbtest 10:25:43> delete from sbtest1 where id=1;  # 写操纵被壅闭！！没有是报错
  24. ......
复造代码


  • 如今，假如数据量没有年夜，则能够正在设置好my.cnf以后间接推起真例，经由过程齐量binlog复造参加散群(具体步调可参考3.1.2末节)，假如数据量较年夜，则利用xtrabackup备份方法规复(具体步调可参考3.1.3末节)
PS：


  • MGR散群大都节面crash以后，剩下的节面能够对中供给读效劳，但不成供给写效劳，那取MGC、PXC差别(那两种散群大都节面crash以后，读写效劳皆不克不及供给)
  • MGR散群大都节面crash以后，剩下的节面假如承受到写恳求，间接壅闭，而没有是报错返回，需求客户端自止断开毗连，且断开毗连以后，正在数据库中对应的事件处于COMMIT形态，不克不及跟从客户端断开而自止回滚，需求野生干涉
  • 截至复造插件的方法使得节面离开散群时，节面当前一切已提交事件会被强迫回滚（MGR组复造插件能够stop xxx;start xxx;的方法重启，以是没有需求像MGC、PXC那样必需重启真例去重启散群，也便没有需求分外的备份操纵了）
3.5. 全部散群crash的规复



  • 两种方法
  • 利用备份规复
  • 利用crash节面的datadir数据卷停止规复
3.5.1. 利用备份规复



  • 具体步调参考3.1.3末节，第一个节面以散群方法启动，其他节面利用备份规复数据以后间接推起
3.5.2. 利用crash节面的datadir数据卷停止规复



  • 利用crash节面的datadir数据卷停止规复需求包管最少有一个crash节面的物理机或kvm可会见(容器情况需求包管最少有一个crash节面对应的node可会见)
  • 上面利用sysbench对随便一个节面减压
  1. [root@localhost ~]# ssh 10.10.30.162 "killall -9 mysqld mysqld_safe 2> /dev/null &";ssh 10.10.30.163 "killall -9 mysqld mysqld_safe &> /dev/null &";
复造代码


  • 同时强杀一切节面的数据库历程(模仿一切节面同时crash)
  1. rm -rf /data/mysqldata1/{undo,innodb_ts,innodb_log,mydata,binlog,relaylog,binlog,slowlog,tmpdir}/*
复造代码


  • 以非散群方法启动一切节面，并检察一切节面的GTID
  1. # 检察散群成员形态
  2. root@localhost : (none) 10:15:09> select * from performance_schema.replication_group_members;
  3. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  4. | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
  5. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  6. | group_replication_applier | 0a1e8349-2e87-11e8-8c9f-525400bdd1f2 | node3      |        3306 | ONLINE      |
  7. | group_replication_applier | 2d623f55-2111-11e8-9cc3-0025905b06da | node1      |        3306 | UNREACHABLE  |
  8. | group_replication_applier | 506759a9-2e83-11e8-b454-525400c33752 | node2      |        3306 | UNREACHABLE  |
  9. +---------------------------+--------------------------------------+-------------+-------------+--------------+
  10. 3 rows in set (0.00 sec)
  11. # 测验考试读写操纵
  12. ## 读操纵
  13. root@localhost : (none) 10:15:10> use sbtest
  14. Database changed
  15. root@localhost : sbtest 10:15:52> select * from sbtest1 limit 1;
  16. +----+---------+--------------------------------------------------------------------------------------------+-------------------------------------------------------------+
  17. | id | k      | c                                                                                                                      | pad                                                        |
  18. +----+---------+---------------------------------------------------------------------------------------------+-------------------------------------------------------------+
  19. |  1 | 2507307 | 68487932199-96439406143-93774651418-41631865787-96406072701-20604855487-25459966574-28203206787-41238978918-19503783441 | 22195207048-70116052123-74140395089-76317954521-98694025897 |
  20. +----+---------+-----------------------------------------------------------------------------------------------+-------------------------------------------------------------+
  21. 1 row in set (0.01 sec)
  22. ## 写操纵
  23. root@localhost : sbtest 10:25:43> delete from sbtest1 where id=1;  # 写操纵被壅闭！！没有是报错
  24. ......
复造代码


  • 从上述疑息中，能够看到第一个节面的GTID最年夜（留意那里次要看散群的UUID对应的GTID，而没有是节面的UUID对应的GTID号），事件号为64879507，上面正在第一个节面中，推起组复造散群，并开放对中供给读写效劳
  1. # 存活节面截至组复造插件
  2. root@localhost : (none) 11:51:15> stop group_replication;
  3. Query OK, 0 rows affected (1 min 27.08 sec)
  4. root@localhost : sbtest 11:52:10> set global read_only=1;set global super_read_only=1;
  5. Query OK, 0 rows affected (0.00 sec)
  6. Query OK, 0 rows affected (0.00 sec)
复造代码


  • 其他节面参加散群，并对中供给读写效劳
  1. root@localhost : (none) 12:30:20> set global group_replication_bootstrap_group=ON;
  2. Query OK, 0 rows affected (0.00 sec)
  3. root@localhost : (none) 12:33:25> start group_replication;
  4. Query OK, 0 rows affected (2.04 sec)
  5. root@localhost : (none) 12:33:29> set global group_replication_bootstrap_group=ON;
  6. Query OK, 0 rows affected (0.00 sec)
  7. root@localhost : sbtest 12:28:31> set global read_only=0;set global super_read_only=0; 
  8. Query OK, 0 rows affected (0.00 sec)
  9. Query OK, 0 rows affected (0.00 sec)
复造代码



写正在最初，小编曾经把本文完好版取波教师上一篇《MariaDB Galera Cluster（MGC/PXC）主要参数、形态解读年夜齐》两本电子书收拾整顿到一同，有爱好的同窗能够扫下圆两维码联络助教获得

   
205432jmcciclnypcggunn.jpg
   
    扫码增加助教   
205432fdgux51wbl91p9ud.jpg
   
  

   END  


   
205433pwm9ha7px9saxxwe.jpg
   
205433tf46lx4xbhpxtklk.jpg
      
      
205433q4i78q461zwo627o.jpg
  
         
205433oc476m24zk2cjdzj.jpg
      
   扫码参加MySQL妙技Q群                （群号：529671799）                            
205433yq6d3w6r3d9g99hd.jpg
            
            
            
                                                                                                                                                  
205433gdkkkhgzkkjjwhbh.jpg
                                                                          戳“浏览本文”理解MGR宏构课                                                                                                                        

免责声明：假如进犯了您的权益，请联络站少，我们会实时删除侵权内乱容，感谢协作！
1、本网站属于个人的非赢利性网站，转载的文章遵循原作者的版权声明，如果原文没有版权声明，按照目前互联网开放的原则，我们将在不通知作者的情况下，转载文章;如果原文明确注明“禁止转载”，我们一定不会转载。如果我们转载的文章不符合作者的版权声明或者作者不想让我们转载您的文章的话，请您发送邮箱：Cdnjson@163.com提供相关证明，我们将积极配合您！
2、本网站转载文章仅为传播更多信息之目的，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证信息的正确性和完整性，且不对因信息的不正确或遗漏导致的任何损失或损害承担责任。
3、任何透过本网站网页而链接及得到的资讯、产品及服务，本网站概不负责，亦不负任何法律责任。
4、本网站所刊发、转载的文章，其版权均归原作者所有，如其他媒体、网站或个人从本网下载使用，请在转载有关文章时务必尊重该文章的著作权，保留本网注明的“稿件来源”，并自负版权等法律责任。
回复 关闭延时

使用道具 举报

万魂之主 LV2
发布了 13 篇主题 · 获得积分 143
 
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于作者
万魂之主 LV2
累计积分 143
发表主题数 13
热门标签
  • Archiver| 手机版| 小黑屋|
Powered by Discuz! X3.4 Copyright © 2001-2020, Tencent Cloud.( 鲁ICP备2023025969号-1 )|Sitemap