前言
- 一个分布式计算和存储系统的任何节点都可能因为节点负载过重，节点的计算、存储资源不足，网络延时，网络短暂不可达而导致操作超时。
- 分布式系统的任何操作在等待远程节点返回期间，通常会持有各种资源，不可以无限制等待下去，否则系统整体运行都会因此被阻塞而逐步停滞。
所以超时控制是所有分布式系统需要去解决好的问题，而解决不好就会导致系统运行停滞，无法正常工作。
昆仑分布式数据库的超时控制机制简介
昆仑分布式数据库有以下超时控制变量：
一部分在计算节点中，计算节点的超时变量都在计算节点实例的配置文件中，可以按需修改，并且修改后刷新运行实例的参数。
一部分在存储节点中，存储节点的超时变量在存储节点配置文件中，可以修改配置文件，也可以通过在计算节点或者存储节点执行set语句修改对应变量值。
通常情况下用户并不需要修改这些变量，因为我们已经针对常规情况最优化了计算节点和存储节点的配置参数。
不过在特殊场景下还是需要修改这些超时变量的。
典型场景就是需要在一个DML语句中插入/更新/删除数百万行甚至更多的数据，或者一个select语句中要返回数百万行甚至更多的数据。
例如，逻辑导入超大的数据表或者全量数据，对超大的表做全表更新，数据分析（OLAP）查询需要扫描一个超大的表，以及程序员或者DBA打算删库跑路等等。
这些场景下用户最好根据预估插入/更新/删除/读取的数据量，提前增大下述各个超时值，以确保相关语句和操作可以正常工作直至完成，不会被超时机制误认为是已经超时无法正确执行的语句而提前终止掉。
或者用户可以在尝试这些操作并得到错误之后，再增大这些超时值。
下面就让我们看一下昆仑分布式数据库的所有超时控制变量。
计算节点的超时变量功能
- statement_timeout：语句超时。
如果计算节点执行查询的总时间超过这个限制，语句就会被回滚。
比如，如果计算节点使用存储集群返回的部分数据执行表连接时耗过长，那么最终会在达到这个超时限制后停止（默认100秒）。
- mysql_read_timeout和mysql_write_timeout：计算节点于存储节点/元数据节点之间的通信收发（读写）超时。
读取超过mysql_read_timeout或者写入超过mysql_write_timeout 那么计算节点使用的mysql客户端库就会报错并且从读取/写入等待中返回，这样语句执行就提前终止了。
如果一条发送给计算节点的一条insert语句会插入100万行数据，或者一条select语句会从存储节点返回上百万行数据，那么最好增加这两个变量的值，它们默认是50秒。
另外，这种情况下还要增大mysql_max_packet_size 变量，确保这样的超大数据包可以正确发送给存储节点。
- lock_timeout：计算节点等待表锁的时间。
并发执行的增删改查语句对表的所是相容的，不需要等待锁。
但是如果某个alter table语句正在执行，那么同一个计算节点上其他连接中无法执行针对这个表的DML语句，它们最多等这么久，还拿不到锁就会报错返回（默认 100秒）。
- log_min_duration_statement：超过这个时间的语句会作为慢查询记录到日志文件中。
如果要在每条insert语句中插入数万行甚至更多，那么一定要把这个变量增大，否则会在日志文件中记录大量数据，导致计算节点磁盘空间用尽（默认10秒）。
存储节点的超时变量功能
- lock_wait_timeout：mysql server层的锁超时变量。
等待server层的表锁的最大时间。如果一个DDL语句在alter table, 那么所有对该表做DML语句的事务会阻塞等待最多这么多表，还得不到表锁就会返回错误。
在MySQL8.0时代，加列和加索引这种最常见的曾经要锁住全表才能完成的操作已经不需要全表长期锁定了，已经变成了online ddl，因此默认5秒一般来说足够了。
- innodb_lock_wait_timeout：mysql innodb的锁超时变量，等待innodb行锁的最大时间。
超过了那么DML语句就会报错返回。
如果要做全表更新，并且表的数据量非常大，比如几百GB甚至更多，那么update语句会锁住大量的行很长时间，此时其他事务通常会发生锁超时，除非增大了其innodb_lock_wait_timeout（默认20秒）。
- 如果存储集群使用了MySQL Group Replication做高可用，那么需要增大
MGR的group_replication_member_expel_timeout，group_replication_component_stop_timeout, group_replication_unreachable_majority_timeout 超时控制变量，否则MGR的备机会误以为主节点宕机了从而发起主备切换，或者主节点以为备机失去联系了从而无法写入。
结语
昆仑分布式数据库具备完善的超时控制机制，在任何节点间通信机制中都有超时控制，确保任何操作都有最大时耗上限，确保系统状态可以持续推进，系统资源持续可服务更多的服务请求。
*KunlunDB项目已开源
【GitHub：】
https://github.com/zettadb
【Gitee：】
https://gitee.com/zettadb
END