Что такое репликация в базах данных?

Давай разберём эту тему, а то некоторые думают, что репликация — это когда скопировал папку с данными и всё, ебать мои старые костыли. На деле всё чуть сложнее, но тоже ничего хитрожопого.

Если по-простому, репликация — это когда у тебя есть одна главная база (мастер), которая принимает все записи, и одна или несколько её клонов (реплики), которые эти записи тупо копируют. Зачем это надо? Ну, представь, твой мастер накрылся медным тазом. А у тебя есть реплика — поднял её вместо мастера, и пользователи даже не заметили, что ты всю ночь не спал. Красота, да? Ещё реплики можно использовать, чтобы раздать на них чтение, и мастер не будет захлёбываться под нагрузкой. Овердохуища запросов? Не проблема.

Основные типы, чтобы не путаться:

1. Мастер-реплика (Master-Slave):

   • Мастер — тут всё ясно, царь и бог, только он может писать (INSERT, UPDATE, DELETE). Все изменения идут через него.
   • Реплики (Slaves) — тупые, но верные клоны. Только читают (SELECT) и постоянно подлизывают данные с мастера.
   • Задача для нас, деплоячников: Сделать так, чтобы если мастер внезапно сдохнет, система сама, без нашего участия, переключилась на реплику. А то будешь в три часа ночи вручную всё поднимать, волнение ебать.

2. Мульти-мастер (Multi-Master): Тут уже веселее. Несколько узлов могут писать одновременно. Звучит круто, но это пиздопроебибна для конфликтов. Представь, два мастера пытаются изменить одну и ту же запись с разными значениями. Кого слушать? Приходится городить кучу логики для разрешения этих споров. Чаще головная боль, чем польза.

Как эта магия происходит технически?

• На основе бинарного лога (Binary Log): Самый распространённый способ. Мастер все свои изменения пишет в специальный журнал (бинарный лог), а реплики как подписчики — постоянно его читают и применяют у себя те же команды. MySQL, PostgreSQL — все так умеют.
• Логическая репликация: Это уже поумнее. Реплицируются не сырые байты, а логические изменения на уровне строк. Плюс в том, что можно реплицировать не всю базу, а только выбранные таблицы. PostgreSQL это любит.
• Снимки (Snapshot): Самый тупой метод. Просто периодически делается полная копия всей базы и выгружается на реплику. Лагов дохуя, данные не самые свежие, но для каких-то сценариев сойдёт.

Пример из жизни, чтобы вообще всё стало ясно:

Допустим, работаешь ты с AWS RDS. Хочешь сделать реплику для чтения, чтобы разгрузить продакшен. Делается это в три клика, ёпта.

1. Заходишь в консоль RDS, выбираешь свой основной инстанс (мастер).
2. В меню действий жмёшь "Create read replica".
3. Выбираешь, где её поднять (можно даже в другом регионе, для отказоустойчивости на случай, если весь регион AWS полетит к чёрту).

И всё! AWS сам настроит всю репликацию, будет за ней следить. Красота.

А где это реально применить, кроме как для галочки?

• Масштабирование чтения: Весь тяжёлый аналитический отчётный софт цепляешь не к мастеру, а к реплике. Пусть там свои гигабайты данных молотят, мастеру-то что?
• Резервные копии без боли: Бэкапы — святое дело. Но если ты начинаешь нагружать гигабайтными дампами продакшен-мастер, он может тебе такого наговорить... Поэтому бэкапы лучше гнать с реплики. И спокойно, и мастер не страдает.
• Тестирование на живых данных: Нужно протестировать новую фичу на почти что продакшен-данных? Разверни тестовое окружение с репликой. Данные свежие, а нагрузку на основную систему не создаёшь. Идеально.
• Географическое распределение: У тебя пользователи по всему миру. Чтобы чувак из Австралии не ждал ответа от базы в Айове полсекунды, подними реплику в Сиднее. Задержка упадёт, пользователи будут счастливы.