Високодоступний словник бази даних: реплікація, відновлення, і RPO/RTO
Основний словник баз даних HA для адмініструвачів і інженерів баз даних: типи реплікації, концепції відключення, RPO, RTO, MTTR, кластеризація, консенсус і багато іншого — пояснено простою англійською мовою.
Архітектури високої доступності (HA) бази даних забезпечують, що дані залишаються доступними і коректними навіть при відмові компонентів. Незалежно від того, розробляєте ви системи HA, документуєте їх для аудиторів або пояснюєте компроміси у перегляді архітектури, вам потрібен цей словник. Цей посібник містить 50 термінів, що є основою надійності бази даних.
Основи доступності
Висока доступність (HA)
** Висока доступність ** — це здатність системи залишатися функціональною і доступною протягом великої частини часу — зазвичай 99, 9% (три дев’ ятки) або 99, 99% (чотири дев’ ятки) часу роботи.
| Availability | Annual downtime |
|---|---|
| 99% (two nines) | ~3.6 days |
| 99.9% (three nines) | ~8.7 hours |
| 99.99% (four nines) | ~52 minutes |
| 99.999% (five nines) | ~5.3 minutes |
Толерантність до помилок
** Відповідальність за помилки ** — це здатність продовжувати роботу правильно у разі помилок компонентів — без переривання роботи, але, щонайбільше, з погіршенням продуктивності.
«Наш кластер баз даних є збоївстійким — втрата одного вузла не викликає ніяких перерв; кластер продовжує обслуговувати читання і запис»
Resilience
** Устойчивость ** - это способность быстро восстанавливаться после сбоев. Устойчивая система отказывает, выявляет и восстанавливает — минимизируя действие окна.
Методи відновлення
Реконструкція (Reconstruction)
** RPO ** — максимально допустима кількість втрат даних, виміряна за часом. Якщо RPO = 1 година, система може терпіти втрати не більше ніж останньої години транзакцій.
«Наш RPO становить 15 хвилин — ми не можемо дозволити собі втратити більше 15 хвилин транзакційних даних в катастрофі»
** RPO визначає **: частоту резервування, синхронізацію реплікації, інтервал надсилання журналу транзакцій.
Реконструкція (Reconstruction)
** RTO ** — максимально прийнятний час відновлення служби після аварії. Якщо RTO = 4 години, система повинна бути знову в мережі протягом 4 годин після аварії.
«Наш RTO становить 1 годину — нам потрібно бути в змозі відновити базу даних протягом години після повної первинної невдачі»
** РТО визначає **: автоматизація відключення, стратегія резервування, готовність сайту до відновлення.
MTTR (Mean Time to Recovery) — середній час відновлення
** MTTR ** — середній час, який знадобиться на відновлення служби після аварії. KPI продуктивності для команд надійності.
«Цього кварталу MTTR для інцидентів з базами даних становить 34 хвилини — ми націлюємося на 20 хвилин до Q3»
MTBF (англ. Mean Time Between Failures) — середній час між помилками
** MTBF ** — середній час між послідовними помилками. Вищий MTBF = більш надійна система.
Реконструкція (Reconstruction)
** RLO ** — це мінімальний функціональний рівень служби, прийнятний під час або після відновлення, наприклад, режим тільки для читання, прийнятний під час відновлення записів.
Replication
Реплікація бази даних
** Реплікація ** — це процес зберігання копій даних на декількох серверах — для доступності, масштабованості (розподілу для читання) і відновлення після аварії.
Начальник / Майстер
** primary ** (раніше « master ») — це сервер, який приймає записи. Всі зміни даних спочатку переносяться до первинного.
Реплікація / Режим очікування / Додатковий
** репліка ** (або ** резервна ** або ** вторинна **) — це копія основної, яка отримує і застосовує зміни. Репліки можуть обслуговувати читання (репліки читання) або триматися у стані очікування лише для відключення (гарячий стан очікування).
Синхронна реплікація
У ** синхронній реплікації **, головний сервер чекає на підтвердження від принаймні однієї репліки перед підтвердженням виконання транзакції.
** Гарантії **: нульова втрата даних під час відключення (RPO = 0). ** Комбінація **: збільшується затримка запису; якщо репліка повільна, повільним буде і головне.
«Ми використовуємо синхронну реплікацію між AZs — ми приймаємо трохи більшу затримку запису в обмін на нуль-RPO відключення.»
Асинхронна реплікація
У ** асинхронній реплікації **, головний запис виконується негайно, без очікування на реплікацію. Реплика наздоганяє на задньому плані.
** Гарантії **: нижча затримка запису; можлива певна втрата даних під час відключення (RPO > 0). ** Комбінація **: репліка може відставати від первинної.
«Крос-регіональна реплікація є асинхронною — мережева затримка робить синхронну реплікацію непрактичної. Наш крос-регіональний RPO ~30 секунд»
Затримка реплікації
** Затримка реплікації ** — це затримка між записом на головний диск і його появою на реплікації. Контролюється як ключова метрика. Надмірне затримування = ризик застарілих читань і більший RPO під час відключення.
«Replica lag spiked to 4 hours during the incident — reports using the read replica showed 4-hour-old data.» (англійською)
Реплікація потоку
** Реплікація потоком** безперервно передає потоком записи журналу передзапису (WAL) з первинного на резервний в майже реальному часі. Використовується PostgreSQL для резервування HA.
Логічна реплікація
** Логічна реплікація ** реплікує певні таблиці на логічному (зміна рядка) рівні — це більш гнучке, ніж фізична/ потокова реплікація. Увімкнути реплікацію між основними версіями або часткову реплікацію вибраних таблиць.
Failover
Failover
** Відновлення роботи після аварії ** — це процес перемикання потоку даних бази даних з пошкодженого головного на резервний, у результаті чого резервний стає новим головним.
Автоматичне відключення
** Автоматично відключення при відключенні ** визначає помилку первинного пристрою і переходить у режим очікування без втручання людини. Вимагає надійного виявлення помилок і механізмів консенсусу.
«Ми налаштували автоматичне відключення — якщо первинний не відповідає протягом 30 секунд, резерв автоматично підвищується»
Ручне відключення
** Ручне відключення при відмові ** потребує, щоб людина почала перехід з резервного на основний. Вищий RTO ніж автоматичне відключення.
Розділений мозок
** Розділений мозок ** — це небезпечний стан, коли два вузли кластера вважають, що вони є основними, зазвичай, це відбувається через розділ мережі. Може призвести до розбіжностей і пошкодження даних.
Захищено: Fencing, механізми кворуму/консенсусу, STONITH.
1999 — «Стреляй в голову» (англ. Shoot the Nose)
** Fencing ** запобігає розділенню мозку за допомогою ізоляції або примусового вимкнення вузла, який більше не має бути основним, перед підвищенням до нового основного. « STONITH » — це запам’ ятовуваний акронім для цього шаблону.
Quorum
** Кворум ** — це мінімальна кількість вузлів, які мають погодитися, щоб кластер міг прийняти рішення (пропозиція, прийняття запису). 3- вузловий кластер з кворумом 2 може пережити один вузол.
Консенсусний протокол
** Протоколи консенсусу ** (Raft, Paxos) забезпечують, що всі вузли погоджуються на один і той же стан. Використовується розподіленими базами даних (CockroachDB, etcd, Patroni для PostgreSQL) для керування виборами лідерів і послідовністю даних.
Топологічні шаблони
Горячий резерв
** Режим очікування** — це репліка, яка працює, синхронізується і готова приймати з’ єднання одразу після підвищення рівня. Мінімальний RTO.
Гаряча готовність
** гаряча черга ** запущена і отримує реплікацію, але не приймає з’ єднань. Вимагає виконання кроків запуску і підвищення рівня перед обслуговуванням трафіку.
Холодний резерв
** Холодний режим очікування ** — це сервер, який не запущено — для того, щоб він міг обслуговувати трафік, його слід запустити, відновити резервну копію і наздоганяти. Найвищий RTO.
Multi-AZ (зона багаторазової доступності)
Multi-AZ розгортає первинний і резервний в різних зонах доступності (фізично відокремлені центри даних в регіоні). Захист від пошкоджень рівня AZ з автоматичним відключенням.
«Наша інстанція RDS є Multi-AZ — якщо AZ, що містить первинну, впаде, AWS автоматично переходить в режим очікування в іншому AZ протягом 60-120 секунд»
Прочитайте репліку
** Репліка читання ** це репліка, налаштована для обслуговування запитів SELECT — перевантаження трафіку читання з первинного.
«Ми маємо три репліки читання, що обслуговують наші запити звітності — основна обробляє тільки записи і критичні операційні читання»
Активно-активно
** Активна- активна ** реплікація означає, що декілька вузлів приймають запис одночасно, з механізмами розв’ язання конфліктів. Найвища доступність і пропускна здатність, але найскладніше для правильної реалізації.
Активно-пасивний
** Активний- пасивний ** означає, що один з основних приймає записи; резервні є пасивними (відбувається реплікація, але не приймаються записи). Простіше розуміти; відключення вимагає підвищення.
Резервне копіювання і відновлення
Повне резервування
** Повна резервна копія ** — це повна копія бази даних у певний момент часу.
Резервне копіювання
** Приростова резервна копія ** зберігає лише зміни, внесені з моменту останньої резервної копії — вона менша і швидша, але для відновлення потрібно повна резервна копія і всі приростові копії.
WAL (журнал попереднього запису) / журнал транзакцій / журнал повторення
Рушії баз даних використовують ** журнал попереднього запису (WAL) ** — зміни транзакцій записуються в журнал перед тим, як застосовуються до файлів даних. WAL вмикає PITR і реплікацію.
Підтримка точки-в-часі (Point-in-Time Recovery)
** PITR ** — це можливість відновлення бази даних до будь- якої певної точки часу у вікні зберігання резервної копії — за допомогою бази резервних копій плюс повторення WAL.
«Ми мали поганий запит DELETE, який був запущений о 14:30 — ми використовували PITR, щоб відновити базу даних до 14:29, відновлюючи всі видалені записи»
Корисні фрази
** Обговорення RPO/RTO в проектуванні: **
-
- “При нульовому RPO і RTO менше 60 секунд нам потрібна синхронна реплікація Multi- AZ з автоматичним відключенням.” *
** Пояснення відключення: **
- “Первинна помилка сталася о 09:43 UTC. Автоматичний відключення підвищив режим очікування на 09:44 — 61 секунду всього. Всі з’єднання були автоматично перенаправлені.”
** Пояснення затримки реплікації: **
-
- “Затримка реплікації зараз становить 45 секунд — у межах нашого RPO- цілі 1 хвилина. Ми будемо стежити за ним через набір вантажу.”*
Practice
Поглибте свій словниковий запас з ** Набір вправ з адміністрування баз даних. Name ** і ** ДБЯ навчальний шлях **.