Репликация позволяет сделать N копий одной БД. Обычно есть одна ведущая копия, которую называют master, и есть N ведомых реплик, которые называют slaves. Репликация не отменяет первоначального копирования БД. Сначала нужно первый раз скопировать данные, а потом уже запустить репликацию.
- Позволяет получить масштабирование чтения, но ==не позволяет получить масштабирование операций вставки.== Для масштабирования вставки используется [Шардирование в БД](Шардирование%20в%20БД.md).
- Чтобы делать асинхронное [резервное копирование БД](Резервные%20копии%20БД.md)
- Чтобы распределить нагрузку. Например перенести сложные запросы построения отчетов на отдельную реплику.
Прямой способ сделать репликацию - это скопировать [Журнал БД](Журнал%20БД.md) с мастера на слэйв и применить его на слейв. PostgreSQL работает именно так используя журнал [WAL](Write-Ahead%20Log.md).
## Классификация репликаций
- По синхронизации. Гарантия наличия и доступности.
- Физическая репликация. Работа на уровне хранилища, мы работаем напрямую со страницами памяти
- [Write-Ahead Log](Write-Ahead%20Log.md) в PostgreSQL
- [InnoDB Undo/Redo Log](Журналы%20в%20MySQL.md#InnoDB%20Undo/Redo%20Log) в MySQL
- Логическая репликация. Работает с кортежами. Мы храним набор кортежей до и после.
- [Row-based Binary Log](Журналы%20в%20MySQL.md#Row-based%20Binary%20Log) в MySQL
- [Statement-based Binary Log](Журналы%20в%20MySQL.md#Statement-based%20Binary%20Log) недоразумение, которое работает на уровне запросов. Для такой репликации нужно выполнять запрос на слейве, и если запрос выполнялся 30 минут, то и на слейве он будет выполняться 30 минут. Также присутсвует зависимость в функциях, например функция времени вернет одно значение на мастере и совершенно другое на слейве.
- По расспространению изменений
- push. мастер сует, слейву пофиг. Реализуется редко. (Postgres)
