Принципы работы кластера Galera для MySQL и управление кластером с помощью ClusterControl

В данном руководстве предоставляется основная информация о высокодоступном кластере Galera для MySQL/MariaDB. Прочитав статью до конца, вы узнаете ответы на вопросы:

  • как работает Galera Cluster;
  • чем репликация Galera Cluster отличается от репликации MySQL;
  • какие настройки рекомендованы для кластера Galera;
  • какими преимуществами и недостатками обладает Galera Cluster;
  • какие преимущества есть в объединении обоих способов репликации в рамках одного развертывания;
  • какие существуют различия в реализациях Galera у различных поставщиков;
  • как управлять кластером Galera;
  • какие стратегии резервного копирования необходимо использовать при использовании Galera.

Также, в статье вы найдете практический раздел о том, как быстро развернуть и управлять кластером с помощью ClusterControl. Для выполнения практической части статьи вам понадобится 4 сервера под управлением Ubuntu Linux 16.04 и новее, или CentOS 7.

Статья является переводом и адаптацией англоязычного руководства от Severalnines — разработчика инструмента ClusterControl.


Что такое Galera Cluster

Galera Cluster — это плагин к InnoDB, благодаря которому возможно создание синхронного мульти-мастер кластера MySQL. Он принципиально отличается от стандартной репликации MySQL и решает ряд проблем, включая конфликты при записи на нескольких узлах Master, проблему с отставанием репликации, которая ведет к рассинхронизации ведомых узлов с мастером. При использовании Galera, пользователям нет необходимости знать, на какой сервер будет производиться запись (Master), а с каких серверов можно будет читать (Slave), поскольку Galera предоставляет равнодоступный, как для записи, так и для чтения, кластер.

В кластере Galera приложение может выполнять запись на любой узел, а фиксации транзакций, или событий репликации на основе строк (RBR), применяются ко всем серверам посредством репликации на основе сертификации. Репликация на основе сертификации — это альтернативный подход к синхронной репликации базы данных с использованием методов группового взаимодействия и упорядочивания транзакций.

Минимальный кластер Galera состоит из 3 узлов. Рекомендуется запускать кластер с нечетным количеством узлов, чтобы при возникновении проблем с применением транзакции на одном узле (например, из-за проблемы с сетью, или когда машина не отвечает на запросы), два других узла могли создать кворум (т.е. большинство) и продолжить выполнение транзакции.

Плагин Galera был разработан компанией Codership Oy в качестве патча для стандартного MySQL. Существует 3 варианта реализации Galera:

  • MySQL Galera Cluster от Codership Oy,
  • Percona XtraDB Cluster от Percona,
  • MariaDB Galera Cluster (5.X и 10.X) от MariaDB.

Начиная с MariaDB Server 10.1, Galera входит в стандартную поставку сервера. Для включения кластера Galera достаточно активировать правильные параметры конфигурации.

Отличия репликации MySQL от кластера Galera

Следующая диаграмма иллюстрирует некоторые высокоуровневые различия между репликациями MySQL и Galera Cluster:

Репликация MySQL

Для реализации репликации в MySQL используется 3 потока, один на master и два на slave-узлах для каждого соединения master-slave:

  • Поток Binlog Dump. Узел Master создает поток для отправки содержимого бинарного журнала на узел Slave. Этот поток может быть идентифицирован в выводе команды SHOW PROCESSLIST на узле Master как поток Binlog Dump.
  • Поток ввода-вывода на узле Slave. Узел Slave создает поток ввода-вывода, который подключается к Master и просит его отправить обновления, записанные в его бинарных журналах. Поток ввода/вывода узла Slave считывает обновления, которые отсылает Binlog Dump, и копирует их журналы передачи (relay log).
  • Поток SQL на узле slave. Slave создает поток SQL для чтения журналов передачи и выполнения содержащихся в них обновлений.

Репликация MySQL является частью стандартного сервера MySQL и является асинхронной по своей природе. Обновления всегда выполняются на одном узле Master, затем распространяются на узлы Slave. Возможно создать кольцевую топологию с несколькими узлами Master, однако этот дизайн не является рекомендованным, так как серверы могут легко выйти из синхронизации в случае отказа одного из серверов. Введение GTID в MySQL 5.6 и более поздних версиях упрощает управление потоком данных репликации и, в частности, операциями переключения при отказе, однако автоматического переключения при отказе или повторной синхронизации не предусмотрено.

Репликация в Galera Cluster

Кластер Galera осуществляет репликацию, используя 4 компонента:

  • Сервер СУБД. Cервер базы данных, который работает на каждом узле. Поддерживаемые серверы СУБД — MySQL Server, Percona Server для MySQL и MariaDB Server.
  • WSRep API. API и набор обязанностей для сервера базы данных и поставщика репликации. Он обеспечивает интеграцию репликации с ядром СУБД.
  • Galera Plugin. Расширение, которое обеспечивает работу службы репликации.
  • Плагины групповой коммуникации. Различные системы групповой коммуникации, доступные для Galera Cluster.

Поставщик, который встраивает технологию Galera Cluster в движок СУБД, должен включить в кодовую базу сервера СУБД патч WriteSet Replication (WSRep). Это позволит расширению Galera, работающему в качестве провайдера WSRep, взаимодействовать и реплицировать транзакции (наборы записей или write-set’ы в терминах Galera) посредством протокола групповой связи, что обеспечивает работу синхронной мульти-мастер репликации для InnoDB. В результате транзакции выполняются синхронно на всех узлах.

Если любоий из узлов вышел из строя, другие узлы будут продолжать работать и отслеживать изменения данных. Когда узел восстанавливается, перед возвращением в кластер он автоматически синхронизируется с другими узлами посредством передачи снимка состояния (SST) или инкрементной передачи состояния (IST) в зависимости от последнего известного состояния. При сбое любого из узлов данные не теряются.

Кластер Galera использует репликацию на основе сертификации, то есть форму синхронной репликации с уменьшенными вычислительными затратами.

Репликация, основанная на сертификации

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

Предварительные условия для репликации на основе сертификации следующие:

  • СУБД с поддержкой транзакций. Возможность откатывать незафиксированные изменения.
  • Поддержка Атомарных изменений. События репликации должны изменять базу данных атомарно.
  • Глобальное упорядочивание. События репликации должны применяться ко всем экземплярам в одном и том же порядке.

Основная идея репликации на основе сертификации заключается в том, что транзакция выполняется условно до точки фиксации, при условии отсутствия конфликтов. Это называется оптимистичным исполнением. Когда клиент выполняет команду COMMIT, но до того, как произойдет фактическое выполнение (commit), все изменения, внесенные в базу данных транзакцией, и первичные ключи измененных строк собираются в набор write-set. Затем этот набор записей реплицируется на остальные узлы, после чего он проходит детерминированный сертификационный тест с использованием собранных первичных ключей на каждом узле, включая узел, инициировавший write-set. Это определяет, может ли write-set применяться на узле или нет.

Если сертификационный тест не пройден, write-set отбрасывается, а исходная транзакция откатывается. Если тест пройден успешно, транзакция фиксируется, и write-set применяется к остальным узлам.

Сертификационный тест, реализованный в Galera, зависит от глобального порядка транзакций. Во время репликации каждой транзакции присваивается глобальный порядковый номер. Таким образом, когда транзакция достигает точки фиксации (commit), узел сверяет порядковый номер с номером последней успешной транзакции. Интервал между этими двумя значениями считается неопределенным, так как транзакции в пределах этого интервала не видели влияния друг друга. Поэтому все транзакции в этом интервале проверяются на конфликты первичных ключей с проверяемой транзакцией. При обнаружении конфликтов считается, что сертификационный тест не прошел.

Поскольку процедура является детерминированной, и все реплики получают транзакции в одном и том же порядке, все узлы принимают одинаковое решение о результате транзакции. Это позволяет узлу, инициировавшему транзакцию, уведомить клиентское приложение о выполнении транзакции.

Репликация на основе сертификации (или, точнее, разрешение конфликтов на основе сертификации) основана на академических исследованиях, в частности, на докторской диссертации Фернандо Педоне.

Полюсы и минусы использования Galera

Galera имеет ряд преимуществ:

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

Как и любое решение, Galera имеет некоторые ограничения:

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

Больше информации о репликации в кластере Galera можно найти в следующих ресурсах на английском языке:

Развертывание кластера Galera Cluster

Если вы хотите развернуть кластер Galera вручную без использования ClusterControl, обратитесь к нашей статье на эту тему.

Кластер Galera можно легко развернуть с помощью ClusterControl. Мы будем разворачивать кластер на трех рабочих и одном управляющем узле:

Установите ClusterControl на отдельном узле, следуя инструкциям официальной документации. Настройте доступ по SSH без пароля от ClusterControl ко всем узлам, включая сам узел ClusterControl.

Мы будем разворачивать кластер от имени пользователя root. От его имени запустим следующие команды на узле ClusterControl:

ssh-keygen -t rsa
ssh-copy-id 192.168.10.100 # clustercontrol
ssh-copy-id 192.168.10.101 # galera1
ssh-copy-id 192.168.10.102 # galera2
ssh-copy-id 192.168.10.103 # galera3

После установки откройте пользовательский интерфейс ClusterControl, перейдите в раздел «Deploy Database Cluster» и откройте вкладку «MySQL Galera». В диалоговом окне вы увидите два шага, как показано на изображениях ниже.

Развертывание кластера

Общие настройки и параметры SSH

В разделе «General & SSH Settings» укажите необходимую информацию:

  • SSH User — укажите пользователя SSH, который будет использоваться для подключения к целевому хосту.
  • SSH Key Path — для доступа без пароля по SSH нужен ключ SSH. Укажите здесь физический путь к файлу ключа.
  • Sudo Password — пароль sudo, если пользователь sudo использует пароль для повышения прав доступа. В противном случае оставьте это поле пустым.
  • SSH Port Number — не требует пояснений. По умолчанию 22.
  • Cluster Name — имя кластера, который будет развернут.

Не меняйте флажки, заданные по умолчанию, чтобы ClusterControl установил программное обеспечение и соответствующим образом настроил параметры безопасности. Если вы хотите сохранить настройки брандмауэра на каждом из узлов, снимите флажок «Отключить брандмауэр», однако до начала развертывания убедитесь, что связанные с MySQL порты открыты, как требуется согласно разделу документации.

Выбор поставки и определение узлов кластера

Перейдите в следующую вкладку и определите параметры установки и настройки MySQL Server:

  • Vendor — поставщик. В настоящее время поддерживаются поставщики Percona Server, MariaDB и Codership.
  • Version — основная версия MySQL. Рекомендуется версия 5.7 (Codership/Percona) или 10.1 (MariaDB).
  • Server Data Directory — физическое местоположение каталога данных MySQL. По умолчанию это /var/lib/mysql.
  • Server Port — порт сервера MySQL. По умолчанию 3306.
  • my.cnf Template — шаблон конфигурации MySQL. Не меняйте его, тогда будет использоваться шаблон по умолчанию, расположенный в /usr/share/cmon/templates.
  • Root Password — пароль root для MySQL. ClusterControl настроит его за вас.
  • Repository — репозиторий. Рекомендуется выбрать значение по умолчанию, если только вы не хотите использовать ваши репозитории. Также можно выбрать «Create New Repository», чтобы создать и зеркалировать репозиторий текущего поставщика базы данных, а затем с помощью локального зеркального репозитория развернуть его.
  • Add Node — укажите IP-адрес или имя хоста целевых хостов. ClusterControl должен иметь доступ к указанному серверу по SSH без пароля.

Нажмите Deploy, и ClusterControl выполнит подготовку, установку, конфигурирование кластера и настроит мониторинг его состояния. После завершения развертывания на панели мониторинга ClusterControl появится созданный кластер базы данных.

Горизонтальное масштабирование

Процесс добавления нового узла к кластеру Galera происходит автоматически, аналогично процессу восстановления неисправного узла. Ожидается, что добавленный узел пуст, поэтому на этом этапе Galera выполняет полную передачу снимка состояния (SST) от определенного узла-донора.

Добавить новый узел Galera с помощью ClusterControl очень просто. Достаточно настроить доступ по SSH без пароля к целевому узлу, а затем перейти в раздел ClusterControl > Cluster Actions > Add Node > Create and add a new DB Node:

Если используется балансировщик нагрузки, можно для опции «Include in LoadBalancer set» задать значение true, чтобы ClusterControl автоматически добавил его в выбранный балансировщик нагрузки.

Удаление узлов из кластера

Удаление узлов из кластера тоже выполняется просто. Для этого достаточно удалить соответствующий узел базы данных из кластера Galera через пользовательский интерфейс ClusterControl, кликнув «X» в разделе «Nodes». Если вывод узла из эксплуатации производится корректно и узел Galera останавливается, он помечается как корректно удаленный из кластера. Затем ClusterControl удаляет узел из балансировщика нагрузки (если он используется) и соответствующим образом обновляет переменную wsrep_cluster_address на доступных узлах.

Присоединение slave-узла для асинхронной репликации

Распространенным решением при использовани кластера Galera является подключение к нему узла Slave для асинхронной репликации данных. Это может быть необходимо по нескольким причинам. Одна из них в том, что долго выполняющиеся аналитические запросы на узле Galera могут замедлить работу всего кластера, если узлу приходится тратить значительные усилия для интенсивной обработки большого объема данных. При использовании узла Slave, тяжелые запросы могут быть отправлены на отдельный сервер, тем самым эффективно снимая нагрузку с Galera. Асинхронный узел Slave также можно использовать для резервного копирования без влияния на производительность кластера Galera.

Чтобы добавить новый узел Slave, выполните следующие шаги:

  1. Включите ведение бинарного журнала на выбранном узле Galera (Master). Перейдите в ClusterControl > Nodes > choose the Galera node > Node Actions > Enable Binary Logging. Перезапустите сервер MySQL на данном узле. Если нужно несколько узлов master, повторите этот шаг для остальных узлов Galera.
  2. Настройте доступ по SSH без пароля на узел Slave.
  3. Перейдите в ClusterControl > Cluster Actions > Add a Replication Slave > New Replication Slave и укажите необходимую информацию: IP-адрес/имя хоста узла slave, правильно укажите master и порт потоковой передачи данных.

Также, можно настроить отстающий узел slave, указав количество времени в секундах. Подробно об этом читайте в статье «Как настроить асинхронную репликацию из кластера Galera на автономный сервер MySQL с GTID».

Доступ к Galera Cluster

На этом этапе наш кластер Galera должен быть настроен. Следующим шагом является импорт существующей базы данных или создание новой базы данных для нового приложения. Кластер Galera поддерживает стандартный интерфейс MySQL. Следовательно, большинство существующих библиотек и коннекторов MySQL с ним совместимы. Однако при подключении к кластеру есть некоторые аспекты, которые следует учитывать. Подробнее об этом в следующем разделе.

Непосредственный доступ приложений к кластеру

Когда сервер MySQL в Galera Cluster запущен, это еще не означает, что он действительно работает. Возьмем пример, когда узлы Galera разделены. В течение этого времени значение wsrep_cluster_state будет передаваться как Non-Primary. Обратите внимание, что только кластер с состоянием Primary является работоспособным. Однако, даже на нерабочем кластере возможно подключиться к серверу MySQL и выполнить ряд команд, таких как SHOW и SET. Имейте в виду, что операторы DML, такие как SELECT, INSERT и UPDATE, на этом этапе работать не будут.

При выполнении мониторинга состояния здоровья кластера, необходимо ориентироваться на три переменных, значения которых должны соответствовать приведенным ниже:

wsrep_cluster_state: Primary
wsrep_local_state_comment: Synced
wsrep_ready: On

Значения данных переменных можно проверить с помощью SHOW GLOBAL STATUS LIKE 'wsrep_%';.

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

Доступ с помощью обратного прокси-сервера

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

Обратный прокси-сервер или балансировщик нагрузки обычно размещается перед узлами Galera и перенаправляет запросы клиентов на соответствующий внутренний сервер. Эта конфигурация упрощает работу с несколькими узлами master в MySQL, эффективно распределяет соединения MySQL и делает сервис MySQL более устойчивым к сбоям.

Приложения просто отправляют запросы на сервер балансировки нагрузки, откуда они перенаправляются на соответствующие части сервера. На стороне приложения не нужно проверять работоспособность кластера и доступность базы данных, поскольку эти задачи берет на себя обратный прокси-сервер.

При добавлении обратного прокси архитектура будет выглядеть следующим образом:

ClusterControl поддерживает установку HAProxy, ProxySQL и MariaDB MaxScale.

Использование HAProxy

Работа HAProxy в качестве балансировщика нагрузки MySQL выполняется на транспортном уровне модели TCP/IP. HAProxy не понимает запросы MySQL, которые он распространяет на внутренние серверы MySQL, поскольку они работают на прикладном уровне.

При использовании HAproxy совместно с кластером Galera требуется внешний скрипт mysqlchk, размещенный на узле базы данных. Этот скрипт проверки состояния будет передавать информацию о состоянии базы данных через код состояния HTTP на порту 9200. ClusterControl установит данный скрипт на выбранных узлах кластера Galera автоматически.

Чтобы настроить доступ к кластеру Galera через HAProxy, перейдите в раздел Manage > Load Balancer > HAProxy > Deploy HAProxy. На изображении ниже показаны данные экземпляра HAProxy:

Теперь приложения могут отправлять запросы к MySQL через порт 3307, используя узлы, на которых развернуты балансировщики. Более подробно читайте в руководстве по балансировке нагрузки MySQL с помощью HAProxy.

Использование ProxySQL

ProxySQL — это новый прокси-сервер MySQL с открытым исходным кодом, распространяемый под лицензией GPL. Он служит посредником между сервером MySQL и приложениями, которые обращаются к базам данных. Он принимает входящий трафик от клиентов MySQL и перенаправляет его на серверы MySQL. Он поддерживает различные топологии MySQL, а также маршрутизацию запросов (например, разделение на чтение/запись), разбиением, перезаписью, зеркалированием запросов, пул соединений и многое другое.

Чтобы развернуть экземпляр ProxySQL, просто перейдите в Manage > Load Balancer > ProxySQL > Deploy ProxySQL и укажите необходимую информацию. Выберите серверы, которые будут входить в группу балансировки нагрузки, и для каждого из них укажите максимальную задержку репликации. ClusterControl настроит две группы хостов для кластера Galera: одну в режиме мульти-мастер, а другую в режиме выделенного мастера. По умолчанию все запросы будут перенаправляться в Hostgroup 10 (пул с выделенным мастером). При необходимости маршрутизацию запросов можно настроить позднее в разделе Query Rules.

Когда сервер развернут, необходимо настроить соединения клиентов с MySQL через узлы балансировщика на порту 6033. Изображение ниже показывает группу хостов с одним узлом master (Hostgroup 10):

Использование MariaDB MaxScale

MariaDB MaxScale является прокси для MySQL, который позволяет перенаправить команды базы данных на один или более серверов базы данных MySQL/MariaDB. Последняя версия MaxScale 2.0 поставляется под лицензией MariaDB BSL, по которой MaxScale может бесплатно использоваться только для конфигураций, включающих не более трёх серверов. ClusterControl устанавливает MaxScale 1.4, который можно бесплатно использовать для конфигураций с неограниченным количеством серверов.

Поддержка других балансировщиков

Severalnines создали скрипт проверки работоспособности под названием clustercheck-iptables, который можно использовать с другими балансировщиками нагрузки, такими как nginx, IPVS, Keepalived и Pen. Этот фоновый скрипт проверяет доступность узла Galera и открывает доступ к порту СУБД, используя iptables, если узел Galera исправен. Это позволяет балансировщикам нагрузки с ограниченными возможностями правильно обслуживать трафик клиентов только на доступных узлах кластера Galera.

Использование виртуального IP с помощью Keepalived

Keepalived используется для предоставления виртуального IP-адреса, который динамически переносится между узлами при возникновении ситуации отказа (Virtual Router Redundancy Protocol). В случае сбоя основного узла виртуальный IP-адрес будет автоматичеки переназначен резервному узлу балансировки нагрузки. Как только основной балансировщик нагрузки восстанавливается, плавающий IP-адрес возвращается к нему.

Развернуть экземпляр Keepalived можете через ClusterControl > Manage > Load Balancer > Keepalived > Deploy Keepalived. Требуется как минимум два узла для выполнения Keepalived, находящихся под управлением ClusterControl.

Обработка ошибок Galera с помощью ClusterControl

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

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

ClusterControl перезапускает процесс базы данных, завершившийся ошибкой, и восстанавливает его состояние с помощью одного из существующих узлов. Galera обрабатывает процесс ресинхронизации с помощью передачи состояния снимка (SST) либо инкрементной передачи снимка (IST).

Во время повторной синхронизации отказавшего узла любые новые транзакции (write-set’ы), поступающие от существующих узлов, будут буферизироваться в очереди. Как только узел восстанавливается, он считается синхронизированным и готов принимать клиентские соединения.

Больше информации о том, как восстановить кластеры MySQL и MariaDB, представлено в вебинаре по ссылке.

Операции: управление кластером Galera

Резервное копирование

ClusterControl поддерживает два инструмента резервного копирования — Mysqldump и Xtrabackup (полное и инкрементное). Резервное копирование может выполняться на любом узле базы данных, храниться локально или централизованно на узле ClusterControl. При хранении резервных копий на узле ClusterControl, резервная копия сначала создается на целевом узле базы данных, а затем передается на узел ClusterControl. Можно выполнить резервное копирование отдельных или всех баз данных. Также доступно отслеживание процесса копирования с возможностью получения уведомлений о состоянии резервного копирования при создании каждой копии.

Чтобы создать резервную копию, перейдите в Backup > Create Backup и укажите необходимые данные:

Чтобы установить расписание для создания копий, нажмите Schedule Backup и задайте нужные настройки:

Резервные копии, созданные через ClusterControl, можно восстановить на одном из узлов базы данных.

Восстановление из резервной копии

ClusterControl дает возможность восстанавливать резервные копии данных в форматах Mysqldump и Xtrabackup, созданные с помощью ClusterControl или с помощью другого инструмента. Файлы резервных копий должны находиться на узле ClusterControl, поддерживаются только расширения xbstream, xbstream.gz и tar.gz.

Все инкрементные резервные копии автоматически группируются вместе с последней полной резервной копией, их можно просмотреть в раскрывающемся списке. Для каждой резервной копии есть кнопки Restore и Log:

Чтобы восстановить резервную копию, просто нажмите Restore рядом. Появится мастер восстановления и пара опций:

Если резервное копирование выполнялась с помощью Percona Xtrabackup, кластер будет остановлен, и выполнятся следующие шаги:

  1. остановка всех узлов в установке Galera;
  2. копирование файлов резервной копии на выбранный сервер;
  3. восстановление резервной копии;
  4. после завершения восстановления ClusterControl загрузит восстановленный узел;
  5. используя загрузочный узел в качестве донора, ClusterControl запустит остальные узлы.

Обновления

Вы можете выполнить обновление программного обеспечения базы данных через ClusterControl > Manage > Upgrades > Upgrade. Обновления происходят онлайн, за один раз выполняется обновление ПО на одном узле. Узел останавливается, затем через менеджер пакетов программное обеспечение обновляется и, наконец, узел снова запускается. Если не удается обновить узел, процесс обновления прерывается. Обновления должны выполняться в периоды наименьшей нагрузки на серверы.

ClusterControl обновляет узлы Galera Cluster последовательно. После завершения задания проверьте правильность новой версии во вкладке «Cluster Overview».

Управление конфигурациями

Системные переменные находятся в my.cnf. Некоторые из переменных являются динамическими и могут установливаться во время выполнения, другие нет. ClusterControl предоставляет интерфейс для обновления параметров конфигурации MySQL сразу на всех экземплярах БД. Выберите экземпляр(ы) БД, группу конфигурации и параметр, и ClusterControl выполнит необходимые изменения с помощью SET GLOBAL (если это возможно), а также сделает его постоянным в my.cnf.

Если требуется перезагрузка, ClusterControl подтвердит это в диалоговом окне Config Change Log:

Больше информации можно найти в статье Обновление конфигурации MySQL.

Обновление схемы онлайн

Любой оператор DDL, который выполняется в базе данных, например, CREATE TABLE, ALTER TABLE или GRANT, обновляет схему. Изменение схемы в MySQL блокирующая операция — таблицу необходимо заблокировать на время изменений. В Galera Cluster есть два способа внесения изменений в схему в режиме онлайн (OSU):

  • Total Order Isolation (TOI);
  • Rolling Schema Upgrade (RSU);

Оба способа, TOI и RSU, задаются с помощью переменной wsrep_osu_method.

Total Order Isolation (TOI)

Это значение используется по умолчанию для переменной wsrep_osu_method. Обновление схемы выполняется на всех узлах кластера в одной и той же последовательности, предотвращая выполнение других транзакций во время операции. При использовании Total Order Isolation запросы, которые обновляют схему, реплицируются как операторы на все узлы кластера. Узлы ожидают выполнения всех текущих транзакций, а затем одновременно выполняют обновление схемы. Во время обработки DDL другие транзакции блокируются.

Больше информации можно найти в статье об изменениях схемы с использованием TOI.

Rolling Schema Upgrade (RSU)

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

Больше информации можно найти в статье об изменениях схемы с использованием RSU.

Каждый способ обновления имеет свои преимущества и недостатки. Подробнее об этом читайте статью.

Общие вопросы о Galera Cluster

Причины сбоев в Galera

Чтобы избежать проблем, старайтесь не допускать реализации известных ограничений Galera.

Что происходит при полном заполнении диска?

Кластер Galera достаточно умный, чтобы исключить любой проблемный узел из кластера, если обнаруживается несогласованность среди участников кластера. Когда у mysqld заканчивается свободное место на диске (в каталоге данных), узел не может применять writeset’ы. Galera определяет такие транзакции как неудачные. Так как это нарушает согласованность узлов, Galera подает сигнал на закрытие группового соединения и принудительно завершает работу mysqld.

Перезапуск узла вызовет ошибки переполнения диска (например, «no space left on device») и ошибки превышения квоты (например, «write failed» или «user block limit reached»).

Что происходит при подкачке операционной системы?

Если операционная система начинает подкачку и/или если iowait очень высокий, ОС может «заморозить» сервер на время. В течение этого времени узел Galera может перестать отвечать на другие узлы и будет считаться мертвым. В виртуализированных средах подкачку может выполнять также хост-операционная система.

Что делать при сбое в Galera?

Прежде всего, убедитесь, что вы используете последнюю стабильную версию Galera, чтобы не сталкиваться с ошибками более ранних версий, которые уже были исправлены. Проверьте журнал ошибок MySQL на узлах Galera, поскольку Galera будет писать в этот файл. Найдите нужную строку, указывающую на ошибку или сбой. Если узлы Galera отвечают, также можно попытаться получить следующие выходные данные:

mysql> SHOW FULL PROCESSLIST; 
mysql> SHOW PROCESSLIST; 
mysql> SHOW ENGINE INNODB STATUS; 
mysql> SHOW STATUS LIKE 'wsrep%';

Затем проверьте системные ресурсы, в частности сеть, брандмауэр, использование ресурсов диска и памяти, а также общий журнал активности системы (syslog, message, dmesg). Если источник проблемы по-прежнему не обнаружен, сообщите об этом на странице Launchpad или запросите помощь непосредственно у службы технической поддержки поставщика (Codership, Percona или MariaDB). Также можно подписаться на рассылку Galera Google Group.

Примечание:

Если вы используете rsync для передачи состояния, и перед завершением передачи состояния происходит сбой узла, процесс rsync может зависнуть навсегда, занимая порт и не позволяя перезапустить узел. В журнале ошибок сервера проблема будет отображаться как ‘port in use’. Найдите потерянный процесс rsync и убейте его вручную.

Перед повторной инициализацией кластера можно определить, какой узел БД имеет наиболее обновленные данные, сравнив значение wsrep_last_commited среди узлов. Тот узел, у которого это значение больше, рекомендуется использовать в качестве эталонного узла при начальной загрузке кластера.

Что происходит, если в таблице нет первичных ключей?

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

Оператор DELETE FROM требует отключения PK или MySQL на узле будет завершен с ошибкой. Всегда явно определяйте первичный ключ во всех таблицах. Простого AUTO_INCREMENT для первичного ключа будет достаточно.

Правда ли, что MySQL Galera работает со скоростью самого медленного узла?

Да, это так. Работа Galera основывана на групповой коммуникации между узлами. Кластер ожидает, пока все узлы вернут статус сертификационного теста, прежде чем приступить к выполнению транзакции или откату. На этом этапе перегруженный узел будет отвечать с большой задержкой, что заставит остальную часть кластера работать медленно. Кроме того, время обработки транзакции не может быть короче, чем RTT (время прохождения пакета) до самого удаленного узла.

Можно ли использовать Galera для репликации между дата-центрами?

Хотя Galera Cluster является синхронным, его узлы могут быть развернуты в разных центрах обработки данных. Синхронная репликация, такая как MySQL Cluster (NDB), реализует выполнение транзакции в два этапа — на этапе «подготовки» всем узлам кластера отправляются одни сообщения, а на этапе «выполнения» отправляется другой набор сообщений. Этот подход обычно не подходит для географически разрозненных узлов, т.к. при отправке сообщений между узлами возникают задержки.

Galera Cluster использует репликацию на основе сертификации, то есть форму синхронной репликации с уменьшенными вычислительными затратами.

Почему нельзя использовать таблицы MyISAM?

MySQL Galera обрабатывает таблицы MyISAM совершенно по-другому:

  • Все DDL (create, drop, alter table…) на MyISAM будут реплицироваться;
  • DML (update, delete, insert) выполняющиеся только для таблиц MyISAM, реплицироваться не будут;
  • Транзакции, в которых происходит как обращение к InnoDB, так и к MyISAM, будут реплицироваться.

Таким образом, таблицы MyISAM находятся на всех узлах (поскольку DDL реплицируется). Если вы обращаетесь к таблицам MyISAM вне транзакций InnoDB, то все изменения данных в таблицах MyISAM останутся локально на каждом узле. Если вы обращаетесь к таблицам MyISAM внутри транзакций InnoDB, то изменения MyISAM реплицируются вместе с изменениями InnoDB. Однако, если возникают конфликты в кластере, изменения MyISAM нельзя будет отменить, и ваши таблицы MyISAM окажутся рассогласованы.