Общие сведения

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

Выбор схемы резервирования зависит от первоначальных требований клиента и количества ТД которые будут использоваться. Всего предоставляется 2-а варианта настройки схемы с резервированием. 

1. Схема резервирования SoftWLC 1+1 в Docker при помощи Ansible

2. Схема репликации SoftWLC 1+1+3 GaleraNodes в Docker при помощи Ansible

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

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

Далее более подробно разберем какая схема больше подходит под определенные условия.

Схема репликации SoftWLC 1+1+3 GaleraNodes в Docker при помощи Ansible

Описание 

Схема резервирования SoftWLC 1+1+3 GaleraNodes представляется мультихостовой установкой из 5 нод: 2 хоста SoftWLC и 3 хоста для баз данных. Связь баз данных осуществляется при помощи ProxySQL+GaleraCluster.

Кому подходит данная схема? 

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

Минимальные требования 

Для работы решения понадобятся пять виртуальных машин: 2 хоста SoftWLC и 3 хоста для баз данных. 

Минимальные требования для хостов с SoftWLC:

• Оперативная память не менее 32Гб
• CPU >= 2200MHz, 8 Core, 64-bit x86 CPUs
• Память жесткого диска >= 500Gb
• Выход в Интернет
• Операционная система Ubuntu Server 20.04 LTS / Ubuntu Server 22.04 LTS / Ubuntu Server 24.04 LTS / Astra Linux Special Edition 1.7.4 / Astra Linux Special Edition 1.7.5 (Воронеж, Орел) / РЕД ОС Муром (7.3.1-7.3.3) / РЕД ОС 8

Минимальные требования для хостов с БД:

• Оперативная память не менее 64Гб
• CPU >= 2200MHz, 4 Core, 64-bit x86 CPUs
• Память жесткого диска >= 500Gb
• Выход в Интернет
• Операционная система Ubuntu Server 20.04 LTS / Ubuntu Server 22.04 LTS / Ubuntu Server 24.04 LTS / Astra Linux Special Edition 1.7.4 / Astra Linux Special Edition 1.7.5 (Воронеж, Орел) / РЕД ОС Муром (7.3.1-7.3.3) / РЕД ОС 8

Преимущества и недостатки данной схемы

Преимущества: 

• Данная схема предотвращает Split-Brain 
• В данной схеме можно использовать больше 10 тысяч ТД

Недостатки:

• Задействовано большое количество ресурсов 
• Необходимость в 5 хостах для развёртывания

Принципиальные схемы репликации:

SoftWLC и Ansible на одном хосте:

SoftWLC и Ansible на отдельном хосте:

Настройка данной схемы более подробно описана в инструкции: Настройка схемы репликации SoftWLC 1+1+3 GaleraNodes в Docker при помощи Ansible

Схема резервирования 1+1 

Описание

Схема 1+1 - это схема в которой реализована репликация MySQL с автоматическим позиционированием GTID, которая помогает обеспечить сохранность данных. GTID появился с MySQL 5.6 и представляет собой уникальный 128-битный глобальный идентификационный номер (SERVER_UUID), который увеличивается с каждой новой транзакцией. Классическая репликация MySQL без GTID использует позицию в бинарном логе. Но благодаря GTID больше не нужно разбираться с вычислениями позиции бинлога. Из преимуществ GTID является согласованность данных, т.е. на сервере (как на master, так и на slave) будет подтверждена одна и только одна транзакция с одним GTID, а любые другие транзакции, имеющие такой же UUID, будут проигнорированы.

Кому подходит данная схема? 

Данная схема подходит эксплуатациям с малым количеством ТД (до  1000 ТД)  и желающим иметь резервирование. 

Минимальные требования 

• Операционная система Ubuntu Server 20.04 LTS / Ubuntu Server 22.04 LTS / Astra Linux Special Edition 1.7.4 (Воронеж, Орел)
• 2 сервера с памятью и CPU в соответствие с количеством ТД :

Преимущества и недостатки данной схемы

Преимущества: 

• Легкость установки и администрирования
• Благодаря использованию GTID и ProxySQL повышается отказоустойчивость

Недостатки:

• Данная схема не предотвращает Split-Brain 

Принципиальная схема  резервирования 1+1

Для настройки схемы с резервирования при наличии одного активного хоста воспользуйтесь инструкцией : Настройка резервирования в схеме 1+1

При первоначальной установке воспользуйтесь инструкцией : Установка схемы резервирования при помощи скрипта

Если имеются закрытый контур, то возможна аналогичная установка схемы резервирование в doсker.

​