提起 GreatDB 大家可能会有些陌生，但是说到万里数据库很多开发者一定有所耳闻。

没错，万里数据库并不是一家新兴企业，而是有二十余年积淀，专注于自主可控数据库和操作系统研发和服务的老牌企业。万里数据库是国内最早从事国际主流数据库核心研发的本地团队，其数据库技术底蕴主要来自于从 2006 年开始与 MySQL AB 合作成立的 MySQL 中国研发中心。

万里数据库于 2010 年开始独立自研分布式事务型数据库 GreatDB，而其源于 Percona Server 分支版本的 GreatSQL 今天已正式在 Gitee 开源，欢迎广大 MySQL 爱好者们前来围观和使用。

仓库地址： https://gitee.com/GreatSQL/GreatSQL

首先，GreatSQL 完全免费并兼容 MySQL 或 Percona Server，可以作为MySQL或Percona Server的可选替代方案，用于线上生产环境。

除了Percona Server已有的稳定可靠、高效、管理更方便等优势外，GreatSQL 进一步提升了 MGR（MySQL Group Replication）的性能及可靠性，并修复了诸多 Bug。

此外，GreatSQL 还合并了由华为鲲鹏计算团队贡献的两个 Patch，分别针对 OLTP 和 OLAP 两种业务场景，尤其是 InnoDB 并行查询特性，TPC-H 测试中平均提升聚合分析型 SQL 性能 15 倍，最高提升 40 多倍，特别适用于周期性数据汇总报表之类的 SAP、财务统计等业务。

GreatSQL的优势与展望

在金融级应用场景中，对数据的可靠性和架构的容错性要求都更高，对多数据中心甚至多活都有较高需求。

为此，GreatSQL 未来会在以下几方面着重发力，让 GreatSQL 做到Making MySQL great again！

增加更多金融级场景需求特性

增加地理标签功能。当在多机房部署MGR时，可以保证每个机房中至少有一个节点都参与事务认证，确保该节点总有最新事务，这可用于解决多机房数据同步的问题。
采用全新的流控机制，流控阈值计算更合理、细致，不会出现频繁性能抖动问题。

更多企业级新特性正在持续完善中，后续的版本会陆续放出。

提升同城双机房和跨城架构部署的可靠性

支持 AFTER 模式下多数派写机制。发生网络分区时，只要多数派节点已经回放完毕，集群就可以继续处理新的事务，依然可以保障集群的高可用性。
解决磁盘空间爆满时导致 MGR 集群阻塞的问题。当发现某节点磁盘空间满了，就会让这个节点主动退出集群，避免像 MySQL 社区版那样整个集群被阻塞的问题。
解决多主模式下或切主时可能导致丢数据的问题。调整了事务认证处理流程，改成放到 applier queue 里按照 paxos 顺序处理，这就解决了在多主模式下或切主时可能导致丢数据的问题。
解决节点异常退出集群时导致性能抖动的问题。优化 paxos 通信机制，发生异常时只会产生约 1~3 秒的性能小抖动，最差时 TPS 可能只损失约 20% ~ 30%。而 MySQL 社区版本可能会造成约 20~30 秒的性能抖动，最差时 TPS 可能有好几秒都降为 0。下面两个图非常明显体现了 GreatSQL 针对这种情况所做的优化。

MySQL社区版： 5秒发现问题，22秒后将其踢出。