标签: xtradb-cluster

使用 Galera Cluster 而不是常规的 Master/Slave Replication 有什么缺点？Galera 的 0 从延迟时间、同步复制和无单点故障看起来很吸引人，那为什么 Galera 集群不常见呢？

我有一个 3 节点 Percona XtraDB 集群，根据mysqlcheck，其中一些表已损坏（一些索引包含错误的条目数）：

mydb.mytable
Warning  : InnoDB: Index 'foo' contains 1393929 entries, should be 1393918.
Warning  : InnoDB: Index 'bar' contains 1393921 entries, should be 1393918.
error    : Corrupt

OPTIMIZE TABLE在集群上运行的最佳实践是什么？

我在没有用户的测试环境中做了一些实验，似乎OPTIMIZE TABLE一个节点上的an不会自动将其影响传播到其他节点。这与此命令修改索引和表的存储空间，而不是其内容或其定义的事实一致。

• 在每个节点的生产环境中运行命令，让它在下一个节点中运行之前完成它可能有什么缺点？

• 考虑到 MySQL（和 Percona XtraDB Cluster，据我所知）不支持分布式表锁，这对用户会有什么影响？这会使集群处于不一致的状态吗？

由于我们的初创公司发展顺利，我们现在遇到了一些您一直认为永远不会影响您的问题。

我们已经扩展了很多应用程序堆栈：我们将临时信息的高读/写表卸载到一个单独的 Percona 服务器，其中表以“Engine=MEMORY”运行，并将其他部分迁移到 cassandra 集群。

现在我们剩下一个“精益”数据库，其中我们的读/写负载为 88%/12%。在这一点上，我有几个问题想得到一些反馈：

1. 读奴隶

通过我们的读/写设置，一些（例如 2-3 个）读从站应该将我们的写主站上的读负载减少到最低限度。read-slave 解决方案的可扩展性如何：如果我们的负载增加一倍/三倍，我们的负载是添加额外的 read slaves 将继续为读取提供足够的容量？我阅读了这篇文章：每个主人的奴隶数量有什么限制？然而，不是出于可扩展性背景，这可能看起来很愚蠢，但这是一个可冻结的解决方案吗？有很多人在推动分片而不是读从解决方案，但是，我现在真的认为我们的读/写负载不需要重写我们应用程序的大部分......有什么想法吗？

2. 多数据中心和复制

此外，我们正在考虑为附近的数据中心提供服务，以减少网络延迟（我们处理不喜欢延迟的移动应用程序）。计划是使用很多提到的半同步。复制（见：这是个好主意，MySQL数据库分成两个服务器，并为MySQL复制的高延迟互连是否受影响？）的主-主复制，其中每个数据中心都有一个主，和多个读的奴隶。同样，天真地，我很想知道在扩展时这是否在“最佳实践”的范围内。

3. 硬件和配置

过去几周我一直忙于对我们的实时系统进行基准测试，我得出的结论是，无论我们为第 1 点和第 2 点选择哪种解决方案，我们当前使用的服务器都不会运行很长时间，是否可以我对我们的设置有一些想法：

CPU: Intel(R) Xeon(R) CPU E31275 @ 3.40GHz mit 8 cores (hyperthreading)
RAM: 16GB
Raid 10 with a strip size of 64 KB and controller cache enabled
Software: Percona 5.5
Database size: 83.7GB
Top 5 Tables:
 21302MB  table1
 7656MB  table2
 5477MB  table3
 4352MB  table4
 3663MB  table5

my.cnf 设置： …

我目前正在考虑建立一个数据库集群（MySQL Galera 或 Percona），但我只有 2 台机器。

但是，根据我读过的许多来源（这篇来自 Mariadb KB 的文章），集群中的最小节点大小应为 3，以避免出现裂脑情况。

为了避免裂脑情况，集群中推荐的最小节点数为3。阻止状态转移是需要至少3 个节点才能在其中一个成员发生故障并需要重新启动时享受服务可用性的另一个原因。虽然其中两名成员将从事状态转移，但其余成员将能够继续为客户请求提供服务。

所以我想知道我是否可以在两台机器上运行 3 个（或更多）docker 容器，每个容器都运行一个数据库服务器。如果其中一台机器出现故障，集群中仍然有 3 个节点，因此不会出现裂脑问题。

感觉像是作弊，但我想不出不这样做的理由。

这个设置有意义吗？