学习POLARDB 已经有3-4个月的时间了，当然大部分还是在理论方面，实际上POLARDB 在实际的操作中，有一部分是我还没有深入，另一部分是POLARDB 的 SERIVCE guy 的服务方式有些太主观，当然有客观的原因，但是作为一个数据库，想拥有FANS ，各种在内部进行展示的系统性能或一些小心思的开关，还是会吸引到 死忠粉的，建议不要冷冰冰的说，这些都是内部XX， 或者说你看 monitor web page 来打发一些想“进步” 的同学，终究我们也是看 MYSQL 的文档，并在里面找 有意思东西的一群人。另外一些服务的同学，你们这样做，真心是在浪费 技术同学的努力创造POLARDB 的好形象。
本篇是POLARDB 的翻译，并学习理论的最后一篇
5 Reliability and failure recovery
在POLARDB SERVERLESS，自身的结构是允许节点可以独立的进行failover, 所以我们有针对每种失败后的恢复的方法，大部分恢复的方法都是针对POLARDB 本身设计的，所有的代理节点都属于无状态的，当代理节点失败了，他能够很容易的被替代，用户可以重新连接其他存活的节点，POLARDB SERVERLESS 会至少保持两个与存储节点的复制，这些都被分布式协议parallel raft 来保证数据的一致性，这里我们保证没有任何单点的服务。
下面我们将关注复杂处理数据库节点recovery 的机制，内存节点机制，和集群恢复等
5.1 DATABASE NODE RECOVERY
PolarDB SERVERLESS 采用了 ARIES-STYLE 恢复逻辑，RW 和 RO 节点都有不同的恢复过程和程序的支持。一个失败的RO节点能够被很容易的替换掉，通过一个新的节点，这个新的节点的信息使用share memory 中的页面。基于节点的失效是有计划的还是突然的，恢复的方式也是不同的。
非计划的节点失败：当写节点是吧，集群的管理CM发现并记录这个时间通过heartbeat 信号，并且初始化一个RO节点来提升成主节点，这里面经历了如下的过程
1 CM 通告所有的存储节点的内存拒绝来自于RW 节点的写请求
2 CM 选择一个RO节点，并且通知他将要被提升
3 这个将要被提升的节点收集最后的LSN 版本信息，通过polarfs的页面chunk，并且获得CHECKPOINT最后一次的最小的LSN号。
4 RW提升的节点读取REDO LOG 的记录，并且持久化信息在POLARFS 日志CHUNK，同时等待这段REDO LOG的 LSN 信息被应用完毕，然后等待这些页面被消化完全写入到页面中。
5 RW 提升的节点会扫描远程内存池，并且清理超过刚才在REDO 中重做后的页面信息，保证页面的一致性。
6 RW提升节点是否从原来失败节点中获得的PL锁
7 RW 提升节点扫描在RW 节点失败这段期间的所有的活跃的事务的页面的页头
8 RW 提升的节点已经准备好接受写的请求，在CM 节点完成提升的工作
9 RW 节点去应用UNDO LOG 要进行回滚的那些uncommited 事务
这里要提及的是在 3-4 中的REDO 的重做的过程不是和MYSQL一样的单机模式，而是并发的在不同的页面中进行进行的，步骤5 中的页面的清理是在远程的内存中，并且清理的页面是版本信息不一致的页面，这里重点是内存页面的信息一定不能低于磁盘中的信息。另一方面RW是可以写脏页到远程的内存中的，并且在REDO LOG 被刷新的POLARFS 之前，所有远程内存页面的信息是有可能高于POLARFS存储中的信息的。
因此这些页面也需要被清理掉，在 3 4 5 操作完毕后，REDO LOG 在POLARFS， 数据页面在POLARFS，以及远程内存中的页面，应该就一致了，数据库就达到了一致性的状态。此时如果没有SMO的工作，那么所有PL锁被释放是安全的（这一段不明白的，看上一篇SMO 解释），同时此时大部分活跃的数据还是在REMOTE MEMORY的内存池中的，这样就避免了CACHE 数据不一致的问题，虽然REDO 重做在单机是一个普通的工作，但是基于POALRDB 的硬件体系，REDO 的工作也将是一个复杂的工作，需要重新的设计和安排。
Planned node down
