Репликация и отказоустойчивость: как MySQL и PostgreSQL защищают данные от сбоев

Репликация — это когда данные автоматически копируются с одного сервера базы данных на другой в реальном времени. Если основной сервер выходит из строя, работу подхватывает копия — и бизнес не теряет данные и не останавливается. И MySQL, и PostgreSQL умеют это делать, но подход у них разный.

Зачем вообще нужна репликация?

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

Репликация решает эту проблему иначе: рядом с основным сервером (его называют «мастер» или «primary») постоянно работает одна или несколько копий («реплики» или «standby»), куда в режиме реального времени передаются все изменения. Если мастер падает, одна из реплик становится новым основным сервером — и простой измеряется секундами, а не часами. Дополнительный бонус: реплики можно использовать для чтения — например, отдавать им отчёты и аналитику, разгружая основной сервер.

Как репликация устроена в MySQL?

MySQL записывает все изменения в специальный бинарный журнал (binary log). Реплика подключается к мастеру, читает этот журнал и применяет те же изменения у себя. Долгое время это работало по принципу «применяем команды в том же порядке, в каком они выполнялись на мастере», но сейчас чаще используется репликация на основе строк — передаются не сами SQL-команды, а конкретные изменения данных, что надёжнее.

У MySQL есть удобная особенность — полусинхронная репликация: мастер ждёт подтверждения от хотя бы одной реплики, что данные получены, и только потом сообщает клиенту об успешной записи. Это снижает риск потери данных при сбое, хотя и немного замедляет запись.

А как это работает в PostgreSQL?

PostgreSQL использует похожий принцип, но журнал называется WAL — write-ahead log, «журнал упреждающей записи». Любое изменение сначала фиксируется в этом журнале, и только потом применяется к самим данным. Реплики получают именно эти записи журнала и воспроизводят их у себя.

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

В чём принципиальная разница между подходами?

Технически оба движка решают одну задачу похожими средствами — журналом изменений. Но есть нюансы:

• PostgreSQL исторически считается более строгим в вопросах согласованности данных, и его репликация «из коробки» ближе к физическому копированию — реплика получается практически точной копией мастера на уровне файлов.
• MySQL долгое время был проще в настройке репликации и остаётся популярным выбором именно из-за низкого порога входа — многие хостинги и облачные сервисы разворачивают репликацию MySQL буквально в несколько кликов.
• В PostgreSQL проще устроена логическая репликация — когда реплицируются не все данные подряд, а отдельные таблицы или базы, что полезно при частичной синхронизации между разными системами.

Интересный факт: обе системы совсем не похожи по происхождению. MySQL создавалась в середине 1990-х шведской компанией как быстрая и простая СУБД для веб-проектов, а PostgreSQL выросла из академического проекта Berkeley, продолжавшего линию ещё более раннего проекта Ingres, — отсюда и её тяга к строгой архитектуре и академической выверенности решений.

Что такое отказоустойчивость и чем она отличается от репликации?

Репликация — это механизм копирования данных, а отказоустойчивость — это результат, ради которого её настраивают. Просто иметь копию базы недостаточно: нужен ещё механизм, который заметит падение мастера и автоматически «переключит рубильник» на реплику. Такие механизмы называют failover — автоматическое переключение при отказе.

Для MySQL и PostgreSQL существуют отдельные инструменты, которые следят за состоянием серверов и управляют переключением: они проверяют, жив ли мастер, и при необходимости назначают новую реплику основной, перенастраивая маршрутизацию запросов. Без такого инструмента репликация просто хранит копию данных, но переключаться при сбое всё равно придётся вручную.

Какие проблемы бывают при работе с репликацией?

Самая частая проблема — это задержка репликации (replication lag). Если реплика не успевает применять изменения так же быстро, как они появляются на мастере, данные на ней немного «отстают». Для аналитики это некритично, но если приложение случайно читает данные именно с отстающей реплики сразу после записи на мастер, пользователь может не увидеть только что сохранённые изменения.

Вторая сложность — так называемый split-brain, когда из-за сетевого сбоя система по ошибке считает, что мастер упал, и назначает новым мастером реплику, хотя старый мастер на самом деле жив и продолжает принимать запросы. В итоге получаются два «главных» сервера с расходящимися данными, и разрешить этот конфликт вручную бывает непросто. Хорошие системы отказоустойчивости специально проектируются так, чтобы минимизировать риск такой ситуации.

Что выбрать для своего проекта?

Если у вас стандартный сайт, интернет-магазин или CRM с предсказуемой нагрузкой и нет узкоспециализированных требований к целостности данных, репликация MySQL в связке с готовыми инструментами отказоустойчивости — простой и проверенный вариант, которым пользуются тысячи проектов.

Если проект работает с финансовыми данными, сложной аналитикой, географически распределёнными командами или требует гибкой настройки — сколько реплик должны подтвердить запись, какие таблицы реплицировать частично, — стоит присмотреться к PostgreSQL: его архитектура репликации даёт больше контроля над тем, что и как копируется.

В любом случае самостоятельно настраивать и поддерживать отказоустойчивый кластер — задача не для новичков: нужно следить за журналами, задержками, обновлениями и правильно тестировать переключение при сбоях. Сервис «Клауд АйСи» берёт эту рутину на себя: базы данных разворачиваются с уже настроенным резервированием, а мониторинг и переключение при сбоях происходят без участия администратора, так что можно сосредоточиться на самом проекте, а не на администрировании инфраструктуры.

С чего начать, если репликации пока нет вообще?

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