В случае, если демон поиска Manticore останавливается и в кластере не остается узлов для обработки запросов, необходимо выполнить восстановление. Из-за мульти-мастерной природы библиотеки Galera, используемой для репликации, кластер репликации Manticore представляет собой единый логический объект, который поддерживает согласованность своих узлов и данных, а также состояние всего кластера. Это позволяет безопасно проводить записи на нескольких узлах одновременно и обеспечивает целостность кластера.
Однако это также создает некоторые сложности. Рассмотрим несколько сценариев, используя кластер из узлов A, B и C, чтобы понять, что нужно делать, когда некоторые или все узлы становятся недоступными.
Когда узел A останавливается, другие узлы получают сообщение о «нормальном завершении работы». Размер кластера уменьшается, и происходит перерасчет кворума.
При запуске узел A присоединяется к кластеру и не будет обслуживать операции записи, пока полностью не синхронизируется с кластером. Если кэш набора транзакций на узлах-доноров B или C (который можно контролировать параметром Galera кластера gcache.size) по-прежнему содержит все транзакции, пропущенные узлом A, узел A получит быстрый инкрементальный перенос состояния (IST), то есть передачу только пропущенных транзакций. В противном случае произойдет перенос состояния снимка (SST), который включает передачу файлов таблиц.
В случае остановки узлов A и B размер кластера сокращается до одного, узел C формирует основную компоненту и обрабатывает операции записи.
Затем узлы A и B могут быть запущены как обычно и присоединятся к кластеру после старта. Узел C выступает в качестве донора, предоставляя перенос состояния узлам A и B.
Все узлы остановлены, кластер выключен.
Проблема теперь заключается в том, как инициализировать кластер. Важно, чтобы при корректном завершении работы searchd узлы записывали номер последней выполненной транзакции в директорию кластера в файл grastate.dat вместе с флагом safe_to_bootstrap. Узел, который был остановлен последним, будет иметь опцию safe_to_bootstrap: 1 и самый продвинутый номер seqno.
Важным является, чтобы этот узел запускался первым для формирования кластера. Для инициализации кластера сервер на этом узле должен быть запущен с флагом --new-cluster. В Linux также можно запустить manticore_new_cluster, который стартует Manticore в режиме --new-cluster через systemd.
Если сначала запускается другой узел, который инициализирует кластер, то наиболее продвинутый узел присоединится к этому кластеру, выполнит полную SST и получит файлы таблиц, в которых некоторые транзакции отсутствуют по сравнению с теми файлами таблиц, которые он имел ранее. Поэтому важно запускать в первую очередь узел, который был остановлен последним, и у которого в файле grastate.dat установлен флаг safe_to_bootstrap: 1.
В случае сбоя или сетевого отказа, из-за которого узел A исчезает из кластера, узлы B и C попытаются переподключиться к узлу A. При неудаче они удалят узел A из кластера. С двумя из трех узлов, которые продолжают работу, кластер сохраняет кворум и продолжает функционировать нормально.
При перезапуске узел A автоматически присоединится к кластеру, как описано в Случае 1.
Узлы A и B вышли из строя. Узел C не может самостоятельно сформировать кворум, поскольку 1 узел меньше половины от общего числа узлов (3). В результате кластер на узле C переходит в состояние non-primary и отклоняет операции записи с сообщением об ошибке.
Тем временем узел C ожидает подключения других узлов и также пытается к ним подключиться. Если это произойдет, восстанавливается сеть, и узлы A и B снова в сети, кластер автоматически восстановится. Если узлы A и B просто временно отключены от узла C, но могут общаться друг с другом, они продолжат работу в нормальном режиме, так как они продолжают образовывать кворум.
Однако если оба узла A и B вышли из строя или перезапустились из-за отключения питания, кому-то нужно активировать основную компоненту на узле C с помощью следующей команды:
- SQL
- JSON
SET CLUSTER posts GLOBAL 'pc.bootstrap' = 1Важным является то, что перед выполнением этой команды нужно убедиться, что другие узлы действительно недоступны. Иначе может произойти сценарий разделения мозга (split-brain), и сформируются отдельные кластеры.
Все узлы вышли из строя. В этой ситуации файл grastate.dat в директории кластера не был обновлен и не содержит корректный номер последовательности seqno.
Если это случается, необходимо найти узел с самыми свежими данными и запустить сервер на нем с использованием ключа командной строки --new-cluster-force. Все остальные узлы будут запущены как обычно, как описано в Случае 3).
В Linux также можно использовать команду manticore_new_cluster --force, которая запустит Manticore в режиме --new-cluster-force через systemd.
Разделение мозга может привести к переходу кластера в состояние без первичной реплики. Например, рассмотрим кластер, состоящий из четного числа узлов (четыре), таких как две пары узлов, расположенных в разных центрах обработки данных. Если сбой сети прерывает соединение между центрами обработки данных, происходит разделение мозга, поскольку каждая группа узлов удерживает ровно половину кворума. В результате обе группы перестают обрабатывать транзакции записи, поскольку модель репликации Galera отдает приоритет согласованности данных, и кластер не может принимать транзакции записи без кворума. Однако узлы в обеих группах пытаются переподключиться к узлам из другой группы, чтобы восстановить кластер.
Если кто-то хочет восстановить кластер до восстановления сети, следует предпринять те же шаги, что описаны в Случае 5, но только в одной группе узлов.
После выполнения оператора группа с узлом, на котором он был выполнен, снова сможет обрабатывать транзакции записи.
- SQL
- JSON
SET CLUSTER posts GLOBAL 'pc.bootstrap' = 1Однако важно отметить, что если оператор будет выполнен в обеих группах, это приведет к образованию двух отдельных кластеров, и последующее восстановление сети не приведет к повторному объединению групп.