Статья подготовлена для студентов курса «Администратор Linux» в образовательном проекте OTUS.
Одно из определений кластера гласит: «Кластер это группа серверов, объединённых логически, способных обрабатывать идентичные запросы и использующихся как единый ресурс». Это значит, что мы объединяем несколько sql-серверов в единую структуру, которая функционирует, как единое целое. Схем построений кластера существует множество, каждая из которых имеет свои преимущества и недостатки.
Можно выделить несколько основных преимуществ кластера: 1. Отказоустойчивость. Если в нашем кластере 5 нод, то мы вполне можем продолжать работать даже на 3х нодах; 2. Сохранность данных. Хотя бы одна нода будет содержать максимально актуальную версию данных. Потеря данных всё ещё возможна, но при этом мы потеряем данные не от момента сбоя до последней резервной копии, а только некоторую разницу в данных между моментом сбоя и нормальным состоянием.
Стоит отметить, что само резервное копирование по-прежнему необходимо, так как только оно спасёт нас от порчи/искажения данных случайно или преднамеренно.
Схемы кластеров
Имеются следующие схемы построения кластеров:
1. Мастер-слейв. В данном случае мы можем читать с любой ноды, но писать только на одну.
2. Мультимастер (мастер-мастер). В данном случае возможны чтение/запись на любую ноду.
В ряде случаев между приложением (сервисом) ставится прокси (HAProxy, ProxySQL). Их наличие позволяет балансировать нагрузку, кешировать запросы, реализовывать отказоустойчивость.
Percona XtraDB Cluster with ProxySQL
Данный кластер представляет собой несколько нод в мульти-мастер режиме. Подключение к ним осуществляется через ProxySQL-сервер, который является высокопроизводительным SQL-прокси.
Данная схема даёт нам ряд преимуществ:
— кеширование запросов;
— маршрутизация запросов;
— поддержка отказоустойчивости;
— изменение настроек на лету без простоя.
Подготовка и запуск
В одном из проектов возникла необходимость в MySQL-кластере. За основу был взят Percona XtraDB Cluster, который будет запускаться в Docker’е. Имеющийся в Docker Hub официальный image состоит из трёх контейнеров (нода в терминах Percon’ы): где запущена сама Percona, контейнер с Discovery-сервисом и контейнер с ProxySQL, к которому и будет подключаться приложение.
В боевых условиях у нас возможно появление новых нод или уменьшение их количества ниже некоторого критического, поэтому нам необходимо отслеживать состояние нашего кластера.
Для запуска контейнеров перкона кластера воспользуемся образами из официального докер-хаба: percona/percona-xtradb-cluster:5.7
Ещё для запуска нашего кластера нам потребуется Discovery-сервис, в котором будет храниться информация о доступных на текущий момент нодах. Для этого воспользуемся etcd, который представляет собой легковесное хранилище вида «Key-Value». Его мы так же возьмём из официального образа: quay.io/coreos/etcd
И третий необходимый образ это ProxySQL: perconalab/proxysql
В скрипты, находящиеся в этом образе, нам и необходимо внести изменения. Данные изменения должны решать следующие задачи:
1. ожидание готовности самого ProxySQL;
2. автоматическое добавление нод;
3. мониторинг количества нод.
Клонируем официальный репозиторий. В нём содержатся файлы:
— Dockerfile: конфигурация контейнера
— proxysql-entry.sh: файл, стартуемый при запуске контейнера
— add_cluster_nodes.sh: добавление ноды в кластер
— proxysql.cnf: конфигурация proxysql
— start-node.sh: старт контейнера proxysql
Изменяем proxysql-entry.sh
добавляем запуск скрипта добавления нод:
Изменяем add_cluster_nodes.sh
Добавим функцию ожидания готовности самого ProxySQL:
И добавим функцию ожидания Discovery-сервиса:
Необходимо заметить, что эта функция, помимо ожидания готовности, возвращает количество зарегистрированных нод на сервисе. Таким образом скрипт add_cluster_nodes.sh примет вид:
Через переменные окружения NODE_COUNT и REFRESH_INTERVAL выставляется минимальное количество нод в кластере и периодичность обновления состояния.
Настраиваем развертывание
Финальный версия percona-cluster.yml, который представляет собой docker-compose-файл, будет выглядеть следующим образом:
При помощи опции volume произведена замена скриптов в контейнере без его пересоздания. Сеть galera используется для связи между нодами, прокси и discovery-сервисом. Через env-файлы передаются необходимые параметры для каждого сервиса: пароль и имя пользователя на подключение к базе данных, имя discovery-сервиса, количество нод, период обновления, имя кластера. Подробнее можно увидеть в примере по ссылке ниже.
Для запуска нашего кластера необходим предварительно созданный swarm-кластер. На leader-node выполняем docker stack deploy -c percona-cluster.yml percona и через некоторое время наш кластер готов к работе.
Полный пример можно найти по ссылке.
Есть вопрос? Напишите в комментариях!
Материал подготовлен для студентов курса «Администратор Linux» в образовательном проекте OTUS. Чтобы присоединиться к ближайшей группе, обязательно пройдите вступительное тестирование:
ПРОЙТИ ТЕСТИРОВАНИЕ