“偶遇” 爱可生 与 MYSQL 大型应用

今天“偶遇” 爱可生的技术人员，经过了两个小时的交流，又重塑的我对大型系统中对MYSQL 的应用， 这绝对不是广告，这绝对不是广告，这绝对不是广告，重要的还的说几遍。

为什么心甘情愿的写点东西，其实对爱可生的认知早在N年前，培训MYSQL 就去过漕河泾的爱可生。当时还在一个外企，肯花钱让我做飞机去魔都。

话归正题，各家产品中的MYSQL 的复制技术都是一样的，这是改变不了的，半同步，GTID等等这都是MYSQL中熟知的基本LISTS. 问题是一个小体积的应用和一个大型金融机构使用 MYSQL 系统，就要有本质的区别。尤其到了银行级别的应用，各种使用的方式就有更多的发挥的地方和要求的地方。一个简单的MYSQL 就变得越发的不简单。

从FAILOVER 的方式就要有更多的考虑，半同步，MHA，MGR 对小企业也许就够了，对金融机构，银行体系那就变得不那么容易，细节，更多的严谨性，就变得不是可有可无。

一切关于金钱的事情都变得慎重，性能，稳定，高可用，在某些场景类似CAP 的原理，都兼顾是不好实现，在保证某些必须要保证的情况下，兼顾性能，自动化自愈等等都是一个数据库打包后的卖点，卖的是什么，一个整套的方案将一个数据库某些不能自己实现的功能，加以雕琢和补全。

在技术交流过程中，关于高可用中的切换，对于大型系统的应用，需要做的更细，考虑的问题更多。数据强一致性，与脱离传统数据FAILOVER后的切换，都从更底层的MYSQL数据库系统信息的收集做起。通过RAFT 协议方式进行选择性的切换。

以前一直认为ORACLE TO MYSQL （不考虑开发的问题），虽然在系统额扩展性上MYSQL 是有优势的，但稳定性和大型系统的可靠性上，都是ORACLE 可以吐槽的。现在觉得MYSQL 如此系统化发展下去，这个吐槽的点都会变得“动摇”。

MYSQL 至始至终都在用我很小，但我可以人多力量大的思路来将系统难题化解，配以开发的微服架构的流行，大型系统的拆分。配角变主角的逆袭，还能被阻挡？