17.9.7.3 Flow Control — MySQL 5.7

17.9.7.3 Управление потоком

Группа репликации гарантирует, что транзакция совершается только после того, как большинство членов группы её получили и согласовали относительный порядок всех транзакций, отправленных одновременно.

Этот подход хорошо работает, если общее количество записей в группе не превышает пропускную способность записи любого члена группы. Если это происходит и некоторые члены имеют меньшую пропускную способность записи, чем другие, особенно чем члены-записывающие, эти члены могут начать отставать от записывающих.

Если некоторые члены отстают от группы, это приводит к некоторым проблемам, в частности, чтение на таких узлах может показывать очень старые данные. В зависимости от причины отставания члена, другие члены группы могут сохранить больше или меньше контекста репликации, чтобы выполнить потенциальные запросы передачи данных от медленного узла.

Однако в протоколе репликации есть механизм для предотвращения слишком большого отставания, с точки зрения применённых транзакций, между быстрыми и медленными членами. Это механизм управления потоком. Он пытается достичь нескольких целей:

сохранять члены достаточно близко, чтобы буферизация и десинхронизация между членами были небольшой проблемой;
быстро адаптироваться к изменяющимся условиям, таким как различные рабочие нагрузки или большее количество записывающих членов в группе;
обеспечить каждому члену справедливую долю доступной пропускной способности записи;
не снижать пропускную способность больше, чем строго необходимо, чтобы избежать потери ресурсов.

Учитывая конструкцию группы репликации, решение о том, нужно ли ограничивать или нет, может приниматься с учётом двух очередей задач: (i) очередь сертификации; (ii) и очередь обработчика бинарного лога. Всякий раз, когда размер одной из этих очередей превышает определённый пользователем порог, срабатывает механизм ограничения. Необходимо настроить только: (i) нужно ли выполнять управление потоком на уровне сертифицирующего узла или обработчика, или на обоих; и (ii) какой порог для каждой очереди.

Управление потоком зависит от двух основных механизмов:

мониторинг членов для сбора статистики о пропускной способности и размерах очередей всех членов группы, чтобы сделать обоснованные предположения о максимальной нагрузке записи, которая должна быть на каждом члене;
ограничение членов, которые пытаются записать больше, чем справедливая доля доступной пропускной способности в каждый момент времени.

17.9.7.3.1 Сбор данных и статистика

Механизм мониторинга работает путем развертывания на каждом узле набора датчиков для сбора информации о его очередях задач и пропускной способности. Затем эта информация периодически передается в группу для обмена данными с другими членами.

Эти датчики распределены по всему стеку плагина и позволяют определить метрики, такие как:

размер очереди сертификации;
размер очереди обработчика репликации;
общее количество сертифицированных транзакций;
общее количество применённых удалённых транзакций на узле;
общее количество локальных транзакций.

После получения сообщения со статистикой от другого члена, узел вычисляет дополнительные метрики, относящиеся к тому, сколько транзакций было сертифицировано, применено и выполнено локально в течение последнего периода мониторинга.

Данные мониторинга периодически обмениваются с другими членами группы. Период мониторинга должен быть достаточно большим, чтобы позволить другим членам принять решение о текущих запросах записи, но достаточно коротким, чтобы минимально повлиять на пропускную способность группы. Информация обменивается каждую секунду, и этого периода достаточно для решения обеих задач.

17.9.7.3.2 Управление потоком в группе репликации

На основе метрик, собранных по всем серверам в группе, срабатывает механизм ограничения и решает, нужно ли ограничить скорость, с которой узел может выполнять/совершать новые транзакции.

Следовательно, метрики, полученные от всех членов, являются основой для расчёта ёмкости каждого члена: если у узла большая очередь (для сертификации или потока обработчика), то ёмкость для выполнения новых транзакций должна быть близка к тем, которые были сертифицированы или применены в последний период.

Наименьшая ёмкость всех членов группы определяет реальную ёмкость группы, а количество локальных транзакций определяет, сколько членов записывают в неё и, следовательно, с кем должна быть разделена доступная ёмкость.

Это означает, что каждый член имеет установленную квоту записи, основанную на доступной ёмкости, другими словами, количество транзакций, которые он может безопасно выполнить в следующий период. Квота на запись применяется механизмом ограничения, если размер очереди сертифицирующего узла или обработчика бинарного лога превышает заданный пользователем порог.

Квота уменьшается на количество транзакций, которые были задержаны в предыдущем периоде, а затем ещё уменьшается на 10%, чтобы дать очереди, которая вызвала проблему, возможность уменьшить свой размер. Для предотвращения больших скачков пропускной способности после того, как размер очереди превышает порог, пропускная способность увеличивается только на те же 10% за период.

Текущий механизм ограничения не накладывает штрафов на транзакции ниже квоты, но задерживает завершение транзакций, которые её превышают, до конца периода мониторинга. Вследствие этого, если квота очень мала для выпущенных запросов записи, некоторые транзакции могут иметь задержки, близкие к периоду мониторинга.