Що ми робимо · Дані та web: Реплікація баз даних і репліки на іншому майданчику

Постійно оновлювана копія вашої продуктивної бази даних лише для читання, що працює на іншому майданчику, де звіти можна виконувати, не торкаючись продуктиву, і куди ви можете перемкнутися, якщо основний майданчик колись буде втрачено. Побудована так, що репліка сама звертається за змінами, а продуктив ніколи не має шляху до неї.
Що це
Асинхронна реплікація MySQL або MariaDB, де репліка розміщена там, куди інша відмова не дістане: інший дата-центр, інший масив сховища, інший мережевий шлях. Репліка йде за основним сервером майже в реальному часі й виконує три роботи одночасно:
- Копія для аварійного відновлення (disaster recovery) даних, актуальна з точністю до секунд.
- Ціль для звітності та інтеграцій, щоб важкі завдання читання перестали конкурувати з вашими клієнтами.
- Чисте джерело для резервних копій, які знімаються без блокування чи сповільнення основного сервера.
Як ми це будуємо
Репліка забирає. З’єднання реплікації відкриває репліка, ніколи навпаки. Продуктив не має мережевого шляху на бік репліки, і це забезпечується на firewall-пристроях, а не правилом на хості, яке хтось може вимкнути. Якщо продуктивний сервер колись буде скомпрометовано, зловмисник не матиме маршруту до копії, з якої ви б відновлювалися.
Через нашу приватну мережу. Репліки на іншому майданчику подорожують нашим шифрованим приватним backbone між нашими дата-центрами в Афінах, Амстердамі та Торонто, ніколи відкритим текстом через публічний інтернет.
На основі GTID. Ми використовуємо глобальні ідентифікатори транзакцій, тому репліку можна перенаправити, підвищити до основної або переналити, і нікому не доведеться шукати координати бінарного журналу о третій ночі.
Моніторинг за станом, а не за шумом. Перевірка виконується кожні п’ять хвилин і надсилає одне сповіщення при зміні стану: відставання понад поріг, обрив або відновлення. Інженери отримують сигнал, на який реагують, а не потік, який вчаться ігнорувати.
Від чого це вас захищає
- Втрата цілого майданчика, а з ним і єдиної копії ваших даних.
- Звітні запити й інтеграції, що сповільнюють базу даних, якою користуються ваші клієнти.
- Репліка, яка тихо зупинилася кілька тижнів тому і яку виявляють лише в день, коли вона потрібна.
- Зловмисник на продуктивному сервері, що дістається копії, з якої ви б відновлювалися.
- Резервні копії, що блокують таблиці або гальмують основний сервер під час виконання.
На практиці
Переїзд телекомпанії з VMware. Коли ми відбудовували web-платформу національної телекомпанії на нашому private cloud на OLVM, база даних була єдиним рівнем зі станом, який варто було переносити. Вона переїхала реплікацією за GTID зі старої платформи на нову, тож сам cutover був підвищенням репліки з різницею в лічені секунди. Cutover завершився кілька місяців тому, і платформа відтоді працює на нашому боці.
Репліки, що обслуговують нові застосунки. Репліка для читання є також найчистішим способом поставити новий пошук, звітність або портал поверх наявної системи: новий застосунок читає зі швидкістю локальної мережі й ніколи не торкається основного сервера під час завантаження сторінок. Ми будуємо їх так, що ініціатором є репліка, тому хост із реплікою не потребує жодного вхідного правила firewall.
Чому EuroVPS
- Репліки живуть на справді іншому майданчику, з’єднаному нашим власним шифрованим backbone.
- Лише pull, що забезпечує firewall: продуктив ніколи не може дістатися боку репліки.
- Сповіщення про зміну стану кожні п’ять хвилин, які інженери читають цілодобово.
- GTID наскрізь, тому підвищення й переналивання є відрепетируваними процедурами.
- Та сама команда будує репліку, резервні копії та план failover, тому вони пасують одне до одного.
Часті запитання
- Наскільки відставатиме репліка? За звичайного навантаження секунди або менше. Ми сповіщаємо, коли відставання перетинає поріг, який погоджуємо з вами, а RPO, який ви отримуєте, відповідає замовленій послузі.
- Чи можемо ми перемкнутися на репліку? Так. Підвищення є задокументованою процедурою. Як швидко за ним підуть застосунки, залежить від дизайну послуги: від ручного підвищення для базової послуги до автоматизованого, відрепетируваного перемикання для послуг із глобальним покриттям.
- Чи може наш інструмент звітності підключатися до неї? Так, з обліковим записом лише для читання. Це одна з головних причин її мати.
- Чи замінює вона резервні копії? Ні. Репліка копіює помилки так само вірно, як і дані. Резервні копії знімаються поруч із нею й забираються на окрему інфраструктуру.
- MySQL чи MariaDB? Обидві. Ми узгоджуємо рушій і налаштування репліки з основним сервером.
Хочете копію ваших даних, до якої не дістане поганий день? Поговоріть з інженером.
Ваш наступний партнер з інфраструктури
Погляньмо на вашу інфраструктуру.
Розкажіть, що ви запускаєте сьогодні і що потребує покращення. Інженер розгляне ваш запит і допоможе спланувати наступний крок.
+357 222 32280
Почнімо з вашої інфраструктури.
Трохи контексту допомагає нам почати правильну розмову.
