天在MGR环境下，造一个表数据，使用语句如下，报错如下。

且集群解散了，我们来看看是什么原因。

报错内容：

语句：一般不建议这么干

INSERT INTO demo.mq_receive_history(create_time,update_time,del_flag,code,gid, uid,msg_id,receive_time,data,receive_message,error_code,error_msg,is_ui_run, is_system_login, code_run_id)

select create_time, update_time, del_flag, code, gid, uid, msg_id, receive_time, data, receive_message, error_code, error_msg, is_ui_run, is_system_login, code_run_id from mq_receive_history

报错内容

Transaction of size 181815674 exceeds specified limit 150000000. To increase the limit please adjust group_replication_transaction_size_limit option.'

大概的意思可能就是事务量太大超过了限制的值，需要调整。

官方解释：

Use the system variable group_replication_transaction_size_limit to specify a maximum transaction size that the group will accept. In MySQL 8.0, this system variable defaults to a maximum transaction size of 150000000 bytes (approximately 143 MB).

Transactions above this size are rolled back and are not sent to Group Replication's Group Communication System (GCS) for distribution to the group. Adjust the value of this variable depending on the maximum message size that you need the group to tolerate, bearing in mind that the time taken to process a transaction is proportional to its size.

大概的意思：超过事务大小限制

使用系统变量 group_replication_transaction_size_limit 来指定组将接受的最大事务大小。在MySQL 8.0中，此系统变量默认为最大事务大小为150000000字节（约143 MB）。超过此大小的事务将被回滚，并且不会发送到组复制的组通信系统（GCS）进行分发。

解决：

我们把参数设置为0。不限制大小，看看能否成功。

set group_replication_transaction_size_limit

接着测试：成功了

我们再看下另外一个参数：group_replication_message_cache_size

当事务量继续超过1G时候，group_replication_transaction_size_limit 保持为 0 不做事务限制，

也会发生节点失联导入失败。

因为超出了 xcom cache 限制，xcom cache 缓存了最近一段时间的消息信息，

当节点失联后加回集群，失联期间的消息要通过 xcom cache 来恢复，如果缓存空间不够，缺失的消息被淘汰了，节点就无法自动加回集群，只能手动加回集群通过异步复制通道恢复数据。

官方文件解释：

xcom使用情况可以使用如下语句查询：

CURRENT_COUNT_USED xcom cache 当前已使用 slot 数量

CURRENT_NUMBER_OF_BYTES_USED xcom cache 当前已使用内存空间

接着引发了几个思考。大事务改如何办？MGR还有哪些限制？Insert select 加锁规则是什么样的？

我们先看 大事务处理：

问题一：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.调整 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。

3.大文件数据加载应拆分后导入，推荐使用 mysql shell 的util.importTable。

MGR还有哪些限制？以及insert select加锁规则我们下期来看看。