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