Ответ
Это архитектурный паттерн, при котором один сервер базы данных, называемый мастером (master или primary), обрабатывает все операции записи (INSERT, UPDATE, DELETE), а один или несколько других серверов, называемых репликами (slaves или replicas), копируют эти данные с мастера.
Основные цели репликации:
- Масштабирование нагрузки на чтение (Read Scaling): Клиентские приложения могут направлять запросы на чтение (SELECT) к репликам, разгружая мастер. Это значительно повышает общую производительность системы.
- Высокая доступность (High Availability): Если мастер-сервер выходит из строя, одна из реплик может быть "повышена" до нового мастера (процесс называется failover), что минимизирует время простоя.
- Резервное копирование: Реплику можно временно остановить для создания резервной копии без влияния на работу мастер-сервера.
Принцип работы:
- Мастер записывает все изменения в специальный лог транзакций (например,
binary logв MySQL,WALв PostgreSQL). - Реплика подключается к мастеру и считывает этот лог.
- Реплика применяет полученные изменения к своей копии данных.
Репликация может быть синхронной (мастер ждет подтверждения от реплики) или асинхронной (мастер не ждет). Асинхронная репликация быстрее, но создает риск потери данных при сбое мастера (возникает лаг репликации).
Пример настройки в PostgreSQL:
-- На мастере (postgresql.conf)
wal_level = replica -- Уровень логирования, достаточный для репликации
max_wal_senders = 3 -- Макс. число одновременных подключений от реплик
-- На реплике (команда в терминале)
-- Создает базовую копию данных с мастера и настраивает репликацию
pg_basebackup -h master-host -D /var/lib/postgresql/data -U replicator -P -v -RОтвет 18+ 🔞
Слушай, архитектурный паттерн, а по сути — как в семье, блядь. Один главный, он же мастер (или primary, если ты выёбистый), на нём вся ответственность: все операции записи — INSERT, UPDATE, DELETE — это его крест, его ебало. А вокруг него шарятся один или несколько подпевал, реплики (slaves, replicas — называй как хочешь), которые тупо копируют с него данные, как обезьянки.
Зачем это всё, спросишь? Цели, блядь, простые:
- Чтение размазать по репликам (Read Scaling): Чтобы мастер не сдох под тяжестью SELECT-запросов от любопытных. Все читают с реплик — и всем хорошо, производительность летит в космос, ёпта.
- Чтобы не было пиздеца (High Availability): Если мастер вдруг накрылся медным тазом — одну из реплик можно резко повысить до нового мастера (этот цирк называется failover). Система не ляжет, все довольны, волнение ебать.
- Для бекапа, чтоб его: Можно реплику на время притормозить и снять с неё слепок данных, а мастер пусть себе дальше пашет, не отвлекаясь.
Как это работает, в двух словах:
- Мастер, сука, всё, что делает, пишет в специальный дневник — лог транзакций (в MySQL это
binary log, в PostgreSQL —WAL). - Реплика, подлизываясь, цепляется к мастеру и начинает этот дневник читать, строчка за строчкой.
- Прочитала — и тупо повторяет у себя то же самое, применяя изменения к своим данным.
Бывает репликация синхронная — когда мастер, зануда, ждёт, пока реплика подтвердит: «Да, бля, получила!». И асинхронная — когда мастер похуй, отправил и забыл. Вторая, конечно, быстрее, но если мастер внезапно сдохнет, есть риск, что последние данные на реплику не успеют дойти. Это и есть лаг репликации, тот самый чёрт из коробочки.
Ну и, бля, примерчик для наглядности, в PostgreSQL:
-- На мастере (правим postgresql.conf)
wal_level = replica -- Включаем режим болтологии, достаточный для репликации
max_wal_senders = 3 -- Сколько реплик можем одновременно обслужить
-- На реплике (команда в терминале, сука)
-- Эта команда тупо сдерёт всю базу с мастера и настроит подчинение
pg_basebackup -h master-host -D /var/lib/postgresql/data -U replicator -P -v -RВот и вся магия. С одной стороны — просто, а с другой — овердохуища тонкостей, где можно наебнуться. Но если настроить — жить можно, блядь.