172.31.217.182 bd-dev-mingshuo-182
172.31.217.183 bd-dev-mingshuo-183
172.31.217.89 bd-dev-vertica-89
正常关闭
183
一个节点
mysqladmin -uroot -poracle -S /u01/mysql/3307/data/mysql.sock -P3307 shutdown
关闭节点
log
：
|
|
正常节点
log
|
|
182
节点插入数据
|
|
启动
183
节点
|
|
增量数据已经同步过来了。
下面是日志增量应用部分，可以看到收到了一个事务。
|
|
现在测试直接非正常关闭两个节点
将
182
和
183
两个节点进程直接
kill -9
杀掉
89
存活节点：
|
|
存活节点已经无法正常提供读写服务。
|
|
可以看到
wsrep_cluster_size=1
代表集群节点个数只剩自己了。
wsrep_cluster_status=non-Primary
代表集群状态不一致
wsrep_connected=ON
代表数据库还接受连接
wsrep_read=OFF
代表数据库已经不能正常接受查询服务了。上面的
select
语句也佐证了这一点。
存活节点能否提供读服务，取决于
wsrep_dirty_reads
参数
|
|
wsrep_dirty_reads
是可以动态调整的。如果设置为
ON
，那么在节点状态是
non-Primary
时，
是可以提供读的服务的。写的服务还需要提升该节点为
primary
，这个是要通过其他参数设定的，
后面会说的。
存活节点一直在尝试连接另外两个节点
|
|
不能提供读写的原因其实就是
PXC
对集群脑裂的判断机制还不完善，对我自己来说我是
kill
掉了两个节点的进程。
但是对
PXC
来说，存活节点不知道另外两个节点的状态，有可能另外两个节点已经死掉了，有可能另外两个节点相互之间还能继续通信对外提供服务，
这样一来就形成了两个信息孤岛，彼此之间不能联系对方，所以存活节点就变成了这样不能读写的状态。
拉起两个节点后存活节点日志
|
|
出现脑裂后解决方法：
|
|
三个节点正常关闭
依次关闭
183,182,89
三个节点
启动的之前，一定要看一下
grastate.dat
文件内容
183
节点
|
|
182
节点
|
|
89
节点
|
|
注意：
safe_to_bootstrap=1
的节点，说明这个节点是可以安全的作为主节点启动的。所以启动的时候必须先启动
89
节点。
mysqld_safe –defaults-file=/etc/my.cnf –wsrep-new-cluster &
mysqld_safe –defaults-file=/etc/my3307.cnf &
mysqld_safe –defaults-file=/etc/my3307.cnf &
疑问：
mysql PXC
在启动时是不是只是按照
grastate.dat
的
safe_to_bootstrap
来验证集群呢？
这个很好证明，还是按照上面的做法关闭集群，然后修改
183
的
grastate.dat
的
safe_to_bootstrap
值为
1.
实验过程省略，但是这样做确实是可以启动集群的。
如果在关闭部分节点后有数据变化呢？
关闭
183,182
节点后，在
89
节点插入数据
|
|
然后关闭
89
节点。至此集群全部关闭。
修改
183
的节点的
grastate.dat
|
|
启动集群，先启动
183
节点：
|
|
16
那行数据丢失了。
再去启动
89
节点，看看丢失的数据能否找回来
|
|
89
节点的日志序列已经到了
52
，超过了其他节点的
51.
修改
89
节点日志序列为
51
，然后再尝试启动
89
节点
|
|
但是
183
节点的数据还是
15
条。
183
节点删除一条数据
|
|
两个存活节点都删除了
11
这条数据。
启动
182
节点，可以正常启动，启动后检查数据，数据与
183
一致，推测数据的
donor
节点被选择成了
183
|
|
日志中可以看到，
182
节点被选择成为
IST receiver
，监听端口
4568
端口。选择
183
节点作为
数据的
donor
。那么数据与
183
一致也就不足为奇了。
此时数据出现了不一致，如何解决呢？
可以删除节点数据目录下文件，然后按照启动，通过
SST
全量恢复数据。
Pxc
启动时可以人为选择数据的
doner
节点。
wsrep_sst_donor
参数
关闭两个节点，加
wsrep_sst_donor
参数重新启动
|
|
