此处将为大家介绍关于MySQL集群节点宕机，数据库脑裂！如何排障？的详细内容，并且为您解答有关mysql集群解决方案的相关问题，此外，我们还将为您介绍关于Can''tconnecttolocalMyS

此处将为大家介绍关于MySQL 集群节点宕机，数据库脑裂！如何排障？的详细内容，并且为您解答有关mysql集群解决方案的相关问题，此外，我们还将为您介绍关于Can''t connect to local MySQL server through socket ''/opt/lampp/var/mysql/mysql.sock'' (2)、Can''t connect to local MySQL server through socket ''/var/lib/mysql/mysql.sock''、CentOS yum安装mysql后 Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’、centos7 设置 mysql 自启动的配置文件中 [Service] User=mysql Group=mysql，user 和 group 这边的 mysql 是指的什么？centos 的登录用户名？的有用信息。

• MySQL 集群节点宕机，数据库脑裂！如何排障？（mysql集群解决方案）
• Can''t connect to local MySQL server through socket ''/opt/lampp/var/mysql/mysql.sock'' (2)
• Can''t connect to local MySQL server through socket ''/var/lib/mysql/mysql.sock''
• CentOS yum安装mysql后 Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’
• centos7 设置 mysql 自启动的配置文件中 [Service] User=mysql Group=mysql，user 和 group 这边的 mysql 是指的什么？centos 的登录用户名？

MySQL 集群节点宕机，数据库脑裂！如何排障？（mysql集群解决方案）

王晶，中国移动 DBA，负责 “移动云” 业务系统的数据库集成架构设计、运维、优化等工作；擅长技术领域 MySQL，获 Oracle 颁发的 “MySQL DBA” 官方认证，熟悉 MySQL 复制结构、MHA、cluster 等多种架构及运维优化。

发现故障的时间正值大年初二，在各种铺天盖地的拜年信息和微信红包之中，我发现了手机上的这条告警通知：

PROBLEM:Disaster: Galera cluster has node down。我生产环境的 Galera 集群有一个节点宕机了。

可能有的人不太熟悉 MySQL Galera 集群，下面先介绍一下出故障的集群信息。

PXC：

我们生产上用的是 Percona 的一个 MySQL 分支版本，PerconaXtradb Cluster，简称 PXC，这是一个可以实时同步的 MySQL 集群，基于广播 write set 和事务验证来实现多节点同时 commit，冲突事务回滚的功能。强数据一致性保证。

Galera Replication 原理总结：

1. 事务在本地节点执行时采取乐观策略，成功广播到所有节点后再做冲突检测；

2. 检测出冲突时，本地事务优先被回滚；

3. 每个节点独立、异步执行队列中的 WS；

4. 事务 T 在 A 节点执行成功返回客户端后，其他节点保证 T 一定会被执行，因此有可能存在延迟，即虚拟同步。

Galera 复制的架构图：

Galera flow control：

Galera 是同步复制（虚拟同步）方案，事务在本地节点（客户端提交事务的节点）上提交成功时，其它节点保证执行该事务。在提交事务时，本地节点把事务复制到所有节点，之后各个节点独立异步地进行 certification test、事务插入待执行队列、执行事务。然而，由于不同节点之间执行事务的速度不一样，长时间运行后，慢节点的待执行队列可能会越积越长，最终可能导致事务丢失。

Galera 内部实现了 flow control，作用就是协调各个节点，保证所有节点执行事务的速度大于队列增长速度，从而避免丢失事务。

实现原理很简单。整个 Galera Cluster 中，同时只有一个节点可以广播消息（数据），每个节点都会获得广播消息的机会（获得机会后也可以不广播），当慢节点的待执行队列超过一定长度后，它会广播一个 FC_PAUSE 消息，所以节点收到消息后都会暂缓广播消息，直到该慢节点的待执行队列长度减小到一定长度后，Galera Cluster 数据同步又开始恢复。

搞清楚上面的背景原理之后，继续说明我的排障过程。

问题描述

1 月 29 日早 10 点 08 分接收到 Zabbix 告警信息，生产环境某子系统数据库集群节点 1、2 分别报活跃线程数超阀值，而且不断升高。

从业务侧尝试访问了一下该子系统，发现系统页面一直无法正常查询数据及修改数据。登陆服务器查看 CPU、IO、内存情况均空闲。说明累计的活跃线程过高，已经影响到业务的正常访问了。

问题分析

1、登陆 Zabbix 告警节点 1、2 查看数据库 show global status like ‘Threads_running’情况发现 Threads_running 线程不断增高。

节点 1：

| Threads_running|  100     |

节点 2：

| Threads_running|  110     |

2、继续查看节点 1、2 数据库的 show processlist 的情况，发现存在很多线程停在 wsrep in pre-commit stage 状态 (这意味着很多线程已经在节点发出 commit，但将该 SQL 发送到其他节点是处于独立异步地进行 certification test、事务插入待执行队列的状态）。这里就明了为什么会有活跃线程不断增加了，原来是线程都停留在 wsrep in pre-commit stage 状态。

3、进一步查找为什么会有线程一直停留在 wsrep in pre-commit stage 状态，show global status like ‘% wsrep%’，发现 1、2 节点接受队列并无阻塞，也没有发出流控。

但 wsrep_evs_delayed 报节点 3 的 4567 端口连接延迟。查看节点 1、2 错误日志发现报 “WSREP: (40a252ac, ‘tcp:// 节点 2:4567’) reconnecting to 67f667d2 (tcp:// 节点 3:4567), attempt 0”。查看节点 3 的错误日志与 wsrep_evs_delayed 运行参数则报相反信息，连接节点 1 和节点 2 的 4567 端口延迟。

这里需要解释一下 4567 端口的作用 (wsrep_provider_options 中的 gmcast.listen_addr 项：主要作用是集群内监听组员状态，组员之间的通信 (握手，鉴权，广播，写入集的复制)。

此时，问题原因已经明朗了，因为节点 3 与节点 1、2 的 4567 端口一直连接有延迟，所以在节点 1、2 执行的请求无法及时的复制给节点 3 执行，导致节点 1、2 的活跃线程一直执行不完。

节点 1：

+——————————+————-+

| Variable_name                | Value       |

+——————————+————-+

| wsrep_local_recv_queue       | 0          |

| wsrep_local_recv_queue_avg   | 0.008711    |

| wsrep_flow_control_paused    | 0.000000    |

| wsrep_flow_control_sent      | 0          |

| wsrep_flow_control_recv      | 0          |

| wsrep_evs_delayed             | 节点 3:4567 |

+——————————+————-+

节点 2：

+——————————+————-+

| Variable_name                | Value       |

+——————————+————-+

| wsrep_local_recv_queue       | 0           |

| wsrep_local_recv_queue_avg   | 0.006193    |

| wsrep_flow_control_paused    | 0.000000    |

| wsrep_flow_control_sent      | 0           |

| wsrep_flow_control_recv      | 0          |

| wsrep_evs_delayed             | 节点 3:4567 |

+——————————+————-+

4、因查询数据库状态除 wsrep_evs_delayed 报连接延迟，其他并无异常现象，初步怀疑是网络原因造成，排查网络后，发现是因核心交换机与接入交换机之间的光模块损坏导致丢包，所以影响部分数据库集群之间的通信，才会出现以上问题。

在网络修复期间，因数据库集群节点 3 延迟丢包严重，被数据库集群仲裁后踢出了集群，剩余的节点 1 和节点 2 在运行了大约半小时后也因延迟丢包严重，出现了脑裂现象。

这时紧急将数据库集群 3 个节点关闭，然后在每个节点执行 mysqld_safe –wsrep-recover 命令找出最新事务号节点作为主节点启动，并在故障期间保持单节点运行。待网络故障消除后，逐一启动节点 2、3，系统数据库集群恢复正常。

问题回顾

1、 在 PXC 环境中，如果集群各个节点的通信端口 (4567) 因为网络的原因出现异常（因为集群节点间通信采用的是同一网段，因此是共性的原因），应及时采取相应措施防止脑裂情况出现。例如上面故障中，因网络原因导致集群节点数从 3 个变为 2 个，这时就应该及时地关闭剩余 2 个节点中的一个节点，让业务只跑在单节点上，还能避免出现脑裂的情况。至少业务不会因此终断。

否则剩余的两个节点很快也会被网络丢包拖垮，会导致整个集群都停止服务，影响业务。当然在非多主的集群中也可以通过设置 “SET GLOBAL wsrep_provider_options=’pc.ignore_sb=true’;” 来取消集群判断脑裂的情况 (多主环境中不建议使用)。

2、可以将 wsrep_evs_delayed 作为一个监控项进行监控，并结合网络监控进行适当的告警

Can''t connect to local MySQL server through socket ''/opt/lampp/var/mysql/mysql.sock'' (2)

ERROR 2002 (HY000): Can''t connect to local MySQL server through socket ''/opt/lampp/var/mysql/mysql.sock'' (2)

原因：系统盘满了

[root@localhost opt]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root
18G 17G 0 100% /
tmpfs 504M 0 504M 0% /dev/shm
/dev/sda1 477M 80M 372M 18% /boot
[root@localhost opt]#

解决：

删除大文件后，重启系统解决

[root@localhost mysql]# /opt/lampp/lampp status
Version: XAMPP for Linux 1.8.3-3
Apache is not running.
MySQL is not running.
ProFTPD is running.

df: 未处理文件系统
[root@localhost opt]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root
18G 17G 0 100% /
tmpfs 504M 0 504M 0% /dev/shm
/dev/sda1 477M 80M 372M 18% /boot
[root@localhost opt]#

[root@localhost ~]# /opt/lampp/lampp status
Version: XAMPP for Linux 1.8.3-3
Apache is not running.
MySQL is running.
ProFTPD is running.

转

Can''t connect to local MySQL server through socket ''/var/lib/mysql/mysql.sock''

MySQL已经被我移到数据盘了，本地连接数据库会报错：Can''t connect to local MySQL server through socket ''/var/lib/mysql/mysql.sock''

但是远程是可以连接的，my.cnf设置mysql的根目录也改成了数据盘的地址，还要在加上client的参数，设置如下：

[client]
socket = /home/data/mysql/mysql.sock

之后重启下mysql就可以了

CentOS yum安装mysql后 Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’

centos7 设置 mysql 自启动的配置文件中 [Service] User=mysql Group=mysql，user 和 group 这边的 mysql 是指的什么？centos 的登录用户名？

centos7 设置 mysql 自启动的配置文件中

[Unit]
Description=MySQL Server
Documentation=man:mysqld(8)
Documentation=http://dev.mysql.com/doc/refman/en/using-systemd.html
After=network.target
After=syslog.target

[Install]
WantedBy=multi-user.target

[Service]
User=mysql
Group=mysql
ExecStart=/usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf
LimitNOFILE = 5000
#Restart=on-failure
#RestartPreventExitStatus=1
#PrivateTmp=false

这里的

[Service]

User=mysql

Group=mysql，

user 和 group 这边的 mysql 是指的什么？centos 的登录用户名？还是其他呢？

关于MySQL 集群节点宕机，数据库脑裂！如何排障？和mysql集群解决方案的问题我们已经讲解完毕，感谢您的阅读，如果还想了解更多关于Can''t connect to local MySQL server through socket ''/opt/lampp/var/mysql/mysql.sock'' (2)、Can''t connect to local MySQL server through socket ''/var/lib/mysql/mysql.sock''、CentOS yum安装mysql后 Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’、centos7 设置 mysql 自启动的配置文件中 [Service] User=mysql Group=mysql，user 和 group 这边的 mysql 是指的什么？centos 的登录用户名？等相关内容，可以在本站寻找。