Percona XtraDB Cluster(PXC)掉电无法正常启动

办公室掉电,PXC集群环境无法启动,也就是说整个集群的状态处于丢失的情形。因此需要采取强制的方式来进行,见下面的描述。

一、故障现象

查看mysql错误日志如下:

2017-07-08 09:05:50 3913 [Note] WSREP: GCache history reset: old(0947d0da-4ffe-11e7-b169-137e84a69003:0) ->
new(0947d0da-4ffe-11e7-b169-137e84a69003:112047)
2017-07-08 09:05:50 3913 [Note] WSREP: Assign initial position for certification: 112047, protocol version: -1
2017-07-08 09:05:50 3913 [Note] WSREP: wsrep_sst_grab()
2017-07-08 09:05:50 3913 [Note] WSREP: Start replication
2017-07-08 09:05:50 3913 [Note] WSREP: Setting initial position to 0947d0da-4ffe-11e7-b169-137e84a69003:112047
2017-07-08 09:05:50 3913 [ERROR] WSREP: It may not be safe to bootstrap the cluster from this node. It was not the last one to leave the cluster and may not contain all the updates.
To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .
2017-07-08 09:05:50 3913 [ERROR] WSREP: wsrep::connect(gcomm://192.168.1.248,192.168.1.249,192.168.1.253) failed: 7
2017-07-08 09:05:50 3913 [ERROR] Aborting

2017-07-08 09:05:50 3913 [Note] WSREP: Service disconnected.
2017-07-08 09:05:50 3913 [Note] WSREP: Waiting to close threads......
2017-07-08 09:05:55 3913 [Note] WSREP: Some threads may fail to exit.
2017-07-08 09:05:55 3913 [Note] Binlog end
2017-07-08 09:05:55 3913 [Note] /usr/sbin/mysqld: Shutdown complete

二、故障分析及解决

最好的办法首先就是从日志定位问题的关键。如前所述,
[ERROR] WSREP: It may not be safe to bootstrap the cluster from this node. It was not the last one to leave the cluster and may not contain all the updates.
To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .

无法从当前节点实现安全引导。原因是当前节点不是集群中最后离开的节点,也就是说当前节点可能未能包含所有的更新。
如果强制启动当前节点,需要修改grastate.dat文件将safe_to_bootstrap的值置为1。

咋一看,那就从另外一个节点启动吧。当前的集群仅仅配置了2个节点。遗憾的是另外一个节点也收到了同样的错误。
也就是只能强制启动了。

下面查看grastate.dat,该文件主要描述GALERA保持的状态信息,按指引修改safe_to_bootstrap的值置为1

# more grastate.dat
# GALERA saved state
version: 2.1
uuid:    0947d0da-4ffe-11e7-b169-137e84a69003
seqno:   -1
safe_to_bootstrap: 0

修改safe_to_bootstrap的值为1
# vi grastate.dat 

再次启动正常
# /etc/init.d/mysql bootstrap-pxc

mysql> show variables like 'version';
+---------------+----------------+
| Variable_name | Value          |
+---------------+----------------+
| version       | 5.6.36-82.0-56 |
+---------------+----------------+

mysql> select 'Leshami' Author,'http://blog.csdn.net/leshami' Blog,
    -> '645746311' QQ from dual;
+---------+------------------------------+-----------+
| Author  | Blog                         | QQ        |
+---------+------------------------------+-----------+
| Leshami | http://blog.csdn.net/leshami | 645746311 |
+---------+------------------------------+-----------+

mysql> show global status like 'wsrep_cluster%';
+--------------------------+--------------------------------------+
| Variable_name            | Value                                |
+--------------------------+--------------------------------------+
| wsrep_cluster_conf_id    | 2                                    |
| wsrep_cluster_size       | 2                                    |
| wsrep_cluster_state_uuid | 0947d0da-4ffe-11e7-b169-137e84a69003 |
| wsrep_cluster_status     | Primary                              |
+--------------------------+--------------------------------------+

时间: 2024-10-04 18:01:33

Percona XtraDB Cluster(PXC)掉电无法正常启动的相关文章

快速体验Percona XtraDB Cluster(PXC)

Percona XtraDB Cluster(简称PXC)集群是基于Galera 2.x library,事务型应用下的通用的多主同步复制插件,主要用于解决强一致性问题,使得各个节点之间的数据保持实时同步以及实现多节点同时读写.提高了数据库的可靠性,也可以实现读写分离,是MySQL关系型数据库中大家公认的集群优选方案之一.本文简要介绍其原理并给出安装指导. 一.PXC结构及特性 1.结构及基本描述 群集由节点组成.建议的配置是至少有3个节点,但你可以使它 2节点运行. 每个节点可以是常规MySQ

Percona XtraDB Cluster 5.7.18-29.20 发布

Percona XtraDB Cluster 5.7.17-27.20 发布了,二进制文件可在 下载区 或 软件仓库 中下载.(注意:你也可以从 Docker Hub 仓库中的镜像运行 Docker 容器) Percona XtraDB Cluster 5.7.17-27.20 基于以下这些项目: Percona Server 5.7.18-15 Galera Replication library 3.20 wsrep API version 2 该版本除了上游更改和相关包的修复外,对主要组件

怎么预防固态硬盘掉电数据丢失?

  固态硬盘掉电数据丢失问题是长久以来一直以来困扰着我们的问题,往固态硬盘里面写入数据,首先存储到的并不是不怕掉电的闪存颗粒上,而是固态硬盘上的DDR内存颗粒中,一种易失性的高速缓存,一直要等到缓存写满,才会考虑是否要把内存中的数据移入到闪存当中去.不过大家也别太在意,毕竟这对于固态硬盘的性能提升,实在是太给力了. 固态硬盘 不过随之而来的问题就是,当固态硬盘瞬间掉电之后,高速数据缓存中的数据,可能就会真正的永久丢失了.解决之道也非常简单,那就是在固态硬盘中加入大容量的电容,当固态硬盘掉电之后,

oracle数据库掉电导致系统崩溃的恢复过程

这里简单记录一下,此次国庆加班恢复的某客户的2套Oracle RAC数据库,整个恢复过程中,2套rac差不多,因此这里以其中一套数据库的恢复过程为例进行简单分析说明.数据库由于为非归档,由于掉电导致重启之后系统无法正常open. 在正常open的过程中,报错如下错误: SQL> alter database open; alter database open * ERROR at line 1: ORA-00600: internal error code, arguments: [kcratr

Oracle RAC数据库掉电导致系统崩溃的恢复过程

这里简单记录一下,此次国庆加班恢复的某客户的2套Oracle RAC数据库,整个恢复过程中,2套rac差不多,因此这里以其中一套数据库的恢复过程为例进行简单分析说明.数据库由于为非归档,由于掉电导致重启之后系统无法正常open. 在正常open的过程中,报错如下错误: SQL> alter database open; alter database open * ERROR at line 1: ORA-00600: internal error code, arguments: [kcratr

stm32 PVD掉电检测,进不了中断

问题描述 stm32 PVD掉电检测,进不了中断 芯片是stm32f103C8T6,PVD掉电检测,中断服务函数是通过串口发送数据.可是并没有发送,不知道是没有进入中断,还是进入了中断,但电压值过低,串口发送数据失败.求大神看看,写了好久没解决问题.代码如下: void PVD_Init(void) { SystemInit(); EXTI_InitTypeDef EXTI_InitStructure; RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR,ENAB

嵌入式-at24c里面的东西掉电数据不丢失主要是写保护起作用吗

问题描述 at24c里面的东西掉电数据不丢失主要是写保护起作用吗 我只是网65533地址写入一个u16的数据,掉电重启数据怎么没了呢 解决方案 at24c是EEPROM,如果你不对它重新编程,数据不会丢失. 看看你对它的写入本身有没有问题. 解决方案二: 不是写保护,写的时候直接就存储进去了,就跟你电脑里的磁盘一样,掉电丢失可能是你没有写进去 解决方案三: At24C04 解决方案四: for(i = 218;i <223;i++) //想存储器中写入256个数据 { IIC_write_dat

永不掉电的数据中心 减轻电源路径问题

电源对数据中心的重要性就好比心脏对人类的重要程度,虽然数据中心设计时可以选择不同的级别和冗余水平,但从来没有人希望数据中心掉电.不管是只有单一UPS的小型数据中心,还是具有完全冗余能力的大型数据中心,停电是不可避免的.下面是一些可以减轻电源路径问题的办法. 电源路径:成本vs可接受的风险 数据中心设计通常是由成本和可接受的风险因素推动的,Uptime协会的1-4层要求无需再做解释,它也远远超出了电源话题,但最基本的电源路径是简单的N设计(或1级),即没有冗余,电源路径中的每个组件都是一个单点故障

掉电是数据中心无法抹去的痛

电源对于数据中心的重要性就好比心脏对人类的重要程度,没有电源的持续供电数据中心就无法运转.当数据中心的设备出现自动断电.关机.电源故障等相关不良现象时,统称为掉电故障.掉电给数据中心带来的损失将非常严重,数据中心可能直接会停止运转,所有的应用系统都无法继续运行.比如2016年6月大连电信枢纽机房因市电故障,设备突然闪断,并造成部分线路短路,变压器受损引起跳闸,导致核心设备出现故障.掉电造成大连市区.旅顺地区移动网用户手机通话.短信等功能无法正常使用;2015年11月山西证券就因为数据中心机房掉电