InnoDB Cluster故障处理手册

一、集群环境检查与恢复

1.1 集群状态检查

1）根据集群内主机名使用任意主机名登录集群
 /data/mysql/mysql3306/mysql-shell/mysql-shell/bin/mysqlsh  --uri root@192.168.56.159:3306

2）查看集群状态
var cluster = dba.getCluster()
cluster.status()

3）状态解读
1.Online 正常在线
2.Offline 完全离线，组复制已关闭
3.Recovering 加回集群正在恢复数据
4.Error 被踢出集群
5.Unreachable 网络不通
6.MISSING 丢失，尝试连接 

4）集群整体状态解读
1.OK 状态正常，3节点集群允许故障1个节点
2.OK_NO_TOLERANCE 不能容忍任何故障，因为3节点集群中已经有一个节点故障了，再故障一个就会失去法定票数，失去 primary
3.NO_QUORUM  集群不能执行写事务，变成只读

1.2 处置操作

1)  异常节点自动重新加入集群
    --清理正常主机上异常节点的集群信息
    [root@docker ~]# /data/mysql/mysql3306/mysql-shell/mysql-shell/bin/mysqlsh  --uri root@192.168.56.159:3306
    var cluster = dba.getCluster()
    cluster.rescan()    
    --rescan命令自查可集群状态,重加
    cluster.rejoinInstance和remove it from the cluster metadata

2）  登录损坏节点，清理集群信息
     var cluster = dba.getCluster()
     dba.dropMetadataSchema()

3）  重新添加损坏节点到集群
     var cluster = dba.getCluster()
     cluster.addInstance("user@hostname/ip:3306")

-- 异常节点手动重新加入集群
1）  登录集群
[root@docker ~]# /data/mysql/mysql3306/mysql-shell/mysql-shell/bin/mysqlsh  --uri root@192.168.56.159:3306

2）刷新集群状态
 var cluster = dba.getCluster()
 cluster.rescan()

3）登录损坏节点mysql，清理集群信息。（异常节点mysql可正常登陆）
1.登录损坏节点单机mysql。
mysql -uuser -p -hx.x.x.x

2.清理原有集群信息.
/sql>stop group_replication;
/sql>reset slave all;
/sql>set global super_read_only=off;
/sql>drop database mysql_innodb_cluster_metadata;

3.重启mysql服务
service mysqld restart


---使用备份恢复数据与集群
1.备份数据在目录/mysqldata/backup/命令如下：
/>xtrabackup --defaults-file=/data/mysql_[port]/etc/my.cnf --prepare --apply-log-only --target-dir=备份所在路径
/>xtrabackup --defaults-file=/data/mysql_[port]/etc/my.cnf --copy-back --target-dir=备份所在路径

2.修改恢复文件属组，启动MySQL服务：
chown mysql:mysql /data/mysql_[port]/dbdata/*
chown mysql:mysql /data/mysql_[port]/log/*
service mysqld start

二 集群环境应急场景

2.1 split-brain! 脑裂

当集群中有部分节点出现UNREACHABLE状态，此时集群无法做出决策，会出现以下局面，此时只剩下一个活跃节点，此节点只能提供查询，无法写入，执行写入操作会hang住。如果无法达成一致，例如剩下的成员无法实现过半数同意的情况，那么就无法形成一致，这会造成脑裂问题

解决方案：将故障节点剔除，重新加入集群

1. 登录到故障节点，运行stop group_replication，关闭组复制关系
SQL > stop group_replication;

2. 登录到primary节点，将故障节点重新加入到集群中
JS > cluster.rejoinInstance(‘clusteruser@hostname\ip:port’)

2.2 集群单个节点error

集群单个节点error

-- 查看三节点集群MySQL的组复制状态，确认故障节点error log的异常输出，如果没有问题，按照以下方案将故障节点重新加入集群。
解决方案1：

1、确定/etc/hosts映射关系是否正确。
2、选择以下两种方案实施。
方案1、重启mgr故障节点，如果问题没有解决，参照上
MySQL >stop group_replication;
MySQL >start group_replication;

方案2、主从数据差异导致从库复制链路断掉，后续通过clone方式修复
MySQL JS > cluster.removeInstance("clusteruser@hostname/ip:port", {force: true})
MySQL JS > cluster.rescan()
MySQL JS > cluster.addInstance("clusteruser@hostname/ip:port")

指定Clone方式添加节点：
MySQL JS > cluster.addInstance("clusteruser@hostname/ip:port",{recoveryMethod:"clone"})

问题三：插入数据报错

The table does not comply with the requirements by an external plugin

解决思路：
MySQL MGR对表操作必须有主键，建议添加。
如何规避：
MySQL MGR对表操作必须有主键，建议MGR集群中所有的表都要加主键。

问题四：内存使用率过高

mysql数据库内存使用率过高问题分析

解决思路：
排查：
top看看输出
cat /proc/meminfo；
查看performance_schema监控；

问题五：删表报错

delete from user;ERROR 3100 (HY000)： Error on observer while running replication hook ‘berfore_commit

解决思路：
报错提示事务过大引起，超过了group_replication_transaction_size_limit的大小，建议将事务减少，分批操作，建议清理表直接使用truncate语句或者delete分配次操作；

如何规避：
建议将delete数据加where条件分批次操作，大事务减少，进行拆分，制定合适的SQL规则。
如果是导数期间存在的大事务，建议使用以下语句进行数据导入：
mysqlsh user@x.x.x.x:port/databasename --ssl-mode=DISABLED --util import-table /tmp/sbtest1.txt --schema=databasename --table=sbtest1 --bytes-per-chunk=2M --threads=2 --maxRate="2M";

问题六：执行DDL/DML后无法加入集群

在多主模式的的MGR集群中。一个节点作为primary节点在MGR集群状态异常，成为非集群成员后，执行了DDL和DML操作，导致无法重新加入到集群的情形

解决方案：
1.将集群的复制功能关闭
Mysql-SQL>stop group_replication

2.使用多出GTID的节点作为primary节点，让其他节点重新加入到集群中
MySQL Shell 命令：
JS> dba.dropMetadataSchema({force:true})
JS> var cluster = dba.createCluster('myCluster')
JS> cluster.addInstance('clusteruser@hostname\ip:port',{recoveryMethod:"clone"})
JS> cluster.addInstance('clusteruser@hostname\ip:port ',{recoveryMethod:"clone"})

3）检查新集群的状态：
JS> cluster.status()

问题七：UUID一致

Cannot add an instance with the same server UUID(xxxxxxxx-xxxxxxx-).Please change the server UUID of the instance to add

解决思路：
uuid一致，需要将datadir目录下的auto.cnf删除，删除后重启即可。
删除后加入集群失败如果报3096错误，可能是由于主机名映射关系(cat /etc/hosts)写错了，需要仔细检查。

如何规避：
建议克隆机器生成数据备库时，提前清理相关文件

问题八：添加成员失败

   添加集群成员失败

解决思路：
由于节点成员的 /etc/hosts没有加入各个主机名和ip地址，导致用host主机名加入集群的时候，无法识别到主机名，添加完ip和主机名,

解决方案：
将需添加节点的ip和主机名写入/etc/hosts

问题九：文件损坏及单节点损坏

当出现磁盘损坏、链路问题或操作系统问题或数据库bug导致磁盘损坏、数据盘出现大量坏块, 导致无法提供应用访问。
当出现磁盘损坏、链路问题或操作系统问题或数据库bug导致磁盘损坏，当前正在使用的日志文件损坏，导致无法提供应用访问。
当出现磁盘损坏、网络问题或操作系统问题或数据库bug出现服务器中断或者关机,单台节点损坏不影响应用正常访问。

1.检查集群
/> cat /etc/hosts
/> mysqlsh --uri user@hostname/ip:3306
/> var cluster = dba.getCluster()
/> cluster.status()


2.应急处置
/> var cluster = dba.getCluster()
/> cluster.rescan()
PS:rescan命令自查可集群状态，如果发现节点异常，告知采取措施。并按照提示执行


3.重建主机
安装一台与损坏节点服务器配置、IP、主机名等信息完全一致的主机。


4.添加重建主机到集群
登录集群。（主节点）
1.集群添加新节点。
/> var cluster = dba.getCluster()
/> cluster.addInstance('user@hostname/ip:3306')

2.输入C使用clone将主机添加到集群。

3.添加成功后重复步骤一检查集群环境。

问题十：集群多数节点损坏

当出现磁盘损坏、网络问题或操作系统问题或数据库bug出现服务器中断或者关机,单台节点损坏不影响应用正常访问。

应急措施：
当集群内多数节点损坏，比如3节点集群损坏了2个节点，会导致集群失去primary，存活节点无法接受写操作，需要尽快恢复 primary 提供服务，然后修复损坏的节点

```bash
1.检查集群
2.使用mysqlsh 登录存活节点，恢复集群
JS > cluster.forceQuorumUsingPartitionOf("clusteruser@ hostname\ip:3306")
3.恢复故障节点
使用备份恢复数据与集群

问题十一：所有节点损坏

1.检查集群
2.应急处置
用备份恢复