Group Replication 确保事务仅在组中的大多数成员收到它并就并发发送的所有事务之间的相对顺序达成一致后才提交。如果对组的写入总数不超过组中任何成员的写入容量，则此方法效果很好。如果确实如此，并且某些成员的写入吞吐量低于其他成员，尤其是写入者成员，则这些成员可能会开始落后于写入者。
让一些成员落后于组会带来一些问题的后果，特别是，对这些成员的读取可能会外部化非常旧的数据。根据成员落后的原因，组中的其他成员可能必须保存或多或少的复制上下文才能满足来自慢速成员的潜在数据传输请求。
然而，复制协议中有一种机制可以避免快成员和慢成员之间在应用的事务方面有太大的距离。这称为流控制机制。它试图解决几个目标：
让成员保持足够接近，使成员之间的缓冲和去同步化成为一个小问题；
快速适应不断变化的条件，例如不同的工作量或组中更多的作者；
为每个成员提供公平份额的可用写入容量；
不要减少吞吐量超过避免浪费资源的严格必要性。
考虑到 Group Replication 的设计，是否节流的 决定可能会考虑两个工作队列：（i）认证队列； (ii)和二进制日志应用 程序队列。只要其中一个队列的大小超过用户定义的阈值，就会触发节流机制。仅配置：（i） 是否在验证者或应用程序级别或两者进行流量控制；( ii)每个队列的阈值是多少。
流量控制取决于两个基本机制：
监控成员以收集所有组成员的吞吐量和队列大小的一些统计数据，以对每个成员应承受的最大写入压力进行有根据的猜测；
试图在每个时刻及时写入超出可用容量的公平份额的成员的节流。