使用Galera Cluster代替主/从复制有什么缺点？

使用Galera Cluster代替常规的主/从复制有什么缺点？Galera的0从属滞后时间，同步复制和无单点故障似乎非常吸引人，那么为什么Galera集群不那么常见？

因为像任何其他优化一样，它并不适合所有工作负载。

Galera可能会因高事务率或事务更新许多行而感到不知所措。当集群同步时，它还会使您的应用程序在COMMIT上遇到延迟。

Galera也不同步更新其他节点。它只是同步传输工作集。这样，就有点像半同步模式下的标准复制。因此，从另一个群集节点读取陈旧数据的机会仍然很小。您可以设置一个选项来强制SELECT等待，直到工作集队列更新了数据库，但这意味着您在SELECT上存在延迟。甚至有可能在SELECT上陷入僵局，这似乎违反直觉。

Galera是出色的，但不是一种千篇一律的技术。仍然有充分的理由使用异步复制。

Galera的一些缺点包括：

• 存储引擎支持：仅限于InnoDB / XtraDB（以及对MyISAM的实验性支持）
• 操作系统支持：仅类似于Linux / Unix的Oses

还应注意一些限制，但可以解决：

• 默认情况下（总订单隔离）DDL操作会阻塞整个群集，直到完成
• 每个表必须有一个显式主键，单列或多列
• 锁定：不支持某些类型的显式锁定。

欲了解更多信息，请参阅详细信息在Codership（与此有关阻止DDL），MariaDB的，和Percona的。

编辑：还请注意，有些人认为紧密耦合的数据库集群（例如Galera）不应具有地理分布的节点，这是由于网络层固有的不可靠性所引起的问题。相反，在这些情况下必须使用异步解决方案。请参阅：如何不做MySQL高可用性：具有基于Galera的复制滥用的地理节点分布。尽管如此，Galera博客指出（2015年）：

建立地理分布数据库集群的理由很充分。Galera的复制方法和产品中的特定功能使构建跨越多个数据中心的Galera群集变得切实可行，并且多个用户已经在生产中使用了此类群集。