Flow Control There is however a mechanism in the replication protocol to avoid having too much distance, in terms of transactions applied, between fast and slow members. This is known as the flow control mechanism. It tries to address several goals: 1. to keep the members close enough to make buffering and de-synchronization between members a small problem; 2. to adapt quickly to changing conditions like different workloads or more writers in the group; 3. to give each member a fair share of the available write capacity; 4. to not reduce throughput more than strictly necessary to avoid wasting resources. Given the design of Group Replication, the decision whether to throttle or not may be decided taking into account two work queues:  (i)  the  certification  queue;  (ii)  and on the binary log  applier  queue. Whenever the size of one of these queues exceeds the user-defined threshold, the throttling mechanism is triggered. Only configure:  (i)  whether to do flow control at the certifier or at the applier level, or both; and  (ii)  what is the threshold for each queue. The flow control depends on two basic mechanisms: 1. the monitoring of members to collect some statistics on throughput and queue sizes of all group members to make educated guesses on what is the maximum write pressure each member should be subjected to; 2. the throttling of members that are trying to write beyond their fair-share of the available capacity at each moment in time. 18.7.2.1 Probes and Statistics The monitoring mechanism works by having each member deploying a set of probes to collect information about its work queues and throughput. It then propagates that information to the group periodically to share that data with the other members. Such probes are scattered throughout the plugin stack and allow one to establish metrics, such as: •the certifier queue size; •the replication applier queue size; •the total number of transactions certified; •the total number of remote transactions applied in the member; •the total number of local transactions. Once a member receives a message with statistics from another member, it calculates additional metrics regarding how many transactions were certified, applied and locally executed in the last monitoring period. Monitoring data is shared with others in the group periodically. The monitoring period must be high enough to allow the other members to decide on the current write requests, but low enough that it has minimal impact on group bandwidth. The information is shared every second, and this period is sufficient to address both concerns. 18.7.2.2 Group Replication Throttling Based on the metrics gathered across all servers in the group, a throttling mechanism kicks in and decides whether to limit the rate a member is able to execute/commit new transactions. 3774