以下是最近在 LinkedIn 和 mariadb.org 上进行的一项关于几个主要复制功能受欢迎程度的投票结果（我汇总了这两个网站的结果）
您最喜欢的 MariaDB 复制功能是什么？
- 36% 并行复制
- 27% 多源复制
- 23% 全局事务 ID (GTID)
- 14% 半同步复制
我想分享一些原因，解释为何投票结果与我本人对于这些功能相对重要性的看法一致。
1. 并行复制
并行复制为复制带来了急需的性能提升。这不仅对于那些从库难以跟上主库的大型网站有用，对于那些 DBA 资源较少的小型网站也非常有帮助，例如，让从库在意外停止 5 天后迅速赶上主库。
乐观并行复制的优点在于它“开箱即用”，无需在应用端进行更改（如分区数据），也无需对数据库配置端施加限制（如基于行的 binlog 格式）。
2. 多源复制
多源复制是指能够同时从两个（或更多）主服务器复制不同数据的功能，这也许是 MariaDB 复制中一个被低估的功能。在需要时提供这种灵活性的能力，我认为是 MariaDB 成功的核心。逻辑复制是这种出色灵活性的架构基础，虽然它在代码中造成了很大的复杂性，但它提供了基于物理复制等架构所不具备的功能。
3. 全局事务 ID (GTID)
GTID 允许复制无缝地停止从一个主服务器复制，并从另一个主服务器继续复制。这似乎是理所当然的，但传统上，MariaDB（或 MySQL）复制在很多年里都没有提供此功能。
MariaDB GTID 的强大之处在很大程度上取决于其在服务器代码中实现的细节。其核心是一个复制流集合的概念，每个流由 DBA 配置的域 ID 标识，每个流包含一个严格有序的待复制事务列表。这使得复制状态能够以简单的方式呈现给 DBA（最简单的情况下是一个单独的事务 ID），同时仍然提供了完全的灵活性来支持多源、环形和其他高级复制拓扑。它还为乐观并行复制提供了基础。
4. 半同步复制
半同步复制有时很有用，但我认为其高效配置并不像人们通常认为的那样容易。它不会神奇地将 MariaDB 复制拓扑转变为完全同步的复制集群。它真正做的只是延迟事务提交的时间。
完全且稳健地处理任何错误取决于应用程序本身，这不仅包括重试失败的事务提交，还包括正确确定尽管提交返回错误但事务是否实际成功的本领。我可能会在MariaDB Day Brussels对此有更多要说的。