Высокая доступность и устойчивость баз данных с MaxScale

Учебники
MariaDB

Приложения, критически важные для миссии, требуют высокой доступности. Цель высокой доступности — обеспечить пользователям постоянный доступ к услугам или ресурсам, минимизируя вероятность прерывания. Автоматическое переключение в случае сбоя — это конкретный механизм, используемый для достижения высокой доступности. Он включает автоматическое обнаружение сбоя компонента системы (например, сервера, сети или базы данных) и мгновенное переключение операций на резервный компонент без вмешательства человека. Это повышает устойчивость.

MariaDB MaxScale — это прокси-сервер для баз данных, включающий функции для обеспечения высокой доступности. В этой статье я покажу вам, как можно испытать его с помощью симулятора онлайн-магазина, реализованного на Java и Svelte.

Архитектура

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


A web application developed with JavaScript and the Svelte framework makes HTTP requests to a Java backend. The backend answers with server-sent events that the frontend uses to update the user interface on the browser.

Бэкенд реализован с использованием Spring Boot и подключается к кластеру MariaDB баз данных с помощью R2DBC (реактивного). Логика бэкенда, вкратце, является симуляцией чтений и записей в базу данных онлайн-магазина. Симуляция параметризована, и пользователь может настроить:

  • Количество посещений продукта в минуту: Сколько чтений из базы данных в минуту.
  • Количество заказов в минуту: Сколько записей в базу данных в минуту.
  • Продукты в заказе: Усиление записи.
  • Таймаут в миллисекундах: Сколько секунд проходит до того, как запрос к базе данных считается неудачным.

Колония базы данных предваряется прокси-базой данных под названием MaxScale. Этот прокси делает кластер похожим на единую логическую базу данных для Java backend. MaxScale также выполняет разделение чтения/записи (отправляет записи на основной сервер MariaDB и чтения на реплики), а также балансирует нагрузку чтений среди серверов-реплик с использованием настраиваемого алгоритма. Данные автоматически реплицируются с основного на серверы реплик базы данных.

Создание образов Docker из исходного кода

I have prepared custom Docker images for every component in the simulator. You can either build the images from the source (optional) or use the already built and published images from Docker Hub. If you decide to build the images yourself, you can find the source code on GitHub:

  • Развертывания MariaDB: Пользовательские образы для легкой установки реплицированных топологий MariaDB с MaxScale. НЕ ИСПОЛЬЗУЙТЕ ЭТИ ОБРАЗЫ В ПРОИЗВОДСТВЕННОЙ СРЕДЕ! Данные образы подходят только для демонстрационных приложений. Для производственных развертываний используйте официальные образы MariaDB для Docker.
  • Бэкенд-приложение: Бэкенд-приложение, которое подключается к кластеру баз данных.
  • Фронтенд-приложение: Фронтенд-приложение, которое отправляет запросы на конфигурацию симуляции к бэкенду и получает события для отображения результата симуляции.

Каждый репозиторий содержит Dockerfile, которые вы можете использовать для создания своих собственных образов Docker. Например, для сборки образа бэкенд-приложения запустите:

Shell

  

docker build --tag alejandrodu/online-store-simulator-java-backend .

Запуск симуляции

Все сервисы можно запустить с помощью следующего файла Docker Compose (docker-compose.yml):

YAML

  

version: "3.9"
services:
  server-1:
    container_name: server-1
    image: alejandrodu/mariadb
    ports:
      - "3306:3306"
    environment:
      - MARIADB_CREATE_DATABASE=demo
      - MARIADB_CREATE_USER=user:Password123!
      - MARIADB_CREATE_REPLICATION_USER=replication_user:ReplicationPassword123!
      - MARIADB_CREATE_MAXSCALE_USER=maxscale_user:MaxScalePassword123!

  server-2:
    container_name: server-2
    image: alejandrodu/mariadb
    ports:
      - "3307:3306"
    environment:
      - MARIADB_REPLICATE_FROM=replication_user:ReplicationPassword123!@server-1:3306

  server-3:
    container_name: server-3
    image: alejandrodu/mariadb
    ports:
      - "3308:3306"
    environment:
      - MARIADB_REPLICATE_FROM=replication_user:ReplicationPassword123!@server-1:3306

  maxscale:
    container_name: maxscale
    image: alejandrodu/mariadb-maxscale
    command: --admin_host 0.0.0.0 --admin_secure_gui false
    ports:
      - "4000:4000"
      - "8989:8989"
      - "27017:27017"
    environment:
      - MAXSCALE_USER=maxscale_user:MaxScalePassword123!
      - MARIADB_HOST_1=server-1 3306
      - MARIADB_HOST_2=server-2 3306
      - MARIADB_HOST_3=server-3 3306
    healthcheck:
      test: ["CMD", "maxctrl", "list", "servers"]
      interval: 5s
      timeout: 10s
      retries: 5

  java-backend:
    container_name: java-backend
    image: alejandrodu/online-store-simulator-java-backend
    ports:
      - "8080:8080"
    environment:
    - spring.r2dbc.url=r2dbc:mariadb://maxscale:4000/demo
    - spring.r2dbc.username=user
    - spring.r2dbc.password=Password123!
    - spring.liquibase.url=jdbc:mariadb://maxscale:4000/demo
    - spring.liquibase.user=user
    - spring.liquibase.password=Password123!
    depends_on:
      maxscale:
        condition: service_healthy

  svelte-frontend:
    container_name: svelte-fronted
    image: alejandrodu/online-store-simulator-svelte-frontend
    ports:
      - "5173:80"
    environment:
      - BACKEND_URL=http://java-backend:8080

Перейдите в каталог, в котором находится файл Docker Compose, и запустите сервисы в режиме отсоединенного мониторинга следующим образом:

Shell

  

docker compose up -d

Настройка MaxScale

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

Перейдите по ссылке http://localhost:8989/ и войдите в пользовательский интерфейс, используя:

  • Имя пользователя:admin
  • Пароль:mariadb

На экране отобразится панель управления с состоянием кластера MariaDB.


Здесь есть основной сервер (server-1), а также две реплики (server-2 и server-3). Репликация уже настроена от server-1 (основной) к server-2 и server-3 (реплики). Все серверы должны быть запущены.

Нажмите на mdb_monitor и затем на иконку карандаша для включения редактирования параметров. Установите следующие параметры:

  • auto_failover (true): Это включает автоматическое переключение на резервный сервер. Когда MariaDB сервер выходит из строя, MaxScale выбирает реплику сервера и перенастраивает его как новый основной, чтобы запись могла продолжаться.
  • auto_rejoin (true): Это включает автоматическое возвращение восстановленных серверов. Когда сервер, который вышел из строя, снова запущен, MaxScale обнаруживает это и настраивает его как доступную реплику сервера.
  • failcount (1): Устанавливает количество итераций монитора (компонент в MaxScale, который проверяет статус сервера), необходимых для того, чтобы сервер был признан вышедшим из строя, чтобы активировать процесс переключения на резервный. Мы устанавливаем значение 1, чтобы убедиться, что переключение на резервный начинается сразу после сбоя.
  • backend_connect_timeout (1000): Таймаут соединения для мониторных соединений. Мы устанавливаем низкое значение (одна секунда) для быстрого активации переключения на резервный для этой демонстрации.
  • backend_read_timeout (1000): Время ожидания чтения для соединений мониторинга.
  • backend_write_timeout (1000): Время ожидания записи для соединений мониторинга.
  • master_failure_timeout (1000): Время ожидания отказа основного сервера.
  • monitor_interval (1000): Частота мониторинга серверов.

ВНИМАНИЕ: Эти значения подходят для демонстрации, но, скорее всего, не оптимальны для производственных сред!

После установки параметров нажмите Готово редактировать и Подтвердить.

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

На главном меню нажмите на Панель управления и затем на любую из ссылок сервис маршрутизации запросов в списке серверов. Измените параметры следующим образом:

  • transaction_replay (true): Активирует автоматический повтор неудачных транзакций.
  • transaction_replay_retry_on_deadlock (true): То же самое, что и предыдущее, когда происходит тупик.
  • transaction_replay_retry_on_mismatch (true): То же самое, что и предыдущее, когда возникает несоответствие контрольной суммы.

После установки параметров нажмите Готово редактировать и Подтвердить.

Запуск симуляции

Со всем настроенным, вы можете начать симуляцию. Перейдите по адресу http://localhost:5173/ и настройте следующие параметры (названия, я надеюсь, самоочевидны):

  • Посещения продуктов в минуту:6000
  • Заказов в минуту:60
  • Таймаут в миллисекундах:8000

Но перед тем как начать симуляцию, вам нужно создать продукты для интернет-магазина. Нажмите на Данные | Создать продукты…. Оставьте значения по умолчанию и нажмите на Создать. Вы должны увидеть, как UI обновляется по мере создания продуктов в базе данных.

Теперь вы можете, наконец, нажать на Старт и увидеть симуляцию в действии.


Симуляция сбоя сервера

На данный момент основной сервер обрабатывает записи (заказы). Что произойдет, если вы остановите этот сервер? В командной строке запустите:

Shell

  

docker stop server-1

В зависимости от множества факторов, вы можете получить несколько “разочарованных посетителей” или даже несколько “пропущенных возможностей” в симуляторе. Или, возможно, ничего не получите! Посещения продуктов (чтения) и заказы (записи) продолжают происходить благодаря MaxScale. Без автоматического отказа, вам придется перенастроить все вручную, что приводит к большему времени отключения и в результате к множеству разочарованных посетителей и пропущенных возможностей!

Запустите неработающий сервер:

Shell

  

docker start server-1

Перейдите в MaxScale Панель управления (http://localhost:8989/) и проверьте, что server-1 теперь функционирует как работающая копия.

Вы можете выполнить ручную переключение, чтобы снова сделать сервер-1 основным сервером. Нажмите на mdb_monitor и затем наведите курсор на раздел MASTER. Нажмите на значок карандаша и выберите server-1. Нажмите Swap и проверьте еще раз на Панели мониторинга, что новый основной сервер – это server-1.

Заключение

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

Source:
https://dzone.com/articles/high-availability-and-resiliency-in-databases