Типы репликации

Настраивая репликацию, инженер всегда делает выбор между скоростью работы системы и вероятностью потерять данные.

Как работает: Master записывает изменение у себя в WAL и моментально отвечает клиенту «Успех», не дожидаясь реплик. Данные улетают на Slave в фоновом режиме.

• Плюсы: Максимальная скорость записи. Master не зависит от проблем с сетью.
• Минусы: Если Master сгорит через миллисекунду после ответа клиенту, а данные не успеют долететь до Slave — мы потеряем данные.
• Применение: Социальные сети (лайки, комментарии). Если один лайк потеряется — никто не умрет, скорость важнее.

Как работает: Master ждет, пока реплика не только получит данные, но и физически применит их в свои таблицы. Только после подтверждения от реплики клиент получает ответ.

• Плюсы: Абсолютная гарантия консистентности. Потерять данные невозможно.
• Минусы: Очень медленная запись. Если сеть между дата-центрами «моргнет», все клиенты зависнут в ожидании.
• Применение: Финансовые транзакции, биллинг, медицина.

Как работает: Золотая середина. Master ждет ответа от Slave, что данные получены и надежно сохранены в локальный лог на жестком диске (Relay Log). Но Master не ждет, пока эти данные вставятся в сами таблицы реплики.

В крупных компаниях данные из боевых (OLTP) баз нужно постоянно переливать в аналитические хранилища (DWH), например, в ClickHouse или YTsaurus (open-source платформа от Яндекса).

Как это сделать, не убив боевую базу?

1. Старый подход (Batch ETL): Написать скрипт, который раз в час делает SELECT * FROM users WHERE updated_at > X. Но при этом подходе мы создаем пиковую нагрузку на БД, не видит физически удаленные строки (DELETE).
2. Современный подход (CDC - Change Data Capture): Инструменты вроде Debezium подключаются к БД, притворяясь обычной Slave-репликой. Они просто читают тот самый WAL-лог и стримят все события наружу. Боевая БД даже не чувствует этой нагрузки.