这是我参与8月更文挑战的第8天,活动详情查看:8月更文挑战
消息压缩
这个压缩主要是指MySQL的bin-log压缩,所使用的压缩算法是LZ4。当网络带宽是瓶颈时,消息压缩可以在组通信级别提供高达30-40%的吞吐量改进,这在网络传输压力比较大的组中是尤为重要的。LZ4能很好的支持多线程环境,获得更高的压缩和解压速度。以下是压缩算法LZ4的压缩和解压情况:
压缩发生在组通信引擎级别,之前数据被交给组通信线程,所以它发生在mysql用户会话线程的上下文中。事务有效网络负载可以在被发送到组之前被压缩,并且在被接收时被解压缩。压缩是有条件的,并且取决于配置的阈值。默认情况下启用压缩,此外,它并不要求组中的所有服务器节点都启用压缩机制,在接收到消息时,成员检查消息信封以验证它是否被压缩,如果需要,则成员解压缩该事务,然后将其传递到上层。
默认情况下启用压缩,阈值为1000000字节(1MB)。压缩阈值(以字节为单位)可以设置为大于默认值。在这种情况下,只有具有大于阈值的有效负载的事务被压缩。下面是如何设置压缩阈值的示例。
STOP GROUP_REPLICATION;
SET GLOBAL group_replication_compression_threshold= 2097152;
START GROUP_REPLICATION;
这将压缩阈值设置为2MB。如果事务生成的有效内容大于2MB的复制消息,例如大于2MB的二进制日志事务条目,则会对其进行压缩。禁用压缩设置阈值为0。注意:修改这个阈值是需要重启组复制的。
消息压缩流程图如下:
组复制的要求和限制
限制和要求
-
- 所有涉及的数据都必须发生在InnoDB存储引擎的表内。
-
- 所有的表必须有明确的主键定义。
-
- 网络地址只支持IPv4。
-
- 需要低延迟,高带宽的网络。
-
- 目前集群限制最多允许9个节点。
-
- 必须启用binlog。
-
- binlog 格式必须是row格式。
-
- 必须打开gtid模式。
-
- 复制相关信息必须使用表存储。
-
10.事务写集合(Transaction write set extraction)必须打开。(这个目前与savepoint冲突,这也是导致mysqldump无法备份GR实例的原因)
-
- log slave updates必须打开。
-
- binlog的checksum目前不支持。
-
- 由于事务写集合的干扰,无法使用savepoint。
-
- SERIALIZABLE 隔离级别目前不支持。
-
- 对同一个对象,在集群中不同的实例上,并行地执行DDL(哪怕是相互冲突的DDL)是可行的,但会导致数据一致性等方面的错误,目前阶段不支持在多节点同时执行同一对象的DDL。
-
- 外键的级联约束操作目前的实现并不完全支持,不推荐使用。
组复制的相关配置
依据组复制的要求和限制,以下设置根据MySQL组复制要求配置复制:
server_id = 1
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
此时my.cnf文件可确保服务器配置,并指示实例化一个给定的配置下的复制基础设施。以下部分配置服务器的组复制设置。具体参数比较简单,不在这里赘述,可参见官方说明:
transaction_write_set_extraction = XXHASH64
loose-group_replication_group_name =“aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa”
loose-group_replication_start_on_boot = off
loose-group_replication_local_address ="127.0.0.1:24901”
loose-group_replication_group_seeds =“127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903”
loose-group_replication_bootstrap_group = off
具体的组复制安装部署比较简单,网上和官方说明都有说明,在这里就不阐述安装部署这块了。