What's your worst habit ? Some times , the worst habit is procrastination, the best habit I always always come through and get job done.
已经写到系列的6 ，实际上到目前为止我们才刚刚进入到patroni的实际操作，如同上面的话，我最大的坏习惯可能是有时会有拖延症，反过来我的好习惯是有始有终。
首先我们先启动已经安装好的patroni的系统三台机器
192.168.198.66
192.168.198.67
192.168.198.68
etcd 和 patroni 以及postgresql ，写一个简单的判断的展示的shell ，如果有关闭的和不正常的情况下，会有提示
1 当postgresql leader 主机的etcd DOWN掉会怎么样
1 patroni 会反应到当前的ETCD leader 已经down掉，报错尝试在192.168.198.66 上去写数据，但是无法写入，报错信息在上边，后续会很快的开始raft协议，进行ETCD本身的切换，将ETCD的写节点切换到 192.168.198.68 上
结果一个任意节点的ETCD DOWN 掉不会影响POSTGRESQL 高可用的稳定性。
2 停止掉2个ETCD 一定是不行的，这和RAFT协议中的大多数原理有关我们验证一下
当只剩一个etcd的情况下，patroni 无法通过etcd来判断哪个是当前运作的主库，并且也无法在系统出现问题的情况下进行任何的切换，所以ETCD 必须是多节点，必须是3个节点及以上的基数节点。
再次重新启动2个ETCD ，系统恢复正常。
3 停止patroni 在主节点的服务。
首先我们找到当前的主节点，当然也可以用patroni的命令，这里没有使用
当我们定位到集群中的主节点后，我们停止这个主节点的patroni的服务
在停止主节点的patroni的服务的一刻， 系统开始进行了切换，马上选出了新的主节点，并将主节点转移到了另一个standby节点，后续另一个从节点也更改了复制的节点，连接到了新的节点上。
4 停止两个patroni 的服务
整个的系统出现问题，剩下的一个正常工作的patroni 系统报下图的信息
其他两个节点在重新启动了patroni后，也报类似的错误，整个集群的复制被终止，
同时发现两个关闭partoni的数据库已经进入了 single 模式
并且可以确认的是，正常的复制已经不存在，需要重新做相关的复制并重新启动整体的服务
5 停止postgresql 主库数据库服务
在停止主库的第一时间，其他两个从库均开始有反应，与主库无法相连，并开始报告相关的信息，而在关闭postgresql 主库的服务后，马上patroni将PG主库的服务又来了，短暂的时间其他服务器判断后，恢复了和主库的连接。
所以人为的关闭主服务器数据库服务，是不会对集群产生巨大的影响的
6 关闭主数据库服务器
这次是整体关闭服务器的主机
在关闭主数据库服务器后， 其中一台从库被选举为主库，同时另一台服务器连接到这台主库。
当再次将已经关闭的数据库服务器主机启动后，
系统开始尝试进行pg_rewind 操作，恢复数据库，并且在恢复后，开始讲这个数据库和新的主库进行重新复制关系的建立
经过上述的几个尝试，我们做了如下操作
1 ETCD DOWN 掉后 1 个后，不会出现任何问题， DOWN掉2个后，不在符合RAFT 协议，则系统集群的故障处理不能正常， 在启动ETCD后，整体系统恢复，在此期间，数据库服务不会受到影响
2 停止patroni 服务，在主节点的服务后，故障转换开始，所以patroni的服务的启动时必须的，要保证其服务运行，否则主节的patroni 无法工作就会进行故障切换，当停止两个patroni 的服务，整体集群出现故障，无法在进行工作，数据库进入单用户模式。
3 停止主数据库服务，patroni 会自动将数据库服务拉起来，如果直接停止主服务的服务器，则进行切换，在主服务器启动后，启动数据库服务，ETCD，patroni 后， 开始对失效的patroni 的曾经的主库进行 pg_rewind 并且将这个节点再次加入到集群，作为从库。
整体来说,patroni 作为分布式协议方式的postgresql的高可用方式，的确是靠谱的。
当然这还远远没有结束，我们还需要对原理， 以及一些更深入的操作进行研究和理解
