Ответ
Синхронная репликация — это режим репликации, при котором основная (master) база данных ждет подтверждения записи данных от одной или нескольких синхронных реплик (standby), прежде чем подтвердить транзакцию клиенту. Это гарантирует, что данные на реплике идентичны данным на мастере в момент подтверждения записи.
Как это работает (на примере PostgreSQL):
- Клиент отправляет команду
COMMIT. - Master записывает данные в свой WAL (Write-Ahead Log).
- Master отправляет WAL-данные на синхронную реплику и ждет подтверждения о их записи на диск реплики.
- Только получив подтверждение от реплики, master подтверждает (
COMMIT) транзакцию клиенту.
Настройка в PostgreSQL (postgresql.conf):
# Указываем имена синхронных реплик
synchronous_standby_names = 'standby1'
# Или для нескольких реплик (здесь требуется подтверждение от любой одной из двух)
synchronous_standby_names = 'ANY 1 (standby1, standby2)'
# Уровень синхронности
synchronous_commit = 'on' # или 'remote_write', 'remote_apply' для разных уровней гарантийПлюсы и минусы с точки зрения DevOps:
| Плюсы | Минусы |
|---|---|
| Гарантия нулевой потери данных (RPO=0): При аварии мастера данные точно есть на реплике. | Увеличенная задержка записи (latency): Зависит от сетевой задержки до реплики. |
| Строгая согласованность (strong consistency): Реплика всегда имеет актуальные данные. | Риск недоступности: Если синхронная реплика отключится, мастер может заблокировать запись (в зависимости от настроек). |
| Мгновенный failover: Реплика готова стать новым мастером без потери транзакций. | Сложность и стоимость: Требует мощной сети и инфраструктуры. |
Когда использовать: В финансовых системах, системах обработки транзакций, где целостность данных критически важнее, чем максимальная производительность записи.
Ответ 18+ 🔞
Давай разжую эту тему про синхронную репликацию, чтобы ты понял, что это за зверь такой. Представь, что ты пишешь данные в базу — это как отправить важное письмо с уведомлением о вручении. Пока почтальон не принесёт тебе эту зелёную бумажку с подписью получателя, ты нихуя не успокоишься и будешь считать, что письмо в пропасти. Вот синхронная репликация — это и есть то самое уведомление, только для твоих байтов в базе.
Как это работает, если по-простому (на примере PostgreSQL):
- Твоё приложение говорит базе: «Всё, фигачь на диск, коммить!» (
COMMIT). - Основной сервер (мастер) честно пишет всё в свой журнал (WAL), но дальше начинается магия.
- Он смотрит в настройки, видит там какого-то
standby1, и говорит: «Эй, чувак на том конце сети, лови мои данные и срочно запиши их к себе на диск, я жду!». - И стоит, бля, как дурак, и ждёт. Ждёт, пока реплика не ответит: «Окей, босс, я всё принял и записал, можешь спать спокойно».
- Только получив этот «письмо доставлено», мастер поворачивается к твоему приложению и говорит: «Всё, братан, транзакция завершена, можешь дальше работать». До этого момента приложение просто висит в ожидании.
Как это настроить (postgresql.conf):
# Говоришь мастеру, кого он должен слушаться и ждать
synchronous_standby_names = 'standby1'
# А если реплик несколько, можно указать, что ждать хотя бы одну из списка
synchronous_standby_names = 'ANY 1 (standby1, standby2)'
# Тут ещё можно уточнить, какого именно подтверждения ждать
synchronous_commit = 'on' # классика — ждём, пока реплика запишет на свой дискА теперь плюсы и минусы, чтобы ты понимал, на что подписываешься:
| Плюсы (за что мы это любим) | Минусы (за что мы это ненавидим) |
|---|---|
| Нулевая потеря данных, ёпта! Это главный козырь. Если мастер накроется медным тазом, ты точно знаешь, что последняя транзакция уже сидит на реплике. Спать спокойно. | Всё становится медленнее, ядрёна вошь! Каждая запись теперь упёрлась в скорость сети до реплики и скорость её дисков. Задержка (latency) вырастает овердохуища. |
| Консистентность — пизда рулю. Реплика всегда в том же состоянии, что и мастер. Никаких расхождений. | Риск полной остановки. Если твоя синхронная реплика легла или сеть до неё порвалась, мастер может просто перестать принимать запись. И всё, приехали. |
| Фейловер — раз плюнуть. Переключиться на такую реплику можно мгновенно, данные все целы. | Геморрой и деньги. Нужна быстрая, стабильная сеть и такое же железо для реплики. Всё это стоит нехилых бабок. |
Когда это вот вообще надо? Представь банковский перевод. Ты же не хочешь, чтобы деньги списались с одного счёта, но на второй так и не дошли, потому что сервер хлопнулся? Вот именно для таких случаев, где целостность данных — это святое, а скорость — дело десятое. В остальных ситуациях, честно, да похуй — используй асинхронную репликацию и живи спокойно.
