9.5 KiB
| aliases | tags | date | zero-link | parents | linked | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
Тезисы
- Репликация это копирование измененных данных с одного сервера БД на другой.
- Не отменяет первоначального копирования БД. Сначала нужно первый раз скопировать данные, а потом уже запустить репликацию.
- Репликация не является резервной копией БД.
- Обычно реализуются на базе ../../database/Журнал БД.
- Плюсы:
- Помогает улучшить High Availability. Помогает при падении.
- Ускоряет чтение данных
- Проблемы:
- Не ускоряет запись в БД
- Отставание реплики БД
- Монотонное чтение
- Репликация это ресурсозатратно.
- Репликации БД:
Репликация позволяет сделать N копий одной БД. Обычно есть одна ведущая копия, которую называют master, и есть N ведомых реплик, которые называют slaves.
Репликация не отменяет первоначального копирования БД. Сначала нужно первый раз скопировать данные, а потом уже запустить репликацию.
Для чего делают репликацию?
- ../../../../../_inbox/High Availability. Если один сервер выходит из строя, другие реплики продолжают обслуживать запросы, обеспечивая непрерывный доступ к данным.
- Масштабирование чтения. Нагрузка на чтение может быть распределена между несколькими репликами, что улучшает производительность системы.
- Распределение нагрузки. Сложные аналитические запросы для построения отчетов и асинхронное резервное копирование БД могут выполняться на отдельных репликах, не нагружая основной сервер.
- Географическое распределение. Реплики могут быть размещены ближе к пользователям в разных регионах, уменьшая задержки доступа к данным.
Недостатки репликации:
- Не позволяет получить увеличение производительности запросов на вставку данных. Для этого нужно использовать ../../../../../_inbox/Шардирование БД.
- Сложность управления. Управление несколькими репликами требует дополнительных ресурсов и сложной конфигурации. Это включает настройку синхронизации данных, мониторинг состояния реплик и управление конфликтами.
- Ресурсозатратность. Поддержание нескольких копий данных требует дополнительных ресурсов, что может значительно увеличить расходы на инфраструктуру.
- Проблемы консистентности: В асинхронной репликации данные на разных репликах могут быть несогласованными, что может привести к проблемам с консистентностью. Например, пользователь может получить разные результаты для одного и того же запроса, если реплики не успели синхронизироваться.
Роль журнала БД в репликации
Прямой способ сделать репликацию - это скопировать ../../database/Журнал БД с master на slave и применить его. PostgreSQL работает именно так используя журнал WAL. Однако, не все так просто. Формат и возможности журнала напрямую зависят от СУБД.
Классификация репликаций
- По синхронизации. Гарантия наличия и доступности.
- По уровню работы
- Физическая репликация. Работа на уровне хранилища, мы работаем напрямую со страницами памяти
- Write-Ahead Log в PostgreSQL
- InnoDB Undo/Redo Log в MySQL
- Логическая репликация. Работает с кортежами. Мы храним набор кортежей до и после.
- Row-based Binary Log в MySQL
- Statement-based Binary Log недоразумение, которое работает на уровне запросов. Для такой репликации нужно выполнять запрос на слейве, и если запрос выполнялся 30 минут, то и на слейве он будет выполняться 30 минут. Также присутсвует зависимость в функциях, например функция времени вернет одно значение на мастере и совершенно другое на слейве.
- Физическая репликация. Работа на уровне хранилища, мы работаем напрямую со страницами памяти
- По расспространению изменений
- push. мастер сует, слейву пофиг. Реализуется редко. (Postgres)
- pull. слейв качает, мастеру пофиг. (MySQL)
- По количеству точек записи
- Репликация master-slave
- Репликация master-master
- Безмастерная репликация
- Групповая репликация. Реализовано в MySQL.
Проблемы
Мета информация
Область:: ../../../meta/zero/00 HighLoad, ../../../meta/zero/00 DevOps, ../../../meta/zero/00 Базы Данных Родитель:: ../../../../../source/курсы/otus/Архитектор высоких нагрузок 2019/Репликация Источник:: Автор:: Создана:: 2024-03-10