Реплікація
У попередніх темах ми вже вивчили як налаштовувати резервне копіювання MySQL, щоб мати можливість відновити роботу системи та всі дані у разі неполадок. Звісно, навіть якщо ми й можемо відновити систему після збоїв, вони все одно небажані. Саме тому, з метою зменшення ймовірності збоїв, ми використовуємо реплікацію.
Розглянемо приклад. Уяви, що у тебе є один сервер бази даних, і ймовірність його виходу з ладу складає, наприклад, 10% (0.1). Якщо у тебе є два таких сервери бази даних, ймовірність того, що вони вийдуть з ладу одночасно, становить 10% * 10% (0.1 * 0.1 = 0.01). Отже, чим більше у нас серверів баз даних, тим менше ймовірність того, що всі вони одночасно вийдуть з ладу, і система перестане працювати.
💡 Реплікація — це процес, під час якого дані з одного сервера баз даних копіюються на один або кілька інших серверів. Різні системи керування базами даних по різному імплементують реплікації та підтримують ті чи інші типи реплікування. Основна мета реплікації: можливість використання більше одного сервера баз даних.
Асинхронне та синхронне реплікування
Реплікування можна поділити на асинхронне та синхронне ⬇️
При асинхронному реплікуванні операція запису даних у БД завершується відразу після того, як запис з’явиться на сервері, на якому виконувався запит. При цьому, копіювання цього запису на інші сервери відбувається у фоновому режимі. Недолік такого підходу полягає в тому, що якщо сервер, на якому здійснюється запис даних, вийде з ладу до того, як нові дані встигнуть реплікуватись, ці нові дані будуть втрачені.
На противагу асинхронному реплікуванню, при синхронному реплікуванні, операція запису триває доки запис не з’явиться на всіх серверах баз даних, які беруть участь у реплікації. Такий спосіб реплікації більш надійний, але й повільний, адже операція запису не завершиться, поки нові дані не з’являться на всіх серверах.
💡 Без встановлення додаткових плагінів, які не є частиною проєкту, MySQL підтримує лише асинхронну реплікацію. Тобто операція запису завершується тоді, коли дані записані на source server, а на репліки вони потрапляють вже потім, у фоновому режимі.
Active-active та active-passive реплікування
Реплікування також бувають active-active та active-passive ⬇️
При active-active реплікуванні всі сервери бази даних є рівноцінними. Запити зчитування і запису можна виконувати на будь-якому сервері баз даних, який бере участь в реплікації. Таку реплікацію важко реалізувати, а консолідація даних між репліками вимагає додаткових обчислювальних ресурсів.
Саме тому часто використовують простіший варіант — active-passive, при якому дані можна записувати лише на один головний сервер, який називається source. Інші сервери, які беруть участь в такому типі реплікації, називаються replicas — на них копіюються дані з source server, і їх можна використовувати для зчитування цих даних. Такий спосіб реплікації легше реалізувати, але він вимагає додаткових дій у випадку виходу з ладу головного серверу. Якщо таке трапиться, то потрібно, щоб головним сервером стала одна з реплік. Ця процедура називається fail-over.
💡 Формально MySQL підтримує як active-passive, так і active-active_конфігурацію, проте _active-active реалізація вважається ненадійною. Якщо один і той самий рядок оновити на обох репліках в active-active конфігурації, то між репліками може виникнути конфлікт: одна репліка матиме одну версію даних в цьому рядку, а інша — іншу.
❗️ На момент запису цього відео, MySQL немає механізму вирішення таких конфліктів. Саме тому, коли говорять про реплікацію в MySQL, найчастіше мають на увазі саме active-pasive реплікацію.
У реплікації баз даних є багато застосувань:
- Підвищення надійності системи. Чим більше серверів баз даних в нас є, тим менша ймовірність того, що система вийде з ладу.
- Розподілення обчислень для оптимізації ресурсів. Наприклад, завдяки реплікації можна виділити один сервер для запису даних, а інший лише для зчитування.
- Міграція, або перенесення бази даних з одного серверу на інший без значних простоїв системи. Якщо база даних велика, наприклад, 1 терабайт, то перенесення такої бази даних на інший сервер може зайняти дні, або навіть тижні. Завдяки реплікації можливо переносити дані з одного серверу на інший, і при цьому не зупиняти систему: дані копіюватимуться на фоні, а коли source і репліка остаточно синхронізуються, достатньо буде просто зробити _failover_для того, щоб остаточно перейти на новий сервер.
Налаштування реплікації — це окрема складна задача, яку зазвичай не потрібно виконувати самостійно коли твій застосунок в хмарі чи в Kubernetes. Проте дуже корисно знати як саме вона працює та які бувають види реплікації, щоб правильно побудувати систему, що її використовує.