Налаштування відмовостійкого кластера баз даних з використанням MariaDB Galera, ProxySQL, Keepalived та Debian 13

Вступ

В процесі розвитку ваших додатків забезпечення постійної доступності та відмовостійкості стає критично важливим. Простій або відмова бази даних може призвести до фінансових та репутаційних збитків. У цьому посібнику описано створення відмовостійкого кластера БД з використанням MariaDB, реплікації за допомогою Galera, ProxySQL для інтелектуальної маршрутизації запитів та Keepalived для управління віртуальною IP-адресою. Посібник описує розгортання кластера на 3 VPS (ноди) під керуванням Debian 13.

Ця архітектура поєднує у собі переваги кожної технології. MariaDB Galera забезпечує синхронну реплікацію даних між нодами БД, гарантує узгодженість даних на них. ProxySQL виконує функцію маршрутизатора запитів, забезпечує інтелектуальне керування трафіком та балансування навантаження. Keepalived управляє віртуальною IP-адресою, надаючи єдину точку доступу до кластера, і автоматизує перемикання між нодами у разі збою.

Даний посібник передбачає наявність досвіду системного адміністрування Linux, базові знання мережевих технологій (TCP/IP, DNS) та базові навички адміністрування баз даних.

Переваги даної архітектури:

• Висока доступність: Автоматизоване перемикання нод під час збою, мінімальний час простою.
• Узгодженість даних: Синхронна реплікація гарантує узгодженість даних на всіх нодах.
• Продуктивність: ProxySQL оптимізує маршрутизацію запитів та знижує навантаження на ноди.
• Єдина точка доступу: Віртуальна IP-адреса спрощує налаштування доступу до БД.

Що вам знадобиться:

• Три VPS або сервери під керуванням Debian 13.
• Доступ до root або sudo на всіх серверах.
• Досвід роботи у командному рядку.
• Базові знання TCP/IP та DNS.

Вимоги

Хостнейми нод

Налаштування кластера за допомогою хостнеймів спрощує конфігурацію та підтримку кластера. ІР-адреси вузлів повинні знаходитися в одній підмережі.

Хостнейми та IP-адреси

• galera0 (майстер): 192.168.10.10
• galera1 (слейв): 192.168.10.11
• galera2 (слейв): 192.168.10.12

Налаштувати дозвіл хостнеймів можна за допомогою /etc/hosts або DNS.

• За допомогою /etc/hosts (рекомендується для тестових конфігурацій): Підходить для середовищ тестування та розробки. На кожному сервері додайте записи, що зіставляють хостнейм сервера з його статичною IP-адресою у файлі /etc/hosts.
• За допомогою DNS (рекомендується для робочих конфігурацій): Для робочих конфігурацій або кластерів рекомендується налаштувати DNS-записи (записи A), що зіставляють хостнейми серверів з відповідними IP-адресами.

Перевірка

Після налаштування дозволу хостнеймів переконайтеся, що кожен сервер може розв'язати хостнейми інших серверів за допомогою команди ping. Наприклад, з galera0 виконайте ping galera1. Ви маєте отримати відповідь.

Встановлення необхідних пакетів

Перед налаштуванням кластера Galera потрібно встановити необхідні пакети MariaDB на кожній ноді. У цьому розділі описано необхідні кроки для систем на базі Debian.

Налаштування репозиторію

Додайте необхідні репозиторії, використовуючи наступні команди:

apt-get update && apt-get install -y --no-install-recommends lsb-release wget apt-transport-https ca-certificates

wget -nv -O /usr/share/keyrings/proxysql-3.0.x-keyring.gpg 'https://repo.proxysql.com/ProxySQL/proxysql-3.0.x/repo_pub_key.gpg'

echo "deb [signed-by=/usr/share/keyrings/proxysql-3.0.x-keyring.gpg] https://repo.proxysql.com/ProxySQL/proxysql-3.0.x/bookworm/ ./" | tee /etc/apt/sources.list.d/proxysql.list

Оновлення системи

Спочатку оновіть списки пакетів та самі пакети. Запустіть наступну команду з правами root на кожній ноді:

apt update && apt upgrade -y

Встановлення пакетів

Встановіть необхідні пакети на кожній ноді за допомогою цієї команди:

apt install rsync mariadb-server mariadb-client galera-4 proxysql keepalived -y

Безпека MariaDB

Запустіть скрипт налаштування безпеки на кожній ноді:

sudo mariadb-secure-installation

Цей скрипт виконує два важливі кроки: він запропонує вам встановити надійний пароль користувача root для сервера MariaDB і видалити всі небезпечні налаштування за замовчуванням. Виконайте вказівки на екрані, щоб завершити процес.

Увімкнення віддаленого доступу до MariaDB

Виконайте ці команди на кожній ноді, щоб увімкнути віддалений доступ:

sed -i "s/.*bind-address.*/bind-address = 0.0.0.0/" /etc/mysql/mariadb.conf.d/50-server.cnf

systemctl restart mariadb

Galera

Galera забезпечує синхронну реплікацію даних між усіма нодами кластера. Це означає, що кожна зміна, внесена до бази даних на одній ноді, автоматично і одночасно поширюється на всі інші ноди. Роль Galera у цій конфігурації:

• Висока доступність: У разі виходу з ладу однієї ноди решта забезпечує безперебійну роботу. Кластер автоматично призначає основну робочу ноду.
• Узгодженість даних: Завдяки синхронній реплікації, дані завжди узгоджені на всіх нодах. Це усуває ризик застарілих читань – ви завжди читаєте найактуальнішу версію даних.
• Масштабованість читання: Оскільки дані реплікуються між кількома вузлами, можна розподіляти запити на читання по всьому кластеру для підвищення продуктивності читання.

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

Конфігурація

Створіть конфігураційний файл /etc/mysql/conf.d/galera.cnf на кожній ноді. Вміст буде ідентичним, за винятком імені та адреси кожної ноди. Вставте цей шаблон:

[mysqld]
# Basic MariaDB settings
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

# Galera Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so

# Galera Cluster Configuration
wsrep_cluster_name="my_galera_cluster"
wsrep_cluster_address="gcomm://galera0,galera1,galera2"

# This node's specific configuration
wsrep_node_name="<node_name>"
wsrep_node_address="<node_address>"

Замініть <node_name> і <node_address> на кожній ноді. Використовуйте galera0 для першої ноди і так далі.

Запуск кластера

Запустіть кластер на першій ноді за допомогою цієї команди:

sudo systemctl stop mariadb && sudo galera_new_cluster

Перезапустіть MariaDB на інших нодах:

sudo systemctl restart mariadb

Перевірте налаштування кластера

Перевірте розмір кластера

Підключіться до MariaDB на будь-якій ноді та перевірте стан кластера. Підключіться до бази даних:

sudo mariadb -u root -p

Перевірте стан нод кластера в командній оболонці MariaDB:

SHOW STATUS LIKE 'wsrep_cluster_size';

wsrep_cluster_size має дорівнювати кількості наших нод.

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+
1 row in set (0.001 sec)

Тест реплікації

Створіть тестову базу даних на будь-якій ноді та додайте тестовий запис. Виконайте такі команди в оболонці MariaDB:

CREATE DATABASE galtest;

USE galtest;

CREATE TABLE messages (id INT AUTO_INCREMENT PRIMARY KEY, text VARCHAR(255));

INSERT INTO messages (text) VALUES ('Test from galera0!');

Потім перевірте дані на інших нодах, використовуючи наступний SQL-запит через оболонку MariaDB:

USE galtest;

SELECT * FROM messages;

Тестовий запис повинний з'явитися:

+----+--------------------+
| id | text               |
+----+--------------------+
|  7 | Test from galera0! |
+----+--------------------+
1 row in set (0.001 sec)

ProxySQL

Роль ProxySQL у цій конфігурації кластера — це більше, ніж просто проксі; він значно підвищує продуктивність, надійність та керованість вашої бази даних. ProxySQL відіграє ключову роль між вашим додатком (додатками) та кластером Galera. Його основні завдання:

• Кешування запитів: ProxySQL агресивно кешує запити, що часто виконуються. Замість того, щоб багаторазово виконувати ті самі запити до кластера Galera, він надає кешований результат, значно знижуючи навантаження на базу даних і покращуючи час відгуку. Це особливо корисно для додатків з інтенсивним читанням.
• Об'єднання з'єднань: ProxySQL підтримує пул постійних підключень до кластера Galera. Встановлення з'єднання з базою даних – ресурсоємна операція. Об'єднання з'єднань дозволяє нівелювати ці накладні витрати за рахунок повторного використання існуючих підключень, що додатково підвищує продуктивність.
• Балансування навантаження та маршрутизація запитів: ProxySQL може інтелектуально спрямовувати запити до різних нод вашого кластера Galera залежно від таких факторів, як навантаження на сервер, тип запиту або прив'язка даних. Це дозволяє розподілити навантаження та максимізувати продуктивність вашого кластера.
• Оптимізація запитів: ProxySQL може переписувати запити, роблячи їх ефективнішими, потенційно використовуючи можливості Galera для оптимального виконання.
• Виявлення збоїв та маршрутизація: ProxySQL постійно відстежує стан вашіх нод Galera. У разі збою ноди ProxySQL автоматично перенаправляє запити на робочі ноди, забезпечуючи безперебійну роботу.

По суті, ProxySQL діє як інтелектуальний менеджер трафіку та оптимізатор продуктивності для вашого кластера Galera, значно підвищує його ефективність та стійкість.

Запобіжні заходи

Налаштування користувачів

Акаунт моніторингу

Акаунт моніторингу в ProxySQL – це виділений обліковий запис бази даних, призначений виключно для інструментів моніторингу, що забезпечує безпечний доступ до внутрішньої статистики та метрик. Він налаштований з мінімальними правами доступу – лише SELECT – що гарантує цілісність та безпеку ваших даних, а також дозволяє здійснювати комплексний моніторинг продуктивності.

Виконайте цей запит в оболонці MariaDB на майстер ноді, щоб додати користувача моніторингу:

CREATE USER 'monitor'@'%' IDENTIFIED BY 'monitor';

GRANT SELECT ON *.* TO 'monitor'@'%';

FLUSH PRIVILEGES;

Акаунт додатка

Акаунт додатка в ProxySQL — це стандартний обліковий запис бази даних, що використовується вашими додатками для підключення та виконання запитів до базового кластера Galera. Через цього користувача ваш додаток безпосередньо взаємодіє з базою даних, отримуючи та змінюючи дані.

Виконайте цей запит в оболонці MariaDB на майстер ноді, щоб додати користувача додатка:

GRANT ALL PRIVILEGES ON *.* TO 'test'@'%' IDENTIFIED BY 'test' WITH GRANT OPTION;

FLUSH PRIVILEGES;

Перевірка

Перевірте створення користувача на всіх нодах за допомогою цієї команди:

mariadb -u root -e "SELECT user, host FROM mysql.user;"

Конфігурація

Створіть конфігураційний файл /etc/proxysql.cnf на кожній ноді з таким вмістом:

datadir="/var/lib/proxysql"
admin_variables={
        admin_credentials="admin:admin"
        mysql_ifaces="127.0.0.1:6032"
}
mysql_variables={
        threads=4
        max_connections=2048
        monitor_username="monitor"
        monitor_password="monitor"
}
mysql_servers=(
        { address="galera0" , port=3306 , hostgroup=0 },
        { address="galera1" , port=3306 , hostgroup=0 },
        { address="galera2" , port=3306 , hostgroup=0 })
mysql_users=(
        { username = "test" , password = "test" , default_hostgroup = 0 , active = 1 })
mysql_query_rules=(
        {
                rule_id=2
                active=1
                match_pattern="^SELECT.*"
                destination_hostgroup=0
                apply=1
        })

Додайте в автозавантаження і запустіть ProxySQL за допомогою наступних команд:

sudo systemctl start proxysql

sudo systemctl enable proxysql

sudo proxysql --reload

Перевірте налаштування ProxySQL за допомогою цієї команди:

mysql -u admin -padmin -h 127.0.0.1 -P6032 -e "SELECT hostname,status FROM mysql_servers;"

Усі ноди повинні бути онлайн:

+----------+--------+
| hostname | status |
+----------+--------+
| galera0  | ONLINE |
| galera1  | ONLINE |
| galera2  | ONLINE |
+----------+--------+

Keepalived

Keepalived керує віртуальною IP-адресою, надаючи єдину точку доступу до кластера і автоматизує перемикання у разі збою нод. Він моніторить стан нод MariaDB та перенаправляє трафік на працездатну ноду у разі збою, підтримуючи високу доступність. Конфігурація визначає Virtual Router ID 51 та використовує інтерфейс eth0. На майстер ноді state установлений у MASTER з пріоритетом 100. Слейв ноди налаштовані з state BACKUP, що мають пріоритети 90 та 80 відповідно. virtual_ipaddress встановлений у 192.168.10.50 на всіх нодах. VIP та ноди повинні знаходитися в одній підмережі. Хостинг має підтримувати VIP для VPS. Аутентифікація включається за допомогою загального пароля 1234. Параметр advert_int визначає, як часто майстер нода надсилає VRRP-оголошення. Менше значення означає частіші оголошення, що потенційно прискорює виявлення відмови; більше значення означає рідші оголошення, що потенційно затримує перемикання, але знижує навантаження на мережу.

Конфігурація

Створіть конфігураційний файл /etc/keepalived/keepalived.conf на кожній ноді з таким вмістом:

vrrp_instance VI_1 {
    state <NODE_STATE>
    interface eth0
    virtual_router_id 51
    priority <NODE_PRIORITY>
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        192.168.10.50/24
    }
}

Замініть <NODE_STATE> і <NODE_PRIORITY> як описано вище. Додайте в автозавантаження і запустіть службу keepalived:

sudo systemctl enable keepalived && sudo systemctl start keepalived

Перевірка

Для перевірки налаштувань використовуйте VIP, налаштований через Keepalived, та порт, налаштований через ProxySQL. Перевірте розмір кластера, наприклад:

mariadb -u test -ptest -h 192.168.10.50 -P6033 -D galtest -e "SHOW STATUS LIKE 'wsrep_cluster_size';"

Очікувана відповідь має бути ідентичною перевірці Galera:

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

Тепер ви можете перезапускати вузли у випадковому порядку, перевіряти розмір кластера та доступність даних.

Висновок

У цьому посібнику описано процес створення високодоступного кластера MariaDB з використанням реплікації Galera, ProxySQL для маршрутизації запитів та Keepalived для керування віртуальною IP-адресою на Debian. Ця архітектура забезпечує низку ключових переваг, включаючи високу доступність з автоматичним перемиканням, узгодженість даних завдяки синхронній реплікації та підвищену продуктивність завдяки ProxySQL. Поєднуючи ці технології, можна створити надійний та відмовостійкий кластер БД, здатний витримувати високі навантаження та мінімізувати час простою.