PXC集群三节点异常宕机全部挂掉如何寻找引导节点

Posted 2023-04-25

参考技术A 一、在使用PXC集群时经常出现由于异常宕机或者批量关闭后导致集群无法再次启动的问题

这边主要的原因是：

     批量关闭或者异常宕机容易出现mysql集群无法及时的记录主节点的信息到grastate.dat 文件中，

     而正常启动时，我们需要判断grastate.dat这个文件里面的safe_to_bootstrap这个值是否为1而进行引导节点启动，其他节点以非引导节点启动

     异常宕机或者批量关闭容易造成该文件来不及写入，导致三个节点的safe_to_bootstrap这个值都是0，导致无法通过safe_to_bootstrap这个值来判断哪个是引导节点，导致无法启动

此时就需要人工进行判断查找确认哪个作为引导节点启动了

二、先来说一下grastate.dat这个文件里面的内容

参数说明

三、说明一下启动脚本

启动脚本：bin/mysqld --defaults-file=../my.cnf

命令说明

四、为什么要区分引导节点和非引导节点方式启动

1、对于PXC首先要明白一点， 整个集群的数据是以引导节点为准的 ，数据是强一致的

所以说，选择好引导节点很重要，不然容易造成数据丢失的风险

非引导节点启动时，都会和引导节点的数据进行对比， 如果发现数据差异太大，则会采用SST(全量复制)的方式进行数据同步覆盖，此时该节点原有的数据将会丢失

2、 在PXC集群中，任何节点都可以以引导的方式进行启动，这种方式适用于，当集体宕机了，此时之前又存在脑裂的情况下（其三个节点的uuid数据不一致 ），

此时不能贸然启动所有节点，应该单独每个节点的启动，然后对每个节点进行备份数据，全部备份好之后，找出备份最大的那个节点为准（表示该机器数据最全，可以作为主节点），然后其他节点再以非引导的方式启动，加入到集群

如果此时确认数据丢失的话，可以从之前的备份中再恢复回来

如果三个节点的uuid都一样的话，则可根据seqno的值最大的进行以引导模式启动

注：如何查看seqno是多少？

第一种方式：查看grastate.dat这个文件

第二种方式：启动时增加--wsrep-recover参数

对于这个值：92d17807-8a46-11ec-bc31-2b23b2ce51ec:43424

其中：uuid = 92d17807-8a46-11ec-bc31-2b23b2ce51ec

           seqno = 43424

redis集群节点宕机

redis集群是有很多个redis一起工作，那么就需要这个集群不是那么容易挂掉，所以呢，理论上就应该给集群中的每个节点至少一个备用的redis服务。这个备用的redis称为从节点（slave）。

1、集群是如何判断是否有某个节点挂掉

　　首先要说的是，每一个节点都存有这个集群所有主节点以及从节点的信息。它们之间通过互相的ping-pong判断是否节点可以连接上。如果有一半以上的节点去ping一个节点的时候没有回应，集群就认为这个节点宕机了，然后去连接它的备用节点。

 

2、集群进入fail状态的必要条件

A、某个主节点和所有从节点全部挂掉，我们集群就进入faill状态。

B、如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态.

 C、如果集群任意master挂掉,且当前master没有slave.集群进入fail状态

 

3、redis的投票机制

具体原理如下图所示：

　　　　

投票过程是集群中所有master参与,如果半数以上master节点与master节点通信超时(cluster-node-timeout),认为当前master节点挂掉。

    选举的依据依次是：网络连接正常->5秒内回复过INFO命令->10*down-after-milliseconds内与主连接过的->从服务器优先级->复制偏移量->运行id较小的。选出之后通过slaveif no ont将该从服务器升为新主服务器。

    通过slaveof ip port命令让其他从服务器复制该信主服务器。

    最后当旧主重新连接后将其变为新主的从服务器。注意如果客户端与旧主服务器分隔在一起，写入的数据在恢复后由于旧主会复制新主的数据会造成数据丢失。

4、集群中的主从复制
      集群中的每个节点都有1个至N个复制品，其中一个为主节点，其余的为从节点，如果主节点下线了，集群就会把这个主节点的一个从节点设置为新的主节点继续工作，这样集群就不会因为一个主节点的下线而无法正常工作。
注意：
1、如果某一个主节点和他所有的从节点都下线的话，redis集群就会停止工作了。redis集群不保证数据的强一致性，在特定的情况下，redis集群会丢失已经被执行过的写命令。
2、使用异步复制（asynchronous replication）是redis 集群可能会丢失写命令的其中一个原因，有时候由于网络原因，如果网络断开时间太长，redis集群就会启用新的主节点，之前发给主节点的数据就会丢失。