mnoskov
40 lines
8.3 KiB
SQL
40 lines
8.3 KiB
SQL
-- Задание 1. Где и зачем понадобится репликация
|
|
-- На примере онлайн-магазина
|
|
-- Пример 1: мастер сервер перестал работать(по любым причинам), и чтобы не останавливать работу магазина - делаем реплику мастером. Если бы небыло репликации работа магазина приостановилась бы на какое время.
|
|
-- Пример 2: на мастер сервере даже без чтения высокая нагрузка с инсертами, апдейтами, а чтение происходит с реплики, например отчеты для аналитиков читаются с реплики чтобы не перегружать мастер. Если убрать репликацию, то сервер будет один и может перегрузиться и упасть.
|
|
-- Пример 3: я сдеал первыве два примера настоллько обобщенными, что они покрываются все более конкретные примеры, и я не могу придумать пример 3.
|
|
|
|
|
|
-- Задание 2. Сравнение синхронной и асинхронной репликации
|
|
-- * как ведёт себя запись при нормальной работе;
|
|
-- * синхронная репликация - мастер ждет пока реплика завершит копирование, наверное блокирует строку в таблице как в тарнзакции строка блокируется пока транзакция не завершится.
|
|
-- * асинхронная репликация - мастер ничего не ждет - его главная задача, что он отправил даные в реплику, и реплика уже пусть сама разбирается и сохраняетс всё.
|
|
-- * что происходит при падении мастера;
|
|
-- * я думаю при обоих видах репликаций - реплика становится мастером.
|
|
-- * какие риски потери/отставания данных есть.
|
|
-- * с синхронной - рисков с отставанием и потерями вроде нет.
|
|
-- * в случае с асинхронной - реплика может не успеть сохранить что-то одно, как придет уже что-то второе в туже строку например, или может произойти какой-то сбой, и данные прийдут некорректно - получается транзакция просто не откатится, а будет как будет.
|
|
|
|
-- платежному сервису нужен синхронный вид репликации, тк ошибки и неточность недопустимы.
|
|
-- аналитической витрины нужен асинхронный вид репликации, тк он быстрее, и небольшая неточность не критична.
|
|
|
|
|
|
-- Задание 3. Логическая и физическая репликация
|
|
-- * думаю логическая репликация это больше про то, что мы видим и делаем сами, по типу sql запрос написать, а физическая репликация - это про то, что происходит на уровне субд/сервера, что данные перетекают байтах, WAL-журналов(я погуглил что-это - это грубо говоря план изменений, но пока не сами изменения)
|
|
-- Оказывается про логические физические репликации я тоже ничего не понял, сейчас прогуглю, и напишу ответ заново.
|
|
-- * у логической репликации изменения передаются как sql запросы, для отдельных талиц например, а физическаая репликация изменяется побайтово создавая полную копию мастера
|
|
-- * у логической репликации высокая гибкость, можно выбирать что обновлять, а что нет, а у физической репликации нулевая гибкость - создается просто копия мастера 1 в 1
|
|
-- * как я понял для миграция лучше всего логическая репликация - тк высокая гибкость, а физическая подходит для резервной копии
|
|
|
|
-- * для физической репликации - банковская система, тк физичская быстрее и копия 1 в 1 делается, а для логическрй репликации я не могу ничего придумать.
|
|
|
|
|
|
-- Задание 4. Схема один мастер — несколько реплик для чтения
|
|
-- * на мастер отправлять строго unsrt update delete только с изменениями, а на реплики select, только с чтением
|
|
-- * проблемы из-за отсавания: 1. пользователь обновил фото профиля, а изменилось оно на странице толькко через 1-2 минуты; 2. один пользователь купил последний товар, а реплика не успела обновиться, и другой пользователь тоже попытался заказать этот товар, и у него вылезла ошибка, получается что товар отображается в наличии а купить нельзя; 3. в банках если будут отставать то там вообще жопа будет со счетами, но там получается синхронная репликация.
|
|
-- * наверное можно закрыть доступ на изменения для строк которые ещё не до конца реплицировались
|
|
|
|
-- Задание 5. Мульти‑мастер: когда это оправдано
|
|
-- * главные плюсы: 1. распределение нагрузки между серверами 2. каждая мастер репликация отвечает только за свою зону ответсвенности
|
|
-- * сложности: 1. конфликты, что на разных мульти репликах могут быть разные записи по одному и тому же значению и будет не ясно что важнее оставить; 2. согласованность - кадая мульти реплика должна работать только в пределах своей зоны ответственности; 3. сложность настройки - я думаю имеется ввиду защита от конфликтов и поддержка согласованности.
|
|
-- * у меня в голове только мысль о разделении отвественности по хэшу, что одна мастер реплика отвечает за один кусок, другая за другой, по типу шардирования, только без деления таблиц, они как бы и дальше между собой реплицируются, но каждая изменят обновляет и делает записи только на своем куске. Наверное такой способ поможет при больших таблицах с частыми изменениями(хотя по суть шардирование лучше испольщовать тогда, а не мульти-мастер). Неэффективно будет на таблицах с редкими изменениями, и не очень больших таблицах. |