Що ми робимо · Дані та web: Кластерні бази даних на Percona XtraDB Cluster
Ваш застосунок звертається до однієї бази даних, але за нею стоять три синхронні копії, кожна на окремому обладнанні. Підтверджений запис існує на кожному вузлі ще до того, як ваш застосунок почує «OK», тому втрата сервера, його оновлення чи перезавантаження є рутинною роботою, а не збоєм.
Що це
Percona XtraDB Cluster сумісний із MySQL і побудований на синхронній реплікації Galera. Ваш WordPress, Magento, PrestaShop, Laravel або власний PHP-застосунок далі говорить звичайною MySQL. Змінюється те, що під сподом: не залишається єдиного сервера бази даних, відмова якого забирає з собою весь сайт.
Ми поєднуємо кластер із ProxySQL, який надсилає записи на один обраний вузол і розподіляє читання між усіма. Застосунку не потрібні ані зміни, ані знання топології.
Як ми це будуємо
- Три вузли, три домени відмов. Кожен вузол працює на власному blade або віртуальній машині, і там, де платформа дозволяє, кожен завантажується з іншого масиву сховища та зберігає на ньому свої дані. Відмова хоста чи масиву коштує одну репліку, ніколи не кворум.
- ProxySQL як локальний sidecar на кожному web-вузлі. Немає спільного балансувальника бази даних, який став би наступною єдиною точкою відмови. Монітор стану ProxySQL, що розуміє Galera, відстежує стан кластера, і якщо writer зникає, за лічені секунди призначає новий.
- Причинно узгоджені читання для редакторів. Ми вмикаємо синхронні перевірки читання, щоб редактор, який зберіг на одному вузлі й перезавантажив сторінку з іншого, завжди бачив власну зміну. Жодних тікетів «моя стаття зникла».
- Простір для повернення. Кеш наборів записів розрахований так, що вузол може бути офлайн годинами обслуговування й повернутися інкрементально, замість копіювати весь набір даних заново.
- Резервні копії кожні тридцять хвилин. Percona XtraBackup робить гарячі, узгоджені фізичні резервні копії, які стискаються й забираються на окремий резервний хост. Продуктивна сторона ніколи не надсилає нічого в інфраструктуру резервного копіювання.
- Під постійним наглядом. Кожен вузол підключений до Percona Monitoring and Management.
В OpenShift діють ті самі правила (h3)
Коли база даних працює в OpenShift або OKD, вона запускається як StatefulSet із жорсткою anti-affinity між шасі та PodDisruptionBudget, що зберігає кворум. Поступове перезавантаження вузлів під час оновлення платформи тоді ніколи не може вивести з ладу більше одного члена бази даних одночасно. Це стандарт дизайну, за яким ми будуємо на кожній контейнерній платформі, а не опція.
Від чого це вас захищає
- Класичний збій: увесь сайт лежить, бо лежить єдиний сервер MySQL.
- Шторми взаємних блокувань від запису на всі вузли одразу, які наївні round-robin-схеми породжують під навантаженням плагінів WordPress та e-commerce.
- Редактори, що втрачають збереження, бо наступне читання потрапило на вузол, який ще його не застосував.
- Вікна обслуговування для оновлень ядра, патчів бази даних і робіт з обладнанням.
- Масив сховища або шасі, що забирає базу даних із собою.
- Поступове оновлення Kubernetes, яке непомітно ламає кворум.
На практиці
Аналітична платформа. Для аналітичної та транзакційної платформи клієнта ми побудували транзакційний рівень на Percona XtraDB Cluster із ProxySQL і плаваючою адресою. Перед передачею ми навмисно вимкнули writer; ProxySQL переніс записи на вцілілий вузол, і застосунок продовжив працювати.
Чому EuroVPS
- Ми проєктуємо домени відмов, а не лише кластер: різні хости, різні масиви, різні шасі.
- Жодного спільного проксі бази даних посередині. Кожен web-вузол маршрутизує власні запити.
- Резервні копії фізичні, часті й забираються стороною резервного копіювання, ніколи не надсилаються з продуктиву.
- Ми тестуємо failover перед передачею, із запущеним застосунком клієнта.
- Та сама дисципліна на віртуальних машинах, bare metal та OpenShift.
Часті запитання
- Чи потрібно нам змінювати застосунок? Ні. ProxySQL виглядає як звичайна кінцева точка MySQL. Застосунки, що пишуть у нетранзакційні таблиці або покладаються на незвичні блокування, ми спершу розглядаємо разом із вами.
- Це сумісно з MySQL чи MariaDB? Percona XtraDB Cluster є сервером, сумісним із MySQL. Ми мігруємо на нього бази даних MySQL і MariaDB та перевіряємо кодування, плагіни автентифікації й режими SQL під час переїзду.
- Чи робить синхронна реплікація на три вузли записи повільнішими? Кожен commit чекає, доки інші вузли його сертифікують, тож затримка між вузлами має значення. Саме тому всі члени розміщені в одній fabric з низькою затримкою в одному дата-центрі, а копії на іншому майданчику забезпечують асинхронні репліки.
- Чи можемо ми запустити це всередині OpenShift? Так, як StatefulSet із anti-affinity між шасі та PodDisruptionBudget, що є нашим стандартом для будь-якої бази даних на основі кворуму в Kubernetes.
- Що відбувається під час відмови вузла? Вцілілі вузли зберігають кворум і далі обслуговують запити. ProxySQL маршрутизує в обхід відсутнього вузла, а коли той повертається, він наздоганяє інкрементально.
Хочете базу даних, яка витримує втрату сервера? Поговоріть з інженером.
Ваш наступний партнер з інфраструктури
Погляньмо на вашу інфраструктуру.
Розкажіть, що ви запускаєте сьогодні і що потребує покращення. Інженер розгляне ваш запит і допоможе спланувати наступний крок.
+357 222 32280
Почнімо з вашої інфраструктури.
Трохи контексту допомагає нам почати правильну розмову.