给楼上的几位朋友的一点点心得

#   场景：5个宕机的节点宕掉那一瞬间的数据分别为ABCDE 这5个顺序的版本 A是最老的版本 E是最新的版本   第一个节点是根节点

#   实验：启动第一个节点(数据版本为A的节点)

#   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.bat文件,将safe_to_boostrap设置为1

#   启动第二个节点(我加入的那个节点还没启动呢,我不着急启动)  无法与集群建立连接

# PS:五个节点的集群环境均为PXC,第二三四五个节点的加入的节点都是第一个几点

#   启动第N个节点(非开始节点) 与第二个同样

# 现状：所有的节点都宕机了,根节点不是最新节点无法启动,其他节点因为根节点未启动而不能启动,该怎么处理呢？

#   猜想：尝试上面所述的删除grastate.dat文件再重第一个节点开始启动

#   rm -rf /var/lib/docker/volumes/mysql1-v/_data/grastate.dat

#   rm -rf /var/lib/docker/volumes/mysql2-v/_data/grastate.dat

#   rm -rf /var/lib/docker/volumes/mysql3-v/_data/grastate.dat

#   rm -rf /var/lib/docker/volumes/mysql4-v/_data/grastate.dat

#   rm -rf /var/lib/docker/volumes/mysql5-v/_data/grastate.dat

#   启动第一个节点 我们发现启动成功了,但是数据只保留了这个节点宕机时的数据

#   启动第二个节点 数据被同步成了第一个节点的数据

#   启动第N个节点 数据被同步成了第一个节点的数据

# 结论：当所有节点都宕机时,如果最后一个宕机的不是根节点,那么直接删除grastate.dat文件并重启容器的话,数据会丢失,如果最后一个宕机的是根节点,那么数据应该没问题

# 目标：无论最后一个离开集群的节点是否是根节点,我们都希望能够保存最新版的数据并且重启集群

# 方案：个人方案原理如下

确定最后一个宕机的节点并让它成为根节点重启,再运行其他普通节点

# 问题：1.我们应该如何得知最后一个宕机的节点？

# 这个方法应该不少 比如使用haproxy负载均衡页面中的失去连接时间来看  失去连接时间最短的即是最后离开节点的

#   2.我们应该如何指定这个节点从普通节点变为根节点？

# docker好像不支持创建容器后再追加或者修改配置 那么我们可以删除所有卷中的grastate.dat文件,重新创建并运行容器即可

上面的同学说的问题，我也感到很困惑。

按照PXC强一致性的说法，只要存在一个节点无法同步，那么操作就会无法执行，会造成整个集群的瘫痪。

你说的课程我都已经拥有了。不过就强一致性的问题。我有点萌。不是只要一个节点数据同步不进去的话就操作失败。那么down掉一个节点后，即使在其他节点能响应但也保持不了数据的一致性啊。