怎样解决mysql 集群问题集

误1、[MgmtSrvr] WARNING -- 1011 Unable to connect with connect string: nodeid=0,localhost:1186

处理：一般这个情况是系统ping 127.0.0.1不通，可能是网卡问题，但是ping在eth0和eth1上配置的IP地址却通，所以处理方法是在/etc/hosts文件中添加：

192.168.1.5 localhost

即可。192.168.1.5根据自己配置的IP地址进行修改。

错误2、在修改了数据节点目录后，数据节点遇到如下错误：[ndbd] ERROR-- Couldn't start as daemon, error: 'Failed to lock pidfile '/opt/mysql_cluster/ndb_data/ndb_11.pid', errno: 37'

处理：由于数据节点的目录是挂载在nas存储上面，由于防火墙问题导致nas挂载异常，以致出现以上错误，关闭防火墙，重新挂载nas存储即可。

错误3、在修改了数据节点目录后，mysql节点遇到如下警告：[Warning] NDB : Tables not available after 15 seconds. Consider increasing --ndb-wait-setup value，导致管理节点识别不到mysql节点

处理：经检查，是配置文件my.cnf里ndb-connectstring参数的配置有误，改成正确的管理节点IP地址即可。

Warning: World-writable config file '/etc/my.cnf' is ignored

Unable to connect with connect string: nodeid=0,localhost:1186

Retrying every 5 seconds. Attempts left: 12 11 10 9 8 7 6 5 4 3 2 1, failed.

2011-06-08 23:31:35 [ndbd] ERROR-- Could not connect to management server, error: ''

解决办法 chmod 644 /etc/my.cnf

2020-08-14

集群有三个成员memberA、B、C成，其中memberB意外故障停掉了，然后memberA 执行stop group_replication退去集群.此时整个集群不可用了（不能更新数据）。

集群中唯一剩余的成员memberC上看到的成员状态为：

但是memberA看到的状态为：

查看最后的存活的memberC的错误日志发现：

"Plugin group_replication reported: 'This server is not able to reach a majority of members in the group. This server will now block all updates. The server will remain blocked until contact with the majority is restored. It is possible to use group_replication_force_members to force a new group membership.' "

大概意思是当前的服务没法获取到成员的投票数，当前服务将会阻塞所有的更新，直到能够获取到投票数。可以使用group_replication_force_members 来强制组成一个新的组。

开始认为这是MGR功能的一个bug，不过后来想想这样的设定也是合理的，因为如果是当前的服务成员自身网络或其他问题导致的无法与其他成员的通信成功，那么这样的情况下这种设定也是合理的，因为不能让它自动重新组成一个组，否则就会可能出现多个重复的组。对于为什么组成员A执行stop group_replication后，剩余的memberC的视图中memberA还是online状态，可能是因为memberB已经unreachable,所以memberC去请求是否同意memberA退去时没有得到结果，一直阻塞等待造成的。此时，memberA的退出结果应该是无法多数投票通过的，因此memberA的退出结果应该是失败的。查看memberA的error日志，结果确实如此：

解决的方法是memberC也执行stop group_replication停掉这个组，再重新组成一个新的组。

此时memberA再重新加入就成功了：

结果：

以此类推，当有多个server组成的group而有多数成员已经意外故障时，导致整个组的停止更新，目前想到的解决的方法就是停掉现在的组，重新组成新的组。

ps:

增加Group Replication System Variables中group_replication_member_expel_timeout的大小，可以避免网络问题或执行事务慢造成的错误驱逐。

【背景】

对一套数据库集群进行5.5升级到5.6之后,alter.log

报warning异常。

复制代码

代码如下:

2015-02-03

15:44:51

19633

[Warning]

Storing

MySQL

user

name

or

password

information

in

the

master

info

repository

is

not

secure

and

is

therefore

not

recommended.

Please

consider

using

the

USER

and

PASSWORD

connection

options

for

START

SLAVE

see

the

\'START

SLAVE

Syntax\'

in

the

MySQL

Manual

for

more

information.

数据库业务压力

qps

1

tps

几乎为0

4-10

秒或者更久会有写入 *** 作。

【分析】

1

主从复制信息

主机地址，端口，复制用户，binlog

文件位置等信息是存储在master.info中的，

5.6

版本在安全性上做了很多改善，不建议在执行change

master的时候指定密码。如果在搭建主从时制定密码，5.6

MySQL

会提示上述warning信息。这也是该集群在5.5版本时不报错的原因。

2

MySQL

Replication的重连机制

在一个已经建立主从复制关系的系统里面,正常情况下,由从库向主库发送一个

COM_BINLOG_DUMP

命令后,主库有新的binlog

event，会向备库发送binlog。但是由于网络故障或者其他原因导致主库与从库的连接断开或者主库长时间没有向从库发送binlog。例如该例子中数据库集群

10s

左右还没有写入的情况，超过slave_net_timeout设置的4s

，从库会向主库发起重连请求。5.6

版本slave

发起重连请求时，MySQL都会判断有没有用明文的用户名密码,如果有则发出上述信息到error.log。

【解决方法】

在本案例中可以尝试将slave_net_timeout

调整大一些

设置为25

。slave_net_timeout是设置在多少秒没收到主库传来的Binary

Logs

events之后,从库认为网络超时,Slave

IO线程会重新连接主库。该参数的默认值是3600s

，然而时间太久会造成数据库延迟或者主备库直接的链接异常不能及时发现。将

slave_net_timeout

设得很短会造成

Master

没有数据更新时频繁重连。一般线上设置为5s

。

复制代码

代码如下:

set

global

slave_net_timeout

=

25

当然也可以和业务方沟通，对于几乎没有访问量的业务线进行下线

，为公司节省资源。

---