技术分享 | InnoDB Cluster 如何高效加载数据

做者：洪斌
爱可生南区负责人兼技术服务总监，MySQL  ACE，擅长数据库架构规划、故障诊断、性能优化分析，实践经验丰富，帮助各行业客户解决 MySQL 技术问题，为金融、运营商、互联网等行业客户提供 MySQL 总体解决方案。
本文来源：转载自公众号-玩转MySQL
*爱可生开源社区出品，原创内容未经受权不得随意使用，转载请联系小编并注明来源。

---

一行命令搞定 InnoDB Cluster 数据快速加载。

InnoDB Cluster 8.0 通过一系列的优化已足够稳定，早期版本常因网络延迟、闪断等问题形成集群不稳定，也曾遇到客户因网络缓解问题致使节点频繁被踢，可用性得不到保障，不得不使用外围运维手段保障集群稳定性，也增长了运维工做的复杂性。如今经过参数优化已能获得有效解决，可以容忍必定网络波动。解决了网络问题，另外一个使用 InnoDB Cluster 面临问题就是大事务了，系统不免会遇到大的 DML，load data 操做。在数据同步机制上 group replication 与 async replication、semi-sync replication 有很大差别。它是参考 paxos 协议实现了独立的组通信引擎 xcom 集成在 MySQL，xcom 负责节点间消息的发送与接收，并保证消息投递的一致和有序，消息包括两类事务写集相关信息和心跳统计相关信息。xcom 是单线程实例，在处理大事务必然会影响其余消息的处理，若是是来自其余节点的心跳消息没法回应，5s 无响应节点会被踢出集群。group_replication_transaction_size_limit 参数限制了事务大小，超出限制事务回滚不会广播。事务消息就是 writeset，其大小是由事务变动行数、行长度、惟一索引数量等因素决定。为了加强对大事务的处理能力，8.0.16 支持了消息分片机制，经过 group_replication_communication_max_message_size 参数控制消息分片大小，若消息超过该限制会自动分包广播，到达其余节点后自动合并起来，此参数不能大于 slave_max_allowed_packet 值，默认是 10MB，最大上限 1GB。

那有了消息分片机制是否是就完美支持大事务了？

我模拟了 load data 导入一个 185MB 的文件。在 group_replication_transaction_size_limit 默认 147MB 配置下是没法导入的，超过限制事务被回滚。

将 group_replication_transaction_size_limit 设置为 0 至关于取消限制，能够成功导入，且集群节点状态所有正常，没有节点被踢出集群。

还能处理更大的事务吗？

随后测试中我将数据文件放大到 1G，group_replication_transaction_size_limit 保持为 0 不作事务限制，会发生节点失联导入失败。由于超出了 xcom cache 限制，xcom cache 缓存了最近一段时间的消息信息，当节点失联后加回集群，失联期间的消息要经过 xcom cache 来恢复，若是缓存空间不够，缺失的消息被淘汰了，节点就没法自动加回集群，只能手动加回集群经过异步复制通道恢复数据。8.0.16 以前 xcom cache 是固定配置 50000 个 slot 或 1G 内存，超出限制按 LRU 策略回收内存空间，8.0.16 新增了 group_replication_message_cache_size 参数取消了固定限制，用户能够结合实际状况调整，配合 group_replication_member_expel_timeout 调整能容忍更长网络延迟。xcom cache 使用状况在 memory_summary_global_by_event_name 观测

mysql> select * from  memory_summary_global_by_event_name where event_name like 'memory/group_rpl%'\G
*************************** 1\. row ***************************
EVENT_NAME: memory/group_rpl/GCS_XCom::xcom_cache
COUNT_ALLOC: 2362
COUNT_FREE: 2317
SUM_NUMBER_OF_BYTES_ALLOC: 5687428055
SUM_NUMBER_OF_BYTES_FREE: 3196560772
LOW_COUNT_USED: 0
CURRENT_COUNT_USED: 45
HIGH_COUNT_USED: 1176
LOW_NUMBER_OF_BYTES_USED: 0
CURRENT_NUMBER_OF_BYTES_USED: 2490867283
HIGH_NUMBER_OF_BYTES_USED: 3195280758
1 row in set (0.0030 sec)

• CURRENT_COUNT_USED  xcom cache 当前已使用 slot 数量
• CURRENT_NUMBER_OF_BYTES_USED  xcom cache 当前已使用内存空间

若是将 xcom cache 设置足够大，能处理更大的事务吗？

group_replication_message_cache_size 上限是 16EB，cb_xcom_receive_data 函数接收消息的限制是 4G，有兴趣能够试验下加载一个 5G 数据文件会是什么状况。但大事务对内存和网络的开销，会影响集群总体性能，仍是应尽可能避免大事务。

了解了组复制对大事务的处理方式，如何快速的导入数据？

正确作法是拆分红小文件并行导入，mysql shell AdminAPI 早已集成了并行导入小工具，自动拆分并行处理，效率更高，开箱即用。

mysqlsh root@localhost:4000 --ssl-mode=DISABLED -- util import-table /Users/hongbin/mysql-sandboxes/4000/mysql-files/sbtest --schema=test --table=sbtest2 --bytes-per-chunk=10M

总结

1. 消息分片机制能在必定程度下降大事务形成节点被踢出集群的几率，但集群性能依然会受影响。
2. 大事务须要占用更多 xcom cache 空间，xcom 要申请更多内存空间，也会有被 OOM 的风险。
3. 应尽可能避免大事务，调整 group_replication_transaction_size_limit、group_replication_message_cache_size、group_replication_communication_max_message_size、group_replication_member_expel_timeout 参数只能缓解部分问题。生产环境也不建议设置 group_replication_transaction_size_limit 为 0。
4. 大文件数据加载应拆分后导入，推荐使用 mysql shell 的util.importTable。