У Сітімобілі ми використовуємо базу даних MySQL як основне сховище постійних даних. У нас є кілька кластерів баз даних під різні послуги та цілі.

Постійна доступність майстра є критичним показником працездатності всієї системи та її окремих елементів. Автоматичне відновлення кластера у разі відмови майстра сильно знижує час реагування на інцидент та час простою системи. У цій статті я розгляну схему забезпечення високої доступності (HA) кластера MySQL на основі MySQL Orchestrator та віртуальних IP адрес (VIP).

HA-рішення на основі VIP

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

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

Реплікація виконується у напівсинхронному режимі на основі GTID. Це означає, що як мінімум одна репліка має записати транзакцію до журналу, перш ніж її буде визнано успішною. Такий режим реплікації забезпечує оптимальний баланс між продуктивністю та збереженням даних у разі виходу з ладу головного вузла. В основному всі зміни передаються від майстра до реплік за допомогою Row Based Replication (RBR), але частина вузлів може мати mixed binlog format.

Оркестратор періодично оновлює стан топології кластера, аналізує отриману інформацію та у разі виникнення проблем може запустити процедуру автоматичного відновлення. За процедуру відповідає розробник, оскільки його можна реалізувати різними способами: з урахуванням VIP, DNS, з допомогою служб виявлення сервісів (service discovery) чи самописних механізмів.

Одним із простих способів відновлення майстра у разі його відмови є використання плаваючих VIP-адрес.

Що потрібно знати про це рішення, перш ніж рухатися далі:

VIP - це IP-адреса, яка не прив'язана до конкретного фізичного мережного інтерфейсу. При виході вузла з ладу або планових роботах ми можемо переключити VIP на інший ресурс з мінімальним часом простою.
Звільнення та видача віртуальної IP-адреси – дешеві та швидкі операції.
Для роботи з VIP потрібен доступ до сервера SSH, або використання спеціальних утиліт, наприклад, keepalived.

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

Зникла мережна зв'язність до майстра, або виникла проблема на рівні «заліза», і сервер недоступний

Оркестратор оновлює топологію кластера, кожна репліка повідомляє про відсутність майстра. Оркестратор запускає процес вибору репліки, яка підходить на роль нового майстра, і починає відновлення.
Намагаємось зняти VIP зі старого майстра – безуспішно.
Репліка переключається на роль майстра. Топологія перебудовується.
Додаємо новий мережевий інтерфейс із VIP. Оскільки зняти VIP не вдалося, у фоновому режимі запускаємо періодичну відправку запиту gratuitous ARP. Цей вид запиту/відповіді дозволяє оновити на підключених комутаторах таблицю відповідності IP- та MAC-адрес, повідомляючи про переїзд нашого VIP. Це мінімізує ймовірність split brain при поверненні старого майстра.
Всі нові з'єднання одразу ж перенаправляються на новий майстер. Старі з'єднання завершуються невдало, виконуються повторні звернення до БД лише на рівні докладання.

Сервер працює в нормальному режимі, відбулася відмова на рівні СУБД

Алгоритм аналогічний попередньому випадку: оновлення топології та запуск процесу відновлення. Оскільки сервер доступний, ми успішно звільняємо VIP на старому майстрі, переносимо його на новий та надсилаємо декілька ARP-запитів. Можливе повернення старого майстра не повинно вплинути на перебудований кластер та роботу програми.

інші проблеми

Відмова реплік чи проміжних майстрів не приводить до автоматичних дій та вимагає ручного втручання.

Віртуальний інтерфейс мережі завжди додається тимчасово, тобто після перезавантаження сервера VIP автоматично не призначається. Кожен екземпляр БД за замовчуванням запускається в режимі тільки для читання, оркестратор автоматично перемикає новий майстер на запис і намагається встановити read only на старому майстрі. Ці дії спрямовані на зменшення ймовірності split brain.

У процесі відновлення можуть виникнути проблеми, про які варто також повідомляти через UI оркестратора, крім стандартних засобів моніторингу. Ми розширили REST API, додавши таку можливість (PR зараз перебуває на розгляді).

Загальна схема HA-рішення представлена нижче.

Вибір нового майстра

Оркестратор досить розумний і намагається вибрати найбільш відповідну репліку в якості нового майстра за такими критеріями:

відставання репліки від майстра;
версія MySQL майстра та репліки;
тип реплікації (RBR, SBR чи mixed);
розташування в одному чи різних дата-центрах;
наявність errant GTID - транзакції, які були виконані на репліці та відсутні на майстрі;
також враховуються користувацькі правила вибору.

Чи не кожна репліка є ідеальним кандидатом на роль майстра. Наприклад, репліка може бути використана для резервного копіювання даних, або сервер має більш слабку конфігурацію «заліза». Оркестратор підтримує ручні правила, за допомогою яких можна налаштувати свої переваги на вибір кандидата від найбільш кращих до ігнорованих.

Час реагування та відновлення

У разі інциденту важливо мінімізувати час простою системи, тому розглянемо параметри MySQL, що впливають на побудову та оновлення топології кластера оркестратором:

slave_net_timeout - кількість секунд, протягом яких репліка очікує надходження нових даних або heartbeat-сигналу від майстра, перш ніж з'єднання визнається втраченим і виконується перепідключення. Що менше значення, то швидше репліка зможе визначити, що зв'язок з майстром порушено. Ми встановлюємо це значення рівним 5 секунд.
MASTER_CONNECT_RETRY – кількість секунд між спробами перепідключення. У разі проблем із мережею низьке значення цього параметра дозволить швидко перепідключитися і запобігти запуску процесу відновлення кластера. Рекомендоване значення – 1 секунда.
MASTER_RETRY_COUNT - Максимальна кількість спроб перепідключення.
MASTER_HEARTBEAT_PERIOD - інтервал за секунди, після якого майстер відправляє heartbeat-сигнал. За замовчуванням дорівнює половині значення slave_net_timeout.

Параметри оркестратора:

DelayMasterPromotionIfSQLThreadNotUpToDate - Якщо дорівнює true, то роль майстра не буде застосована на репліці-кандидаті до тих пір, поки SQL-потік репліки не виконає всі застосовані транзакції з Relay Log. Ми використовуємо цю опцію, щоб не втрачати транзакції за умов відставання всіх реплік-кандидатів.
InstancePollSeconds - Частота побудови та оновлення топології.
RecoveryPollSeconds - Частота аналізу топології. У разі виявлення проблеми починається відновлення топології. Це константа, що дорівнює 1 секунді.

Кожен вузол кластера опитується оркестратором один раз на InstancePollSeconds секунд. При виявленні проблеми стан кластера примусовий оновлюєтьсяа потім приймається остаточне рішення про виконання відновлення. Експериментуючи з різними параметрами БД та оркестратора, нам вдалося знизити тривалість реагування та відновлення до 30 секунд.

Тестовий стенд

Тестування HA-схеми ми розпочали з розробки локального тестового стенду та подальшого впровадження у тестове та бойове оточення. Локальний стенд повністю автоматизований на основі Docker і дозволяє експериментувати з конфігурацією оркестратора та мережі, масштабувати кластер від 2-3 серверів до кількох десятків та проводити навчання у безпечному середовищі.

Під час навчань ми обираємо один із методів емуляції проблеми: миттєво відстрілити майстер за допомогою kill -9, м'яко завершити процес і зупинити сервер (docker-compose stop), імітувати проблеми з мережею за допомогою iptables -j REJECT або iptables -j DROP. Ми очікуємо на такі результати:

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

Як ви знаєте, система може поводитися по-різному в тестовому та production-оточеннях через різну конфігурацію «заліза» та мережі, відмінностей у синтетичному та реальному навантаженні тощо. Тому періодично ми проводимо навчання в реальних умовах, перевіряючи, як поводиться система при втраті мережевої зв'язності чи деградації її окремих частин. У майбутньому хочемо побудувати повністю ідентичну інфраструктуру для обох середовищ та автоматизувати її тестування.

Висновки

Працездатність головного вузла системи зберігання даних є одним із основних завдань команди SRE та експлуатації. Впровадження оркестратора та HA-рішення на основі VIP дозволило досягти наступних результатів:

надійне виявлення проблем із топологією кластера БД;
автоматичне та швидке реагування на інциденти, пов'язані з майстром, що знижує час простою системи.

Однак рішення має свої обмеження та недоліки:

масштабування HA-схеми на кілька ЦОД потребує наявності єдиної L2-мережі між ними;
Перш ніж призначити VIP на новому майстрі, нам потрібно звільнити його на старому. Процес є послідовним, що підвищує час відновлення;
звільнення VIP вимагає SSH-доступу до сервера або будь-якого іншого способу виклику віддалених процедур. Оскільки сервер або БД має проблеми, що викликали процес відновлення, ми не можемо бути впевнені, що зняття VIP завершиться вдало. А це може призвести до появи двох серверів з однаковою віртуальною IP-адресою та проблемою. split brain.

Щоб уникнути split brain, можна використовувати метод STONITH ("Shoot The Other Node In The Head"), який повністю ізолює або вимикає проблемний вузол. Існують й інші способи реалізації високої доступності кластера: комбінація VIP та DNS, виявлення служб та проксі-сервіси, синхронна реплікація та інші способи, які мають свої недоліки та переваги.

Я розповів про наш підхід до створення відмовостійкого кластеру MySQL. Він простий у реалізації та забезпечує прийнятний рівень надійності у поточних умовах. У міру розвитку всієї системи в цілому та інфраструктури зокрема цей підхід, безперечно, еволюціонуватиме.

Джерело: habr.com

Orchestrator та VIP як HA-рішення для кластера MySQL