pxc的问题故障:
1.3节点,其中两个已经正常起来并且运行,第3个节点启动报错,如下:
关键词:WSREP: failed to open gcomm backend connection: 131: invalid UUID
进入该数据库节点/var/lib/mysql/目录,将文件gvwstate.dat移除(mv)掉。然后重新启动mairbd即可
2.关键词:bind: Address already in use
查看mysql进程:ps -ef | grep mysql,然后杀死该进程,在启动mariadb
3.关键词:It may not be safe to bootstrap the cluster from this node
数据库集群宕机,在运行./mysqld_safe --defaults-file=mysql3306.cnf --wsrep-new-cluster &
如果报错都相同,则需要从3个节点中选取一个主节点,修改/var/lib/mysql/grastate.dat,把其中safe_to_bootstrap的值改为1即可。然后运行/bin/galera_new_cluster。其他节点依次启动
4.no-primary
Recovering a Non-Primary cluster
(或者在一些事故一些其他的节点离开)这个失败的节点会引起其他的编委non-primary 状态,
用如下命令可以恢复节点从non-primary状态:
SET GLOBAL wsrep_provider_options='pc.bootstrap=true';
4.脑裂问题:
在PXC环境中,如果集群各个节点的通信端口(4567)因为网络的原因出现异常(因为集群节点间通信采用的是同一网段,因此是共性的原因),应及时采取相应措施防止脑裂情况出现。例如上面故障中,因网络原因导致集群节点数从3个变为2个,这时就应该及时地关闭剩余2个节点中的一个节点,让业务只跑在单节点上,还能避免出现脑裂的情况。至少业务不会因此终断。
否则剩余的两个节点很快也会被网络丢包拖垮,会导致整个集群都停止服务,影响业务。当然在非多主的集群中也可以通过设置“SET GLOBAL wsrep_provider_options=’pc.ignore_sb=true’;”来取消集群判断脑裂的情况(多主环境中不建议使用)。
5.死锁问题
由于集群是基于乐观的并发控制(optimistic consurrency control),事务冲突的情况可能哎commit阶段发生,当多个节点修改同一行数据的时候,只有一个节点能够成功,失败的节点将终止,并且返回死锁错误码 Error:1213 SQLSTATE:4001(ER_LOCK_DEADLOCK).(这样是否太不稳定了?动不动就会有某个节点终止刮掉的情况?而且这种情况如何处理?)
ps:由于个人能力有限,这些内容都是从网上查找到的,然后总结出来的。可能会存在不对的地方。
1.3节点,其中两个已经正常起来并且运行,第3个节点启动报错,如下:
关键词:WSREP: failed to open gcomm backend connection: 131: invalid UUID
进入该数据库节点/var/lib/mysql/目录,将文件gvwstate.dat移除(mv)掉。然后重新启动mairbd即可
2.关键词:bind: Address already in use
查看mysql进程:ps -ef | grep mysql,然后杀死该进程,在启动mariadb
3.关键词:It may not be safe to bootstrap the cluster from this node
数据库集群宕机,在运行./mysqld_safe --defaults-file=mysql3306.cnf --wsrep-new-cluster &
启动第一个节点时报错,意思是该节点不是最后一个停掉的,不能安全启动;
然后可以尝试在其他节点运行该命令;
如果报错都相同,则需要从3个节点中选取一个主节点,修改/var/lib/mysql/grastate.dat,把其中safe_to_bootstrap的值改为1即可。然后运行/bin/galera_new_cluster。其他节点依次启动
4.no-primary
Recovering a Non-Primary cluster
(或者在一些事故一些其他的节点离开)这个失败的节点会引起其他的编委non-primary 状态,
用如下命令可以恢复节点从non-primary状态:
SET GLOBAL wsrep_provider_options='pc.bootstrap=true';
4.脑裂问题:
在PXC环境中,如果集群各个节点的通信端口(4567)因为网络的原因出现异常(因为集群节点间通信采用的是同一网段,因此是共性的原因),应及时采取相应措施防止脑裂情况出现。例如上面故障中,因网络原因导致集群节点数从3个变为2个,这时就应该及时地关闭剩余2个节点中的一个节点,让业务只跑在单节点上,还能避免出现脑裂的情况。至少业务不会因此终断。
否则剩余的两个节点很快也会被网络丢包拖垮,会导致整个集群都停止服务,影响业务。当然在非多主的集群中也可以通过设置“SET GLOBAL wsrep_provider_options=’pc.ignore_sb=true’;”来取消集群判断脑裂的情况(多主环境中不建议使用)。
5.死锁问题
由于集群是基于乐观的并发控制(optimistic consurrency control),事务冲突的情况可能哎commit阶段发生,当多个节点修改同一行数据的时候,只有一个节点能够成功,失败的节点将终止,并且返回死锁错误码 Error:1213 SQLSTATE:4001(ER_LOCK_DEADLOCK).(这样是否太不稳定了?动不动就会有某个节点终止刮掉的情况?而且这种情况如何处理?)
ps:由于个人能力有限,这些内容都是从网上查找到的,然后总结出来的。可能会存在不对的地方。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/30162734/viewspace-2157244/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/30162734/viewspace-2157244/