在使用POLARDB for MySQL 逐步往深层次使用的情况下 ，最近又发现了问题，最终问题解决了，让我对于POLARDB 在多种复杂环境下的安全和稳定度有了更深的了解。
事情是这样的，月初开发在添加数据库字段的时候，直接报错
错误的信息为如下的信息，提示我们要开启PolarDB中的参数 set polar_support_mdl_sync_preemptinotallow=on,这个参数。
这下我也有点傻眼了，我们已然有了不到3年的POLARDB for MySQL的使用经验各种功能已经使用了一遍 IMCI, Serverless，之前上百套加字段没有发生过问题，这次不行了，后面我从下面直接连接到POALRDB系统内尝试语句直接添加，发现也不行加不上去。随后开了服务和服务的小哥联系，把错误信息给他，问这个参数什么意思。然后给我一个网页。
对于PolarDB 本身之前也是翻译他们的各种白皮书，也做过很多次POC, PolarDB 的原理还是懂一些的，PolarDB MySQL版采用共享存储的架构，用户在执行DDL操作时，是先要判断是否可以加锁，基于主从复制是采用REDO LOG 内存通道复制，在从存储提取数据到从节点的内存重放进行数据的同步，但若此时只读节点的表上存在访问要进行DDL的表正在进行大事务长时间的对表的霸占那么，MDL锁同步线程便会被阻塞是加不上锁的，也就是事前判断直接拒绝加锁。这个抢注的模式为，提高在进行DDL时从库出现大事务长期霸占表时进行主动的等待机会，只要在等待周期可以获得到锁，就可以进行DDL的操作，如果在超过抢注时间外，只读节点依然会无法获得MDL-X锁，客户端则会返回错误ERROR 8007 (HY000): Fail to get MDL on replica during DDL synchronize。相关关于抢注问题的参数的描述在下方的连接中。
说到这里可能有些人已经不是很明晰这个问题，你不是之前3年用这个数据库上百套没出现这个问题，怎么现在出现这个加个字段还要调整参数的问题，what's wrong with PolarDB for MySQL ? 其实我作为PolarDB for MySQL的推动者，我非常明晰我为什么会遇到这个问题
1 原先使用POALRDB 的应用是OLTP，并且在使用前有严格的分库分表（业务逻辑），在操作上的语句都是尽量使用主键查询，或类主键的查询方式，当然也有一些“不好”的语句，但我们一直都在尽力的优化和降低SQL本身的问题，这样使用方式下即使使用MYSQL也很少发生问题，更不用提POLARDB 上产生问题了，当然我非常明晰为什么要用PolarDB 替换MySQL, 之前的那些文章都说的很明白了，因为MySQL传统数据库在云上没有半毛钱的便宜可以占，无论是技术的先进性，还是成本上的节省，在或者是数据库架构的灵活多变和可操作性，PolarDB for MySQL 对比 MySQL 属于对MySQL毁灭性打击。
2 现在使用的应用是OLAP + OLTP 混用的方式，语句写的那叫一个“漂亮”，有多漂亮你就想“如花”有多漂亮，这个语句就有多漂亮，这是历史遗留问题，就是因为MySQL hold不住才用PolarDB for mysql 解决问题。
3 之前的PolarDB 没有加载Serverless 这次的数据库系统加载了serverless 原因见下帖
PolarDB serverless 真敢搞，你出圈了你知道吗!!!!
这次整体的使用环境和对PolarDB的期望与之前是非常不一样，之前对于PolarDB 替换MySQL属于没有任何担心，这次不一样是MySQL不行才用PolarDB 去顶包解决硬骨头，整体的状态十分的不同，这太多人都盯着看这次的硬骨头到底PolarDB 是能挺过去，还是噶了与MySQL一样的结果，所以我整个人的压力也非常大，因为我当时说PolarDB 这好那好可以解决问题，MySQL和PolarDB比就一堆代码小垃圾。
为什么PolarDB 能解决MySQL 没戏的原因，估计看这篇文章99%的人都还是不知道为什么，稍微普及一下
PolarDB for MySQL
1 不是分布式数据库，如果非要说是分布式，也是存储物理分布式，上层就是一个shared storage的结构，也就是一个存储，上面都是内存式的节点。添加从节点非常快最快1分钟左右就加一个从库，最慢7-9分钟一个。（500G-800G的数据量）
2 开启了serverless 主从节点就相当于启动了强制主从一致，主和从节点数据在时间的角度上，是一致的。
3 只要CPU够，PolarDB 会启动自己的并行查询解决大SQL查询性能的问题，对比MySQL后续并行功能假惺惺的扭捏，PolarDB 的并行是真的，并且查询的时候是真给你并行。
4 IMCI 列式存储，Archive 压缩规定，硬件数据压缩大法，直接将数据库的可以解决问题的范围拉满，管你是OLAP，数据冷热分离，还是存储成本压缩，统统一库解决。
这次主要要解决的问题就是查询的语句太漂亮的事情，因为语句实在是太漂亮了，ORACLE 这样数据库见了这样的语句也怂。之前这样的语句在MySQL解决那是不可能，除了垂直扩展，创造更多的从库，MySQL 也就黔驴技穷了，所以整体项目稳定运行的宝就压到了PolarDB上。
好了，在这样的情况下，极端的事情就发生了，加字段加不上，然后我后面直接跳过客服小哥，直接找到和阿里云PolarDB 核心人员解决问题的群，把这个问题给提交上去了，为什么
1 我修改了参数后，还是解决不了问题，添加字段依然失败
2 在我操作的过程中，的确所有的读操作都加了mdl 锁
在查找问题工作的线程的情况下，我的确发现有一个线程显示 KILLED ，但我当时没有多看他的time ，后面核心的POALRDB 老师也帮助分析问题，发现的确有一个语句卡主了，并且之前这样的情况也不多见。
后续这个KILLED的状态的语句完成后，问题就解决了。这边公司的开发和架构以及领导也问我，遇到这样的问题怎么办，是不是POALRDB 的问题，问之前为什么MYSQL 没有这样的问题等等，因为这个项目的人之前一直是用MySQL 对于PolarDB的了解估计和现在读这篇文章的人一样，也是不懂。
我和他们讲了POLARDB 的原理以及发生这样的问题，与使用者是有关的，且我们可以解决类似的问题，我也将我想出的解决方案和POALRDB 的老师对了一下，得到了认可，的确在极端的情况下，我们还是可以解决这个问题的，什么方案这里就不便透露了。
问题的主因是因为从库大量的大事务，不断在对热表进行访问，长时间的霸占那么，MDL虽然在主库，但是由于我们是强一致，则主库如果要进行添加字段必须拿到锁，可以一堆的读不释放锁，所以POALRDB 提前判断这个字段是加不上了，所以直接取消了加字段的工作，其实拿锁的时间很短，而这次拿不到锁这次的核心问题也不是select大事务的问题，而是 KILLED操作被卡死的问题，导致加锁失败，好在最后问题解决了。
如果想知道更多POALRDB 的事情可以去看如下的帖子
PolarDB serverless 真敢搞，你出圈了你知道吗!!!!
PolarDB 从节点Down机后，引起的主从节点强一致的争论
PolarDB 数据库架构 测试 serverless 后的 三字真言 稳定，灵活，省钱（的用对地方）
PolarDB VS PostgreSQL "云上"性能与成本评测 -- PolarDB 比PostgreSQL 好？
PolarDB for PostgreSQL 有意思吗？有意思呀
POLARDB 从一个使用者的角度来说说，POALRDB 怎么打败 MYSQL RDS
PolarDB 有问必答-- 直来直去 ，用什么打败你
POLARDB -- Ausitndatabases 历年的文章集合
PolarDB 卷来卷去 云原生低延迟强一致性读 1 （SCC READ 译 ）
Polardb X-engine 如何服务巨量数据情况下的业务 （翻译）- 2
Polardb X-engine 如何服务巨量数据情况下的业务 （翻译）- 3
这里用了快3年的PolarDB,我特别想为自己说几句，也为POLARDB 的老师说几句，因为这次我又发脾气了，没冷静，有主观的也有客观的原因，虽然私下解释了很多次，后面自己也后悔又发脾气，又耍宝，这里浅析原因
1 引入一个新的数据库对于DBA或者数据库架构师是非常大的难度的工作，因为这个替换不是人家架构师挑头的，是你DBA架构师挑头的，那责任就在谁提出谁解决，各种的情况你都要想到（实际上个人的能力是有限的，一定有想不到地方），如还保票替换MySQL 用PolarDB铁定解决之前，不能解决的问题的情况下，所有与这个项目事情有关的人，都在看着，有期待的也有冷眼的，当要么解决问题，你牛逼，要么......
在这个社会里面有几个人是真心希望你成功的，都是结果为导向，成功你是GOD，失败那就是 My God , You damn it, you liar! Is PolarDB really as good as you say?
所以你必须挺着，一个新的数据库要持续的站稳脚跟，只能用实力来说话，只要你没有达到预期目的，那么结果都不会是好的，一个新数据库要一个好的口碑很难，同时提出换数据库的人会更惨，因为你提了一个糟糕的注意，并且项目的失败你要负担所有的责任。
从某种角度上我和POLARDB for MySQL属于一根绳上的蚂蚱，要死就都死，要活大家就一起活，当然这个话有点大，POALRDB 客户众多是不会dead 的。这里还是感谢阿里云的同学很给力，相信他们也明白这个道理，还是比较支持我的，终究到现在能写出点客户对POALRDB 云上版本有深度东西的，全网除了刺头刘，也没什么人了。
最近也在反思，自己为什么累，老老实实用MySQL 不就完了，为啥费力不讨好的一个劲的和 PolarDB 上演激情大戏，然后自己为解决问题，和阿里云的老师还经常“出言不逊”落得一个脾气差，刺头刘的绰号。
用着别人走了100000遍的路不好吗，出了问题也和自己没有什么关系，MySQL 就是不行，那也和我无关，自己非要弄出一个PolarDB for MySQL 费心费力不讨好，出问题还是要自己寻找路径解决问题，这不纯纯的神经病，脑子进水了，工资多发你一块钱了，活脱脱的一个猪八戒照镜子，里外不是个人。
写到这里，一个把新数据库引入的人都这么难，那做新数据库的人呢，不更难，我就想我每次和PolarDB 的那些老师们，你来我往，为了解决问题和人家大闹，大吵，人家不生气吗？肯定生气呀，都挺难的，有时候我是挺过分的，一部分情况到那里的确就开始口不择言了。
也谢谢阿里云的老师容忍了我，理解我，实时上我们谁都不会去100%理解对方，能理解10% 20%或者在多一点就已经非常不错，感同身受值存在于真切的在对方的工作岗位上工作过才可能去真切的理解对方的难，每个人都有自己的功课要做，都有自己的责任和命运，PolarDB的老师们已经在这个项目里面做了不少事情，我已经很感谢阿里云的POLARDB 的老师了。另外对于POALRDB我还是很多东西没有摸透，虽然比99%的PolarDB使用者来说我是“遥遥领先”，但对于POLARDB 本身来说，我可能还是一个小学生，很多东西还需要和POLARDB 产品本身一起成长。
最后我想说的是，无论是我还是POLARDB的团队每天都在经受压力，从我的角度去理解他们的压力也是非常大的，不少使用POLARDB的项目都是MySQL数据库方案无法解决的问题，才到了POLARDB FOR MYSQL上寻找一线生机，奇葩的项目非常多。
综上所述，感谢PolarDB 核心研发老师们的支持，也一直包容一个没有什么涵养的刺头，我这边尽量把PolarDB 玩成了一个神挡杀神，佛挡杀佛解决项目难题，成为公司核心的数据库解决方案的数据库产品，我想这也是我和PolarDB 的共赢最美好的结果了吧。
Austindatabases 公众号，主要围绕数据库技术（PostgreSQL, MySQL, Mongodb, Redis, SqlServer，PolarDB, Oceanbase 等）和职业发展，国外数据库大会音译,国外大型IT信息类网站文章翻译，等，希望能和您共同发展。
2989
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
