Представь ситуацию: ты запустил свой проект, пользователи активно им пользуются, и вдруг твоя единственная база данных падает. Сайт встает, пользователи в панике, а ты сидишь и потеешь, пытаясь восстановить всё из ночного бэкапа.
Именно поэтому в реальных системах всегда используется репликация — процесс постоянного копирования данных с главного узла (Master) на резервные (Slave/Replica). Она решает две фундаментальные задачи:
- Отказоустойчивость (Failover): Если Master выходит из строя, мы почти мгновенно переключаем трафик на одну из реплик. Данные не потеряны, система жива.
- Масштабируемость (Read Scaling): Master занимается только записью (INSERT/UPDATE), а все тяжелые
SELECT-запросы мы отправляем на чтение в реплики. Так мы разгружаем главный узел.
Как это работает под капотом: WAL
Способ доставки информации от Master к Slave элегантен. База данных не копирует файлы таблиц целиком. Вместо этого используется WAL (Write-Ahead Log).
WAL — это строго последовательный (append-only) файл, который содержит журнал всех изменений. Представь его как ленту событий: «12:01 — добавили пользователя ID=5», «12:02 — обновили баланс до 100». Реплика (Slave) просто подключается к Master'у, непрерывно скачивает этот лог и «проигрывает» все эти события у себя.