added theory bd replication
This commit is contained in:
Dmitry Medvedev
@@ -0,0 +1,94 @@
|
||||
- Задание 1. Где и зачем понадобится репликация
|
||||
|
||||
На примере онлайн‑магазина описать 3 конкретные ситуации, в которых репликация базы данных помогает:
|
||||
|
||||
- защититься от падения сервера;
|
||||
НОЧЬЮ СЕРВЕР ПАДАЕТ ИЗ-ЗА СКАЧКА НАПРЯЖЕНИЯ, САЙТ ПАДАЕТ, ИДЕТ ПОТЕРЯ ЗАКАЗОВ.
|
||||
БЕЗ РЕПЛИКАЦИИ МОЖНО ЗАПУСТИТЬ ВОССТАНОВЛЕНИЕ , НО ЧАСТЬ ЗАКАЗОВ БУДЕТ ВСЕ РАВНО ПОТЕРЯНА, ПОСТРАДАЕТ РЕПУТАЦИ, УЙДЕТ ВРЕМЯ НА ВОССТАНОВЛЕНИЕ ИНФОРМАЦИИ.
|
||||
С РЕПЛИКАЦИЕЙ МЕНЯЕТСЯ ПОТОК ДАННЫХ, МАСТЕР СТАНОВИТСЯ РЕПЛИКОЙ, А РЕПЛИКА МАСТЕРОМ - ДАННЫЕ ПИШУТСЯ НА ЗАПАСНОЙ СЕРВЕР, В ДАННОМ СЛУЧАЕ ПОТЕРИ ДАННЫХ МИНИМАЛЬНЫ.
|
||||
|
||||
- разгрузить чтение;
|
||||
НАБЛЮДАЕТСЯ НАПЛЫВ КЛИЕНТОВ, НАПРИМЕР ИЗ-ЗА СКИДОК.
|
||||
БЕЗ РЕПЛИКАЦИИ ОДИН СЕРВЕР ОБРАБОТЫВАЕТ ВСЕ, ЗАПРОСЫ ТОРМОЗЯТ РАБОТУ СИСТЕМЫ, САЙТ ПАДАЕТ.
|
||||
С РЕПЛИКАЦИЕЙ МОЖНО РАСПРЕДЕЛЕИТЬ ОБЯЗАННОСТИ, НАПРИМЕР, КАКИЕ-ТО СЕРВЕРЫ ТОЛЬКО ЧИТАЮТ, КАКИЕ-ТО ЗАПИСЫВАЮТ.
|
||||
|
||||
- делать отчёты без влияния на основную базу;
|
||||
ОТДЕЛУ НУЖЕН 1 РАЗ В НЕДЕЛЮ ОТЧЕТ ПО ПРОДАЖАМ И ТП.
|
||||
БЕЗ РЕПЛИКАЦИИ СЕРВЕР ЗАГРУЖЕН ДАННЫМИ И САЙТ ТОРМОЗИТ У КЛИЕНТОВ.
|
||||
С РЕПЛИКАЦИЕЙ ОТЧЕТ ФОРМИРУЕТСЯ НА РЕПЛИКЕ, А КЛИЕНТЫ РАБОТАЮТ ЧЕРЕЗ МАСТЕРА.
|
||||
|
||||
- обновлять версию СУБД без простоя и т.п.
|
||||
МЕНЯЕТСЯ ВЕРСИЯ СУБД ПО КАКИМ-ТО ПРИЧИНАМ.
|
||||
БЕЗ РЕПЛИКАЦИИ ПРИДЕТСЯ ОСТАНОВИТЬ БД И ЖДАТЬ МИГРАЦИИ, А ЭТО ЗНАЧИТ ПОТЕРЯ ТРАФИКА И ЗАКАЗОВ.
|
||||
С РЕПЛИКАЦИЕЙ ВСЕ ПРОЩЕ, ДЕЛАЕМ РЕПЛИКУ НА НОВОЙ ВЕРСИИ , НАСТРАИВАЕМ МИГРАЦИЮ С МАСТЕРА НА НОВУЮ РЕПЛИКУ. ДЕЛАЕМ НОВУЮ РЕПЛИКУ МАСТЕРОМ, СТАРЫЙ МАСТЕР СТАНОВИТСЯ БЭКОМ.
|
||||
|
||||
Для каждой ситуации объяснить: что было бы без репликации и как её наличие меняет картину.
|
||||
|
||||
- Задание 2. Сравнение синхронной и асинхронной репликации
|
||||
|
||||
Сформулировать своими словами различия между синхронной и асинхронной репликацией:
|
||||
Асинхронная подразумевает "параллельную" запись между мастером и слэйвом, а синхронная когда слэйв делает запись , а мастер в это время ждет пока слэйв подтвердит запись.
|
||||
|
||||
- как ведёт себя запись при нормальной работе;
|
||||
ПРИ АСИНХРОННОЙ ЗАПИСЬ ИДЕТ В ЖУРНАЛ, ДАЛЕЕ НА МАСТЕР И ТОЛЬКО ПОТОМ НА СЛЭЙВЫ. СУЩЕСТВУЕТ ЗАДЕРЖКА И ПРОБЛЕМА ПОТЕРИ ДАННЫХ.
|
||||
ПРИ СИНХРОННОЙ ЗАПИСЬ ИДЕТ В ЖУРНАЛ. ДАЛЕЕ МАСТЕР И СЛЭЙВЫ ЗАПИСЫВАЮТ ПАРАЛЛЕЛЬНО.
|
||||
|
||||
- что происходит при падении мастера;
|
||||
АСИНХРОННАЯ. ДАННЫЕ МОГУТ ИСЧЕЗНУТЬ.
|
||||
СИНХРОННАЯ. СЛЭЙВ СМОЖЕТ ЗАМЕНИТЬ МАСТЕРА.
|
||||
|
||||
- какие риски потери/отставания данных есть.
|
||||
ПРИ АСИНХРОННОЙ ЕСТЬ РИСК ПОТЕРИ ДАННЫХ.
|
||||
ПРИ СИНХРОННОЙ РИСКИ ПОТЕРИ МИНИМАЛЬНЫ, ТАК КАК МАСТЕР ЖДЕТ ОТВЕТА ОТ СЛЭЙВА И В ЛЮБОЙ ЧЕГО СЛЭЙВ МОЖЕТ ЗАМЕНИТЬ МАСТЕРА.
|
||||
|
||||
После этого выбрать тип репликации для двух систем: платёжный сервис и аналитическая витрина, и обосновать выбор.
|
||||
ПЛАТЕЖНЫЙ СЕРВИС СИНХРОННАЯ, ЧТОБЫ ВО ВСЕХ БД БЫЛИ ОДИНАКОВЫЕ ДАННЫЕ В ЛЮБОЙ МОМЕНТ ВРЕМЕНИ.
|
||||
ДЛЯ ВИТРИНЫ НЕ ТАК ВАЖНО ЧТОБЫ ДАННЫЕ БЫЛИ И ТАМ И ТАМ ОДНОВРЕМЕННО. АСИНХРОННАЯ.
|
||||
|
||||
- Задание 3. Логическая и физическая репликация
|
||||
|
||||
Объяснить, чем логическая репликация отличается от физической:
|
||||
|
||||
- на каком уровне передаются изменения;
|
||||
ЗАТРУДНЯЮСЬ ОТВЕТИТЬ НА ДАННЫЙ ВОПРОС.
|
||||
|
||||
- насколько гибко можно выбирать, какие таблицы и данные реплицировать;
|
||||
ЗАТРУДНЯЮСЬ ОТВЕТИТЬ НА ДАННЫЙ ВОПРОС.
|
||||
|
||||
- как это влияет на возможность миграций между версиями/схемами.
|
||||
ЗАТРУДНЯЮСЬ ОТВЕТИТЬ НА ДАННЫЙ ВОПРОС.
|
||||
|
||||
Придумать по одному сценарию, где логическая репликация удобнее, и где физическая проще и надёжнее.
|
||||
ЗАТРУДНЯЮСЬ ОТВЕТИТЬ НА ДАННЫЙ ВОПРОС.
|
||||
|
||||
- Задание 4. Схема один мастер — несколько реплик для чтения
|
||||
|
||||
Представить, что есть один главный сервер (мастер) и две реплики только для чтения.
|
||||
|
||||
Нужно описать:
|
||||
|
||||
- какие типы запросов в интернет‑магазине должны ходить строго на мастер, а какие можно смело отправлять на реплики;
|
||||
НА РЕПЛИКИ МОЖНО ЧТЕНИЕ ВИТРИН, НА МАСТЕРЕ ЗАПРОСЫ "РЕАЛЬНОГО ВРЕМЕНИ", НАПРИМЕР, ЗАКАЗЫ ПОЛЬЗОВАТЕЛЕЙ.
|
||||
|
||||
- какие проблемы могут возникнуть из‑за того, что реплики иногда отстают на несколько секунд;
|
||||
В МОМЕНТЕ МОЖЕТ ВОЗНИКНУТЬ СИТУАЦИЯ, ЧТО ДАННЫЕ НЕ СХОДЯТСЯ, ПРОБЛЕМА СХОДИМОСТИ.
|
||||
|
||||
- как в коде можно уменьшить риск багов из‑за отставания (например, после критичных операций записи).
|
||||
|
||||
|
||||
- Задание 5. Мульти‑мастер: когда это оправдано
|
||||
|
||||
Рассмотреть схему, где несколько узлов базы могут принимать запись (multi‑master).
|
||||
|
||||
Нужно:
|
||||
|
||||
- перечислить главные плюсы по сравнению со схемой «один мастер — много реплик»;
|
||||
СКОРОСТЬ, ВСЕ УЗЛЫ МОГУТ ДЕЛАТЬ ЗАПИСЬ.
|
||||
В ОСНОВНОМ МИНУСЫ КОГДА ВЕДЕТСЯ ОДНА БД НЕСКОЛЬКИМИ МАСТЕРАМИ.
|
||||
|
||||
- перечислить основные сложности: конфликты, согласованность, сложность настройки;
|
||||
ДА, КОГДА НЕСКОЛЬКО МАСТЕРОВ МОГУТ ВОЗНИКАТЬ КОНФЛИКТЫ. ПРИ РЕГИСТРАЦИИ ПОЛЬЗОВАТЕЛЯ ОДИН МАСТЕР ДЕЛАЕТ ЗАПИСЬ УНИКАЛЬНОГО АЙДА, ДРУГОЙ МАСТЕР НЕ ЗНАЕТ О ПЕРВОЙ ЗАПИСИ И ТОЖЕ ПРОИЗВОДИТ ТОЖЕ САМОЕ, НО АЙДИШНИК УЖЕ ЗАДАН И ЗДЕСЬ МОЖЕТ ПОЯВИТЬСЯ ДУБЛИКАТ.
|
||||
|
||||
- придумать пример системы, где мульти‑мастер даёт реальную пользу, и пример, где такая схема только усложнит архитектуру без заметного выигрыша.
|
||||
МУЛЬТИ МАСТЕРЫ ДАЮТ РЕАЛЬНУЮ ПОЛЬЗУ В ПРОЕКТАХ РАЗБРОСАННЫХ ПО ВСЕМУ МИРУ, НАПРИМЕР ЭТО СЕТЬ МАГАЗИНОВ, В КАЖДОМ МАГАЗИНЕ БУДЕТ СВОЙ МАСТЕР, КАЖДЫЙ МАСТЕР ВЕДЕТ СВОЙ WAL ЖУРНАЛ И ЗАПИСЫВАЕТ ТУДА ДАННЫЕ, ПОТОМ ПРОСТО ПРОИСХОДИТ СИНХРОНИЗАЦЯ МЕЖДУ МАСТЕРАМИ.
|
||||
УСЛОЖНИТ ТАКАЯ СХЕМА АРХИТЕКТУРУ В ОДНОМ ИНТЕРНЕТ-МАГАЗИНЕ, НАПРИМЕР, С ОДНИМ СЛАДОМ, МОЖЕТ СОЗДАВАТЬСЯ КОНФЛИКТЫ.
|
||||
Reference in New Issue
Block a user