开发者学堂课程【PolarDB-X 开源系列课程：第七节：X-Paxos 三副本与高可用（四）】学习笔记与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/1032/detail/15168
第七节：X-Paxos 三副本与高可用（四）
六、实验实操
刚刚的操作其实就是部署 PolarDB-X 集群的内容，没有一步一步讲解。
下面这一步搭建跑到 DBX 进行比较慢，可能要几分钟。
主节点挂了后新选主，新的主节点如何保证 Binlog 能和原主节点一致。
其不需要和原主节点完全一致，新的 leader 只需要保证其节点、数据，拥有这个集群上已经达成共识的最新的数据就行。原来老leader 节点数据可能更多，但老节点的数据肯定没有提交。
MGR 也是基于 pixels 协议来实现的，但功能实现差别还是有点大，MGR 其实它最早的版本实现了多写，也就是说它三个节点，每个节点都可以承接读写服务，所以这个地方它就必须要解决冲突问题。比如说 A 节点它改了一行，B 节点也改了一行，那在这个集群中，这种行集的冲突是要解决的。所以 MGR 的实现是比较复杂的，其实有兴趣可以去用一下社区的 MGR，体验现在是什么情况，例如体验其性能以及稳定性。就在去年的时候，社区放宽了多写的能力，并且也提供了单 leader 模式。让 pictures 实现的时候，到底是 marty 还是 single？但是对于作为 PolarDB-X 的存储集群来讲，其实不需要在多个节点都能够提供多写服务，整个分布数据库的多写是在 CN 层完成的，存储节点用 single leader 模式，其实性能是更好的，工程上也更简洁。工程简洁会使其更稳定。
大家有兴趣可以看一下代码，其实真正在多数等待多数的同步细节方面还是有不少东西的。比如说真的需要做成平等模式的情况下，做到发一条等一条，那么这个性能是不可接受的。实际在真正共同实现的时候，在刚刚 Binlog commit 的那张图里，在 flash 阶段时，其实这个数据以及日志就已经发出去了。只是在 follow 那边缓存起来，这其实是一种类似于 TCP 的流射模式。
目前此集群已经搭建完成，先登录上去看一下是否正常的。
登录成功，创建一个 yasir 用的数据库。其实下面阶段用压缩工具起一个 suspends，然后点击 CN，点击 DN，观察 suspends 的流量情况。
压缩之前，在集群里面观察发现有两个对等 CN。然后这里是一个集群，并且因为这个环境其资源有限，就只建立了一个逻辑 DN。它有三个节点，包括两个正常的数据节点，还有一个 logger 节点。其实杀 CN 和 DN 的过程很简单，现在向大家展示这里部署出来的 DN 集群，或者说 MYSQU 集群，观察一下其基本情况。
首先登录到其中一个节点，登录它的其中一个容器里，登录到它的系统里观察其比普通 MYSQU 多出来的一些协议方面的东西。
在 information_schema 里，多出来的一些系统表是关于 x-paxos 协议的一些东西，这里先关注其中比较关键的几张表。
Global表可以查看当前节点的角色，这张表只有 leader 角色的节点才有数据，如果角色为 Follow 节点会导致表变为空的，所以如果 global 表查出来数据，就说明当前这个节点是 leader。
这个例子可以发现它有两个 Follower：第一个是 follower，第二个 leader是其自己，第三个也是 follower。这里看不到 logger，因为在协议层没有角色，没有应用状态机而已。看 index 是日志里其的标识，一条日志的标识是由二元组来形成的，一个是产生这条日志当时的 leader 的任期编号；另外一个是 index 即索引，也就是position，Index 和任期编号都是递增向上，不会变小的。目前可以观察这两个 follower，其实日志全部都已经发过。因为现在还没有起压力，所以看 apply 的 index 字段，就是在看 follower 的节点，它的 Binlog 应用的如何了？应用哪个位点了？和最新的位点有多少差距？从这个表就能看出来，这是 leader 节点。
这个是leader 节点，另外两个肯定是 follower 节点，到上面查看一下，发现这张表虽然是空的，但是可以看到自己的信息。
这张 local 表可以看自己的信息，就是自己的 SOID，还有当前 leader 的任期，还有 IP 端口，commit以及最新的 index，还有最新应用的 apply index。
这样看 show tables alisql 这几张表，可以用 show create table看每张表是什么含义？大家有兴趣可以自己去看，记录了这个节点的状态，协议信息、节点信息以及健康状况等等，这些都从系统表里可以看到。
现在退出来，演示一下高可用。现在准备起 six months。
Test 已经起来了，接着开始起流量。
这个是 suspends 的客户端。
这是 suspends 的流量。
CN有两个对等的，随便删掉一个。被删掉流量是有下跌的，现在应该已经起来了。刚才 CN 被删了一次现在起来了，其流量又恢复了。
因为只有一个 DN，删除之后它会停止服务，现在恢复了。
刚才看到有一个细节，刚才其流量是恢复了，但是被干掉的 DN 节点，就是有一个副本还没起来，已经有一个 follower 被选为新 DN 去承接流量了，现在两个节点包括被干掉节点也起来了，演示也就是这个情况，下去之后可以自己尝试着一下。
下面再次解答一些问题
原来被干掉的 DN 起来后会重新选主吗？
被干掉的 leader 重新起来之后，会以 follower 的身份加入到集群里面去。因为他被干掉之后，有一个 follower 的被选为 leader 了，然后原 leader 再起来之后，没必要一定要用原来的新 leader 再作为leader。
除非遇到刚才说的选主权重的情况，如果原来被干掉的 leader 权重比较高的话，有更大更高的概率被选为 leader。
Logger 节点其实是没有 MYSQL，其没有数据，只有日志，但是它依然有可能被选为 leader，因为有可能其日志就是集群中最新的。但是其被选为 leader，但是它自己又没有 MUSQL 数据，不能提供服务的。所以当其为 leader 之后，它会把自己的 Binlog 日志同步给另外两个 follower 节点，等其他节点把日志接收完毕后，logger 会把自己的 leader 角色自动放出去。
权重高有更高概率当选 leader。但权重高也不一定要选为leader。因为其实如果在生产场景中，如果真的需要一定的某个节点时，就是要 leader，比如只要其不坏就是 leader，这里其实可以人工干预。人工干预的意思就是，万一其权重没有把它选为 leader 的话，可以在集群里用一条命令，指定某个节点成为 leader，这种指定也并不破坏协议，只是如果有条件，或者它能够当选为新 leader 才能成为 leader。
