开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2300人左右 1 + 2 + 3 + 4 +5+6） 新人分配到6群,准备建立7 群。*（1 2 3 4 5 均没有空位了，请不要在问了谢谢）
上周和PolarDB又吵起来了，原因主要是任务紧急，责任重大，压力山大，被小皮鞭抽打着，还不怎么顺利，然后就把这气给撒错地方了，在我们和POLARDB核心研发和PolarDB领导的群里，我和一个PolarDB的专业老师，吵起来。后面想想后悔的确不是人家的问题，咱们也不能做和 某咖啡一样撒泼打滚的顾客，虽然PolarDB的老师们不会泼咖啡粉给我，但无端惹怒众人的后果我也是承担不起的。重要的是，我在PolarDB的某些知识上还是不牢固的，虽然翻译了多篇白皮书，但白皮书的年代稍微长了一点，而这次吵的东西可能比较新。
此篇就当是道歉贴，并且上个礼拜也和人家老师在专有群里道歉了，做错事情不怕，怕就是脸皮薄不认错。咱们脸皮厚，做错了道歉，后面不做错就好。
从人性上反思了，从技术上咱们也的反思，到底是那块的知识我记错了。
吵架的主要的原因是，我们上新的一个PolarDB 8.02的版本的从节点从起了，原因不是重点，重点是后面对强一致的部分有了一些错误的理解，认为在强一致下数据从节点在 restart 的期间会导致主库的一些压力或问题。所以这里重新对于这块的知识进行重新学习，并且将一些POLARDB 的小TIPS 在这篇文章里面稍微的写一写，当然是TIPS 也就是小秘密，越少人知道越好。要不专家和凡人的距离又拉近了。
稍微简述一下，PolarDB的主从节点的关系，有点类似于ORACLE RAC，和 SQLSERVER Always on ,或者MYSQL innodb cluster ，PG的 patroni 是完全不一样的，属于shared stroagre 的方式，也就是你再多的 主，从节点它就只有一个存储（存储是一写三安全性不用担心，在担心还有多机房热备），
看上图上图是指的PolarDB怎么一个流程来完成主从同步的，并且可以实现主从的一致性（强一致）。他的主要过程在于通过RDMA2.4G的内存网络，将主节点写数据的信息传递给了从节点，而利用了高速网络和磁盘系统，在从节点获得主节点写信息后会从存储直接将数据拽到从节点上，基于强悍的硬件和PolarDB独有的算法，这一切都可以变成主从节点信息强一致。
通过PolarDB本身的PolarTrans,RW节点上每一个提交的事务都有自己的时间戳，将时间戳和事务的ID写入到REDO LOG里面（这里你可以理解为MYSQL的REDO），然后从节点拿到这些信息进行重放REDO，来完成主从节点的一致。
强一致的完成的主要原则：1 及时在RO节点获取时间戳 2 判断数据是否已经在从节点内存，在直接RO节点允许读取数据，不在重放REDO 3 更细粒度的时间戳，分为全局时间戳，表时间戳，PAGE时间戳 PolarDB 管细粒度写入追踪叫 MTT
这属于三级判断，如果全局时间戳可以满足强一致读取，则返回，如果不行则往下一级表时间戳确认数据一致性，如果还不行就下探到page 时间戳部分。如果都不满足，则才会将读请求进行等待等待RO节点将信息进行重放达到主从一致性。当然代理也可以设置等待时间，如果从节点在规定时间没有数据则直接去主节点读取数据。
以上的信息是没有争论的都是共识，争论的地方在下方
1 从节点在某些原因失败，并被重新拉起来的情况下，在这段情况下我们就只有一个从节点的情况下，读全部去了主节点，主节点会压力过大，导致主节点也 OVER。（因为能摧毁从节点的业务，他也一定能摧毁主节点）
2 从节点在重新被拉起后，会有短暂的数据和主节点不一致的情况，（具体多短不是太清楚），但基于硬件和软件算法的优势，很快就会就会一致。
1 的确主从不一致的问题，持续的时间会很短，主要基于拉起从节点的数据也是从主节点 2 如果有一些需求的确会导致一些数据库系统的不稳定，可以采用多从库的解决方案，将压力进行分散 3 在只有一个读库的情况下，即使在拉起的状态下，1 读库原有的任务会保留在代理中间件中，待从库拉起后，在进行任务重试，拉起期间的任务会走写库。
所以不存在在只有一个从节点的情况下，当从节点挂掉，主节点无法写入数据的情况，即使是强一致的情况。
TIPS，在我们多次包含业务测试与实际使用POLARDB 的情况下，我们发现一个有意思的地方，凡是开启SERVERLESS的POALRDB 更耐艹，即使CPU 100%持续长达6个小时，也不会挂掉，但如果没有SERVERLESS 的POLARDB 在特别过分的使用下，会CRASH 和重启（这与我们了解的其他数据库是一致的），主要的原因这里就不说了，所以我们得到的秘密就是，如果你想你的POALRDB 永远不会DOWN级，在CPU 100% 内存击穿的情况下，你就开启SERVERLESS ，POALRDB 就和穿了一层铠甲，刀枪不入。
神奇！！
与PolarDB 有关的文章
置顶文章：
有思想的人，在这个年代会很痛苦？躺平还是醒着都无所谓了
往期热门文章：
SQL SERVER 2022 针对缓存扫描和Query Store 的进步，可以考虑进行版本升级
MySQL 的SQL引擎很差吗？由一个同学提出问题引出的实验
临时工访谈：从国产数据库 到 普罗大众的产品 ！与在美国创业软件公司老板对话
感谢 老虎刘 刘老师 对 5月20日 SQL 问题纠正贴 ---PostgreSQL 同一种SQL为什么这样写会提升45%性能
PostgreSQL 同一种SQL为什么这样写会提升45%性能 --程序员和DBA思维方式不同决定
PostgreSQL 熊灿灿一句话够学半个月 之 KILL -9
临时工访谈：庙小妖风大-PolarDB 组团镇妖 之 他们是第一 （阿里云组团PK笔者实录）
临时工访谈：金牌 “女” 销售从ORACLE 转到另类国产数据库 到底 为什么？
临时工访谈：无名氏意外到访-- 也祝你好运（管理者PUA DBA现场直播）
