MySQL 9.0 发行说明
根据在组中所有服务器上收集的指标,限速机制会启动并决定是否限制成员执行/提交新事务的速率。
因此,从所有成员获取的指标是计算每个成员容量的基础:如果成员具有较大的队列(用于认证或应用线程),则执行新事务的容量应接近上一时期认证或应用的容量。
组中所有成员的最低容量决定了组的实际容量,而本地事务数决定了有多少成员写入它,因此该可用容量应与多少成员共享。
这意味着每个成员都根据可用容量建立了一个写入配额,换句话说,它可以在下一时期安全地发出一定数量的事务。如果认证程序或二进制日志应用程序的队列大小超过用户定义的阈值,则限速机制会强制执行写入配额。
配额会因上一时期延迟的事务数量而减少,然后还会再减少 10%,以使触发问题的队列减小其大小。为了避免队列大小超过阈值后吞吐量出现大幅跳跃,此后吞吐量只允许在每个时期增长相同的 10%。
当前的限速机制不会惩罚低于配额的事务,但会延迟完成超过配额的事务,直到监控周期结束。因此,如果写入请求发出的配额对于一些事务来说非常小,则这些事务可能具有接近监控周期的延迟。