Galera Cluster 是主流的 MySQL 多活多主高可用方案之一 ， 即使在 InnoDB Cluster （Group Replication） 发布以后 。
Galera Cluster 是主流的 MySQL 多活多主高可用方案之一 ， 即使在 InnoDB Cluster （Group Replication） 发布以后 。
Galera Cluster 是主流的 MySQL 多活多主高可用方案之一 ， 即使在 InnoDB Cluster （Group Replication） 发布以后 。
重要的话说三遍 :)
然而 Galera Cluster 所采用的技术方案 ， 以及它所依赖的一些技术 ， 使得它在标准的 MySQL 基础上有一些限制 。
首先 ， 它只支持 InnoDB 系列的引擎 。 这对于很多应用而言不是大的问题 。InnoDB 是最广泛使用的 MySQL 引擎 , Group Replication 也是要求 InnoDB。
第二 ， 它不支持 XA 分布式事务协议 。XA 分布式事务协议 ， 在传统的企业应用中很常用 ， 特别是 Java EE 应用中 。 这一条对于遗留 Java 系统而言是个问题 。
第三 ， 它不支持表级锁 。 因此 ， 不能使用 Lock tables 等与锁表相关的命令或函数 。 原因是 Galera Cluster 底层的 write set 技术 ， 是基于行的 。
第四 ， 它可能导致较多的冲突 。 在写集中如果有两个事务要改同一行数据 ， 那么第二个事务会被中止 。 在收到异常消息后 ， 应用应该重新发起该事务 。 这意味着应用程序的代码中 ， 应该注意处理这种情况 。 实际中可以设置为单主同步复制模式 ， 避免多主冲突 ； 通过读写分离来利用只读节点资源 。
第五 ， 不要使用字符集 UTF-16， UTF-32. UCS-2。 因为底层的 rsync 技术不支持这些字符集 ， 影响了基于 rsync 的全量复制 。 大部分应用都是使用的 UTF-8， 因此问题并不大 。
第六 ， 表一定要有主键 。 如果没有主键 ， 可以加一个自增长的主键 ， 因此不是大问题 。
第七 ，binlog 不要试图去 binlog-do-db, binlog-ignore-db。 因为 binlog 的这几个选项只是支持了 dml， 不支持 ddl， 这可能导致 binlog 的复制过程中止 。
第八 ， 同步复制技术对于有明显热点或高并发的应用而言 ， 容易产生冲突 。 与第四点相关 。
第九 ， 同步复制技术对于网络稳定性要求高 （ 针对跨机房的集群要注意 ）。 对于每一个查询 （MySQL 把所有的任务都叫查询 ） 事务 ， 都会有多节点的复制和冲突检测 。 从这个角度来说 ， 它使得每次查询都变得慢一些 （ 增加了延迟 latency）。
第十 ， 使用 Galera Cluster 的上述限制 ， 意味着需要与应用开发团队密切的合作 ， 以便尽快发现应用代码中的数据库操作相关语句或逻辑是否正好碰到了 Galera Cluster 的限制 。
尽管有这么多的限制 ，Galera Cluster 仍然是最广泛使用的 MySQL 高可用方案之一 。Galera Cluster 最宝贵的就是其自动化程度高的高可用特性 。 这种强一致性 、 高可用的方案对于关键记录处理系统而言是非常重要的 。
本文引用自：https://www.027yunwei.com/blog/mysql/mysql-galera-diff-standalone-and-limits.html