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

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

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

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

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

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

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

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

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

本文分享自微信公众号 - AustinDatabases（AustinDatabases）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。