MySQL надає кілька параметрів конфігурації реплікації. Реплікація є важливим початковим кроком для підвищення доступності баз даних MySQL. Правильно розроблена архітектура реплікації може суттєво вплинути на доступність ваших даних і запобігти можливим ускладненням керування.
У DevOps.com розглянули найкращі практики реплікації.
Активні та пасивні налаштування
При використанні активного/пасивного режиму для реплікації в MySQL один сервер діє як джерело, а інші слугують як репліки лише для читання. Репліки можуть обробляти запити лише для читання, але всі записи мають бути спрямовані до джерела.
Ця конфігурація розподіляє навантаження між усіма репліками. Тим не менш, у режимі асинхронної реплікації за замовчуванням може виникнути затримка між записом даних у джерело та моментом, коли вони доступні на репліці. Майте це на увазі під час розробки програми.
Конфігурація активний/активний дозволяє кільком серверам виконувати операції як читання, так і запису. Хоча може здатися корисним мати два сервери для запитів на запис, кожен сервер все одно повинен обробляти робоче навантаження запитів іншого, що робить розподіл запису менш ефективним.
Крім того, в MySQL відсутня власна логіка вирішення конфліктів, що ускладнює визначення справжнього джерела даних без суттєвої втрати даних.
Рекомендовано використовувати активну/пасивну конфігурацію для реплікації та шардингу, якщо вам потрібна більша пропускна здатність вашої бази даних.
Як увімкнути GTID
Глобальні ідентифікатори транзакцій (GTID) – це унікальні ідентифікатори, які додаються до транзакцій у реплікованому середовищі.
За замовчуванням репліки відстежують оброблені записи у бінарному файлі журналу вихідної бази даних. Однак цей метод є нестабільним, якщо джерело виходить із ладу і журнали потрібно відновити.
Якщо GTID увімкнено, то кожна транзакція отримує ідентифікатор на основі UUID. Це дозволяє реплікам визначати, чи була транзакція оброблена.
GTID – це UUID, що представляє вихідний сервер, за яким слідує ідентифікатор, який автоматично збільшується (наприклад, 14a54b2f-2ad0-43b6-b803-72b5d7151d3b:1).
Оскільки транзакції відбуваються на джерелі, UUID залишається незмінним, а ідентифікатор збільшується. Коли репліка обробляє транзакцію, GTID або діапазон GTID (наприклад, 14a54b2f-2ad0-43b6-b803-72b5d7151d3b:1-10) зберігається в таблиці gtid_executed.
Цей процес значно знижує ризик того, що дані втратять синхронізацію через необроблені або надмірно оброблені транзакції.
Режими реплікації для оптимальної конфігурації
MySQL пропонує два режими реплікації, які поводяться по-різному, і їх слід розуміти, щоб забезпечити оптимальну конфігурацію для вашого середовища.
За замовчуванням MySQL використовує асинхронну реплікацію, де транзакції надсилаються до джерела, зчитуються репліками й обробляються незалежно без перевірки джерела.
Крім того, MySQL підтримує напівсинхронну реплікацію, увімкнену як плагін. У цьому режимі транзакції приймаються джерелом та обробляються репліками, але джерело чекає, поки принаймні одна репліка прийме транзакцію, перш ніж відповісти. Напівсинхронна реплікація забезпечує більшу узгодженість даних, хоча й потрібен час на відповіді.
У режимі напівсинхронізації є додаткові параметри, які можна регулювати. За замовчуванням основний сервер чекає 10 секунд, поки репліка з увімкненим режимом напівсинхронізації підтвердить транзакцію.
Якщо узгодженість даних залежить від напівсинхронізації, подумайте про збільшення цього значення часу очікування, щоб забезпечити гарантовану узгодженість.
Важливо зазначити, що ці режими можна змішувати та поєднувати. Наприклад, ви можете налаштувати одну репліку з напівсинхронізацією, а іншу – без, гарантуючи, що один конкретний сервер завжди матиме актуальну копію вашої бази даних, тоді як інші репліки наздоганятимуть у своєму власному темпі. Цей підхід сприяє аварійному відновленню, легко визначаючи найкращого кандидата для відновлення.
Оптимізуйте репліки за допомогою окремого зберігання журналів
Копії екземплярів у вашому середовищі покладаються на бінарні журнали джерела для отримання точної інформації. За замовчуванням ці журнали зберігаються на тому ж диску, що й база даних. Однак таке налаштування може перевантажити бази даних. Щоб вирішити цю проблему, рекомендується зберігати бінарні журнали на окремому диску від бази даних.
Цей підхід забезпечує переваги продуктивності й економію коштів у хмарних середовищах, де безкоштовні томи мають суворі обмеження на IOPS.
Відстежуйте реплікацію та показники в керованих кластерах
Моніторинг має вирішальне значення для всієї інфраструктури, включючно з реплікацію. За допомогою моніторингу можна дізнатися, чи копіюються дані після налаштування.
Продуктивність бази даних SolarWinds (раніше VividCortex) і Prometheus є популярними рішеннями для моніторингу реплікації та інших показників у керованих кластерах.
Створіть план відновлення після відмови для мінімізації збоїв
Збої програмного або апаратного забезпечення вимагають планування відновлення. Використання реплікації забезпечує стійкість завдяки одночасному розміщенню ваших онлайн-даних на кількох серверах.
Процес відновлення після відмови може виглядати таким чином:
● Переконайтеся, що вимкнене джерело залишається в автономному режимі, щоб уникнути неочікуваних проблем із реплікацією.
● Визначте та видаліть параметр read_only із вибраної репліки, яка слугуватиме новим джерелом даних. Якщо використовується напівсинхронізація, виберіть репліку, попередньо налаштовану за допомогою плагіна і джерела.
● Оновіть свою програму, щоб спрямовувати запити до нещодавно рекламованого джерела.
● Змініть решту реплік, щоб розпочати реплікацію із нового джерела.
Оптимізація міжрегіональної реплікації
Хмарні провайдери зазвичай надають послуги в кількох географічних регіонах, що включають кілька центрів обробки даних. Тиражування баз даних у різних фізичних місцях рекомендовано, але вимагає ретельного розгляду.
Реплікація вводить додаткову затримку через відстань, яку мають подолати дані. На щастя, затримка в одному регіоні, як правило, низька, тоді як між регіонами існує значна затримка.
Для реплікації між регіонами слід використовувати асинхронний режим, щоб уникнути непотрібних затримок для програм, які надсилають запити.
Повне розуміння параметрів конфігурації реплікації має вирішальне значення. Однак не менш важливо визначити оптимальну конфігурацію для цих опцій. Це може значно вплинути на ефективність роботи кластера MySQL і можливості обслуговування даних.
Раніше ми повідомляли, що Oracle представила підтримку JavaScript у базі даних MySQL. Вона дає змогу розробникам писати програми на JavaScript всередині сервера бази даних MySQL.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
