8.Frequently Asked Questions

组复制常见问题FAQ

本节列出了关于组复制的常见问题。

复制组允许的最大成员数量？

一个复制组最多只允许9个成员，当想要添加第10个成员时，将会拒绝加入。

组内成员如何连接？

组内的成员会建立端对端(peer-to-peer)的 TCP 连接。这些连接仅用于组内通信和消息传递。

选项group_replication_bootstrap_group是干什么用的？

bootstrap标记指示这个成员去创建一个组，并且扮演组内第一个种子节点。第二个成员要加入组时，需要询问这个引导者，让其动态更新组配置以便让新成员加入组。

有两种场景下需要一个成员来引导组。当组第一次被创建时，或者当停止整个组后再启动组时。

我要如何设置恢复过程(阶段)的凭据？

使用 CHANGE MASTER TO 语句先配置好组复制恢复通道凭据即可。

使用组复制是否可以负载写操作？(scale-out write-load)

无法直接实现这样的目的，但是MySQL组复制是一种 share-nothing 的复制模式，组内所有节点都有完全相同的数据副本。因此，如果组内某节点上通过事务提交操作向存储引擎写入了 N 字节的数据，那么其他所有节点上也都会向存储引擎写入 N 字节数据，因为在组中，事务会到处复制。

虽然其他节点上也写入 N 字节数据，但是它们不像发起事务的那个节点一样会执行事务，它们完成这个事务的速度非常快。事务以一种格式(组复制强制限制为 row-based 格式)在组内复制，因此其他节点只需转换行数据即可，无需去重新执行事务。

此外，"以 row-based 的方式传播已发生的更改"意味着它们以一种优化的、紧凑的方式接收事务，相比于事务发起节点，这会减少IO的操作数量。

总而言之，通过在组内传播无冲突的事务可以实现写操作的负载。而且，还可以负载一小部分的IO操作，因为远程节点接收事务后会经过"读--改--写"的过程，从而只写入一些必要的更改到存储中。

在相同的工作负载下，组复制是否比常规复制需要更多的网络带宽和CPU？

确实如此。因为处于组内同步的原因，每个节点都需要不断地和其他成员交互，所以在预期上它需要更多资源。难以量化到底多需要多少资源的数据。它还取决于组的大小(组中只有3个节点肯定比9个节点需要的带宽压力小)。

此外，内存和CPU的需求也更大，因为组内节点同步和消息传递需要完成更复杂的工作。

能否在广域网(WAN)上部署组复制?

可以。但是组内成员之间的连接必须要保证可靠性以及良好的网络传输性能。低延迟、高带宽的网络连接是最优性能的基本要求。

如果网络带宽是个问题，可以使用消息压缩功能(Message Compression)来降低带宽的要求。但是，如果出现网络丢包问题，从而导致数据重传和高延迟，那么组复制的吞吐量和延迟性都将受到影响。

警告
当组内任何成员之间的网络往返时间(RTT)为2秒或以上时，您可能会遇到一些问题，因为内置的故障检测机制可能被不正确触发。

当出现临时的连接问题，成员是否可以自动重新加入组？

这取决于出现连接问题的原因。如果连接问题是短暂的且再次连接成功足够快速，那么故障探测器就无法意识到这个问题，这个成员就不会从组中踢出。如果"短"期内无法再次连接成功，那么故障探测器就会怀疑这个节点是否故障，于是节点会从组中踢出。

当节点从组中踢出去后，你需要重新将它加入到组中。换句话说，当节点离开组后，你只能手动(或使用脚本)将它重新加入回组。

成员何时会被排除在组外？

如果节点沉默了，其他成员将其从组配置中移除。这可能是发生了节点宕机或网络断开的情况。在一段超时时间之后，这个故障会被探测到，之后会重新配置组，使其不包含这个故障节点。

当有一个节点明显落后时，会发生什么？

没有任何可以制定的策略用来决定何时自动从组中驱逐一个节点。你需要查找出这个成员为什么会明显落后，然后修复它或者将它从组中移除。否则，如果节点很慢，慢到触发流程控制(flow control)，这将会让整个组都放慢脚步。可以根据你自己的需要来定制flow control。

当怀疑组中某节点故障时，是否有专门的成员负责触发组重新配置的操作？

没有，组中没有专门的成员复制触发组重新配置。

任何成员都可能怀疑出现了问题。所有成员都需要(这是自动的)就某成员出现故障的问题达成一致。然后会有一个(某)成员通过触发组重新配置，负责将故障节点驱逐出组，但这个成员无法控制和设置的。

我可以用组复制来进行分片(sharding)吗？

组复制旨在提供高可用的副本集：组中每个节点上的数据都是重复的。为了扩展单系统所能提供的能 力，你需要一个围绕着一系列组复制集的编排(orchestration)和分片框架(译注：编排的意思是在复杂的环境中让杂乱、复杂的工作简化、流程化)，使得每个副本集都负责维护和管理整个数据集中的一个给定切片或分区。这种类型的配置通常称为"分片集群(sharded cluster)"，可以让你无限地线性扩展读、写。(译注：此处的扩展请理解为"负载分散"、"压力分散"的意思，也就是让架构具有负载伸缩性)

使用组复制时如何配置iptables？

如果启用了iptables，你需要放行用于成员间通信的端口。使用iptables -L查看当前规则。假定你配置的用于成员间通信的端口为6606，执行iptables -A INPUT -p tcp --dport 6606 -j ACCEPT可放行该端口上的通信数据。(译注：节点上用于 成员间通信的端口是给其他节点联系本节点用的，本节点联系其他节点时自身分配一个随机端口)

如何恢复成员所使用的复制通道的relay log？

组复制所使用的复制通道和常规主从复制使用的通道行为是一样的，因此依赖于relay log。当修改了relay_log变量，或者未设置该变量而主机名发生了改变，则可能会出现错误。这类问题的解决方法见Section 16.2.4.1 “The Slave Relay Log” 。你也可以执行STOP GROUP_REPLICATION和START GROUP_REPLICATION语句来重启组复制，此时组复制插件会重新创建group_replication_applier通道，这也能修复该问题。

为什么组复制要使用两个地址？

使用两个地址是为了将SQL客户端的请求和组内成员通信的网络流量分开，其中组内其他成员连接本节点时使用的地址由选项group_replication_local_address设置。例如，某节点有两个网络接口，地址分别为203.0.113.1和198.51.100.179，group_replication_local_address=203.0.113.1:33061表示203.0.113.1:33061用于组内通信，然后你可以使用198.51.100.179作为主机名。以后SQL客户端程序可以通过连接198.51.100.179:3306来获取MySQL提供的数据库服务。