На прошлой неделе в Percona Live я представил шестичасовое руководство по Percona XtraDB Cluster (PXC) для MySQL. На самом деле у меня было больше материала, чем я покрывал (по замыслу), но я сожалею, что мы не охватили это управление потоком. Итак, я думал, что напишу пост, посвященный управлению потоками, потому что это важно понять.
Что такое управление потоком?
При переходе на Galera люди не ожидают, что механизм обратной связи будет существовать в отличие от всего, что вы найдете в стандартной асинхронной репликации MySQL. Я считаю, что отсутствие понимания этой системы или даже того, что она существует, приводит к ненужному разочарованию в Галере и кластерных «стойлах», которые можно предотвратить.
Эта обратная связь, называемая управлением потоком , позволяет любому узлу в кластере проинструктировать группу, когда ему необходимо приостановить репликацию и когда она будет готова к продолжению репликации. Это не позволяет любому узлу в группе синхронной репликации слишком сильно отставать от других при применении репликации.
Поначалу это может показаться нелогичным: как отстает синхронная репликация? Как я упоминал ранее , репликация Galera является синхронной с точки зрения обеспечения того, что транзакции копируются на все узлы и устанавливается глобальное упорядочение, но применение и принятие асинхронны на всех узлах, кроме узла, на котором выполняется транзакция.
Важно понимать, что Galera предотвращает конфликты с такими транзакциями, которые были сертифицированы, но еще не применены, поэтому многоузловая запись не приведет к несоответствиям, но это выходит за рамки этого поста.
Настройка потока управления
Управление потоком запускается, когда синхронизируемый узел превышает определенный порог относительно размера очереди приема (видимый через глобальную переменную состояния wsrep_local_recv_queue ). Донорные / Desynced узлы не применяют управление потоком, хотя они могут входить в состояния, где recv_queue существенно возрастает. Поэтому следует позаботиться о том, чтобы приложения не использовали донорские / десинцированные узлы, особенно при использовании блокирующего метода SST, такого как rsync или mysqldump.
Итак, управление потоком запускается, когда очередь recv становится слишком большой, но насколько она велика? И когда управление потоком ослаблено? Здесь есть несколько параметров, которые уместны, и все они настраиваются через глобальную переменную wsrep_provider_options .
gcs.fc_limit
Этот параметр определяет, когда включается управление потоком. Проще говоря, если wsrep_local_recv_queue превышает этот размер на данном узле, будет отправлено сообщение о приостановке потока. Тем не менее, это немного сложнее, из-за fc_master_slave (см. Ниже).
В fc_limit по умолчанию 16 сделок. Это фактически означает, что данный узел может быть за фиксацией транзакций из кластера.
gcs.fc_master_slave
Fc_limit изменяется динамически , если вы fc_master_slave отключены (который по умолчанию). Этот режим фактически настраивает fc_limit динамически в зависимости от количества узлов в кластере . Чем больше узлов в кластере, тем больше становится вычисляемое значение fc_limit . Теория, лежащая в основе этого, состоит в том, что чем больше кластер становится (и, вероятно, более загруженным с большим количеством записей, поступающих от большего количества узлов), тем больше свободы действий у каждого узла будет немного дальше после применения.
Если вы выполняете запись только в один узел в PXC, рекомендуется отключить эту функцию, установив fc_master_slave = YES. Несмотря на свое название, этот параметр действительно не более, чем изменить, если fc_limit динамически изменен размер или нет. Он не содержит никакой другой магии, которая помогает записи одного узла в PXC работать лучше.
gcs.fc_factor
Если fc_limit контролирует, когда управление потоком включено, то fc_factor обращается, когда оно освобождается. Коэффициент представляет собой число от 0,0 до 1,0, которое умножается на текущее значение fc_limit (скорректированное с помощью приведенного выше расчета, если fc_master_slave = NO). Это дает количество транзакций, которые очередь recv должна упасть НИЖЕ, прежде чем узел отправит другое сообщение управления потоком, дающее кластеру разрешение на продолжение репликации.
Этот параметр по умолчанию был равен 0,5, что означало, что очередь должна была упасть ниже 50% значения fc_limit, прежде чем репликация была возобновлена. Большой fc_limit в этом случае может означать долгое ожидание, прежде чем управление потоком снова ослабнет . Однако недавно он был изменен на значение по умолчанию 1,0, чтобы репликация могла возобновиться как можно скорее.
Пример настройки потока управления настройкой конфигурации в главном / подчиненном кластере может быть:
mysql> set global wsrep_provider_options="gcs.fc_limit=500; gcs.fc_master_slave=YES; gcs.fc_factor=1.0";
Работа с контролем потока
Что происходит во время контроля потока
Проще говоря: управление потоком останавливает репликацию и, следовательно, останавливает записи (которые являются синхронными) на всех узлах, пока управление потоком не будет ослаблено .
При нормальной работе мы ожидаем, что большая очередь приема может быть результатом некоторой краткой проблемы производительности на данном узле или, возможно, эффектом какой-то большой транзакции, кратковременно останавливающей поток приложения.
Тем не менее, можно остановить применение очереди на любом узле, просто запустив «FLUSH TABLES WITH READ LOCK» или, возможно, «LOCK TABLE», и в этом случае управление потоком сработает, как только будет превышено значение fc_limit . Поэтому следует позаботиться о том, чтобы ваше приложение или какая-либо другая операция обслуживания (например, резервное копирование) случайно не вызывала управление потоком в вашем кластере.
Стоимость увеличения fc_limit
Сохранение fc_limit small имеет две цели:
- Это ограничивает величину задержки, которую может иметь любой узел в кластере, применяя кластерные транзакции. Таким образом, он сохраняет последние чтения без необходимости использовать wsrep_causal_reads.
- Он сводит к минимуму расходы на сертификацию, сохраняя небольшой интервал между совершаемыми новыми транзакциями и самой старой непримененной транзакцией. Чем больше очередь, тем дороже обходится сертификация.
Поэтому в кластере «ведущий / ведомый» целесообразно увеличить fc_limit, потому что единственными запаздывающими узлами будут ведомые устройства без записей, поступающих с них. Однако при многоузловой записи большие очереди делают сертификацию более дорогой и, следовательно, отнимающей много времени.
Как определить, происходит ли управление потоком и откуда оно идет
Есть две глобальные переменные состояния, которые вы можете проверить, чтобы увидеть, что происходит управление потоком:
- wsrep_flow_control_paused — доля времени (из 1.0) с момента последнего SHOW GLOBAL STATUS, на которую влияет управление потоком, независимо от того, какой узел вызвал его. Вообще говоря, следует избегать всего, что выше 0,0.
- wsrep_flow_control_sent — количество сообщений управления потоком, отправленных локальным узлом в кластер. Это можно использовать для определения того, какой узел вызывает управление потоком.
Я настоятельно рекомендую отслеживать и составлять графики wsrep_flow_control_sent, чтобы вы могли определить, когда и когда происходит управление потоком и какие узлы (или узлы) вызывают его.
Используя myq_gadgets , я могу легко увидеть управление потоком, если я выполню FLUSH TABLES WITH READ LOCK на узле 3:
[root@node3 ~]# myq_status wsrep
Wsrep Cluster Node Queue Ops Bytes Flow Conflct
time name P cnf # name cmt sta Up Dn Up Dn Up Dn pau snt dst lcf bfa
09:22:17 myclu P 3 3 node3 Sync T/T 0 0 0 9 0 13K 0.0 0 101 0 0
09:22:18 myclu P 3 3 node3 Sync T/T 0 0 0 18 0 28K 0.0 0 108 0 0
09:22:19 myclu P 3 3 node3 Sync T/T 0 4 0 3 0 4.3K 0.0 0 109 0 0
09:22:20 myclu P 3 3 node3 Sync T/T 0 18 0 0 0 0 0.0 0 109 0 0
09:22:21 myclu P 3 3 node3 Sync T/T 0 27 0 0 0 0 0.0 0 109 0 0
09:22:22 myclu P 3 3 node3 Sync T/T 0 29 0 0 0 0 0.9 1 109 0 0
09:22:23 myclu P 3 3 node3 Sync T/T 0 29 0 0 0 0 1.0 0 109 0 0
09:22:24 myclu P 3 3 node3 Sync T/T 0 29 0 0 0 0 1.0 0 109 0 0
09:22:25 myclu P 3 3 node3 Sync T/T 0 29 0 0 0 0 1.0 0 109 0 0
09:22:26 myclu P 3 3 node3 Sync T/T 0 29 0 0 0 0 1.0 0 109 0 0
09:22:27 myclu P 3 3 node3 Sync T/T 0 29 0 0 0 0 1.0 0 109 0 0
09:22:20 myclu P 3 3 node3 Sync T/T 0 29 0 0 0 0 1.0 0 109 0 0
09:22:21 myclu P 3 3 node3 Sync T/T 0 29 0 0 0 0 1.0 0 109 0 0
09:22:22 myclu P 3 3 node3 Sync T/T 0 29 0 0 0 0 1.0 0 109 0 0
Обратите внимание, что очередь узла 3 заполняется, она отправляет 1 сообщение управления потоком (для приостановки), а затем управление потоком находится в состоянии паузы 100% времени. Мы можем сказать, что управление потоком пришло с этого узла, потому что «Flow snt» показывает сообщение, отправленное, как только управление потоком включено
Контроль потока и передача государственного пожертвования
Донорские узлы не должны вызывать управление потоком, потому что они перемещены из Синхронизированного в Донорное / Десинсированное состояние. Доноры в этом состоянии будут продолжать применять репликацию так, как им разрешено, но будут создавать большую очередь репликации без управления потоком, если они заблокированы основным методом SST, т. Е. FLUSH TABLES WITH READ LOCK.