Репликация базы между двумя VPS помогает быстрее поднять приложение после отказа, но сама по себе не гарантирует сохранность всех последних заказов. При асинхронной передаче резервная база может отставать; при автоматическом переключении важно не допустить, чтобы оба сервера одновременно принимали записи. Перед настройкой решите, какую потерю данных бизнес может выдержать и кто имеет право назначить новую основную базу.
Репликация и резервная копия — разные вещи
Реплика получает изменения с основного сервера и применяет их к своей базе. Это удобно, когда нужно быстро подготовить второй VPS к продолжению работы. Резервная копия — отдельная сохранённая точка, к которой можно вернуться после ошибки, повреждения данных или ошибочного удаления.
Если администратор удалит таблицу, а репликация передаст удаление на второй сервер, обе копии повторят одну ошибку. Поэтому оставляйте независимые резервные архивы с историей и проверяйте их восстановление. Реплика ускоряет переключение, а копия с историей помогает вернуться в состояние до нежелательного изменения.
Почему важна задержка реплики
При асинхронной схеме основная база может подтвердить транзакцию раньше, чем она получена и применена на резервной. Если основной VPS внезапно перестал отвечать, последние изменения могут отсутствовать на резерве. Поэтому считайте задержку не абстрактным техническим числом, а возможным окном потери данных.
Официальная документация PostgreSQL описывает потоковую репликацию как способ передавать записи журнала на резервный сервер. Она также подчёркивает, что асинхронный режим допускает небольшое отставание и риск потери ещё не дошедших записей. MySQL по умолчанию тоже использует асинхронную репликацию; полусинхронная схема ждёт подтверждения получения от реплики, но за это платит дополнительной задержкой операций записи. Конкретный эффект зависит от сети, версии, нагрузки и конфигурации.
Запишите целевое значение RPO: сколько данных допустимо потерять при аварии. Если допустимо не более нескольких минут, периодически обновляемый дамп может оказаться недостаточным. Если нужна почти нулевая потеря подтверждённых заказов, архитектура и приложение должны поддерживать соответствующую модель подтверждения записи. Само слово «репликация» этого не гарантирует.
Как избежать двух основных баз
Самый опасный сценарий — разделение сети. Основной VPS недоступен для мониторинга, но продолжает принимать запросы от части пользователей; команда повышает реплику до основной, и в этот момент оба сервера пишут свои версии данных. Позже их нельзя безопасно склеить обычным копированием файлов.
Перед переключением нужна процедура, которая подтверждает, что старый источник остановлен или лишён права записи. В кластере для этого применяют fencing или иной механизм управления ролью, а в более простой архитектуре оператор может изолировать старый сервер через панель, приложение или правила доступа. Конкретный вариант должен быть проверен до аварии. После продвижения реплики старый сервер нельзя автоматически возвращать в роль главного.
В PostgreSQL поддержка резервного сервера и потоковой передачи WAL не заменяет механизм, который обнаруживает отказ и координирует переключение. В документации прямо рассматриваются вопросы продвижения standby и риск, когда оба узла считают себя основными. Для MySQL также важно заранее понимать, какая реплика выбрана, как она догоняет источник и кто меняет направление репликации.
Для базы на VPS важны не только CPU и объём RAM. Нужны стабильный диск, сеть между площадками, место для журналов, возможность открыть необходимые соединения и понятный способ получить консоль. Рейтинг ниже сохранён в согласованном порядке и служит списком для сравнения. Уточняйте доступность базы и её режима на выбранном тарифе; порядок не означает, что проведено одинаковое нагрузочное испытание всех конфигураций. Ссылки партнёрские.
Порядок провайдеров взят из рейтинга в статье «VPS/VDS для проекта с вебхуками». Здесь список служит отправной точкой для сравнения площадок под реплику базы. Уточняйте доступность нужных ресурсов и сетевого режима на выбранном тарифе: список не означает, что конфигурации прошли одинаковый нагрузочный тест. Ссылки партнёрские.
Рейтинг VPS/VDS для базы-реплики
| Место | Провайдер | Что проверить для репликации |
|---|---|---|
| 1 | Timeweb | Сеть между VPS, диск и доступ к консоли |
| 2 | Selectel | Поддержку нужной ОС и параметров хранения |
| 3 | EdgeCenter | Сетевые ограничения и возможность резервного доступа |
| 4 | VDSina | Как контролировать задержку и восстанавливать сервер |
| 5 | SpaceWeb | Стоимость диска и внешнего трафика |
| 6 | AdminVPS | Какая помощь доступна для ОС и базы данных |
| 7 | Sprintbox | Подходит ли сеть для постоянной передачи журналов |
| 8 | Hostland | Подтвердите, что речь о VDS и подходящем тарифе |
| 9 | HandyHost | Как устроены снимки и независимый экспорт |
| 10 | FirstVDS | Проверьте настройки сети и доступ к дискам |
Как защитить заказы и оплаты
В интернет-магазине одной базы мало: платёжная система, браузер покупателя и сайт могут сообщать о платеже в разное время. После переключения повторный webhook может прийти ещё раз, а клиент может нажать «Оплатить» повторно. Приложение должно уметь обрабатывать повторные уведомления без создания второго заказа или двойного списания. Используйте уникальный идентификатор операции, а статусы платежа при восстановлении сверяйте с первичным источником — кабинетом платёжной системы или её журналом.
Если приложение отправляет задачи в очередь или использует Redis, перенос одной SQL-базы не восстановит незавершённые задачи и сессии. Составьте список состояния, которое необходимо переносить, и состояния, которое можно безопасно пересоздать. Не включайте запись на резерве, пока не ясно, что основной узел остановлен и исходные данные догнаны до выбранной точки.
Какие показатели отслеживать
- соединение реплики с источником и время последнего принятого изменения;
- позицию последнего отправленного, полученного и применённого журнала;
- свободное место для данных и журналов на обоих VPS;
- скорость накопления очереди и длительность догоняющей синхронизации;
- ошибки приложения при записи и расхождение заказов с оплатами;
- готовность резерва принимать записи после контролируемого продвижения.
Раз в согласованный период отрабатывайте восстановление из архива и переключение на копии. После учения верните исходную роль только по процедуре: проверьте направление репликации, догоните изменения и убедитесь, что запись снова разрешена ровно на одном узле.
Порядок продвижения реплики
До аварии запишите, кто подтверждает остановку старого источника и кто переводит реплику в режим записи. Уточните, как определить последнюю доступную позицию журнала и что делать, если реплика отстаёт. Если фактическая потеря данных может превысить согласованное значение, решение должно учитывать бизнес-последствия: иногда безопаснее временно закрыть оформление новых заказов и сверить оплаты, чем немедленно открыть запись на неполной копии.
После продвижения обновите подключение приложения к базе, проверьте фоновые задачи и сохраните отметку, с какого времени новый сервер стал основным. Прежний источник блокируйте от записи до тех пор, пока не определено его новое назначение. Если сеть восстановилась и старый узел снова виден, это не значит, что его можно подключить обратно как источник без проверки.
Практический сценарий для интернет-магазина
Представим, что основной VPS пропал во время оформления заказа. Сначала нужно определить, был ли запрос принят приложением и подтверждён ли платёжной системой. Затем сравнить последнюю подтверждённую транзакцию с состоянием реплики и решить, открывать ли магазин для новых записей. После восстановления сопоставить идентификаторы заказов, статусы оплат и события webhook. Повторный webhook должен менять статус существующего заказа, а не создавать ещё один.
Если доступна только более старая копия, выпишите временной интервал между ней и текущим инцидентом. Сохраните события платежей и заявки, которые могут быть в стороне от базы. До закрытия инцидента не удаляйте журналы, важные для сверки, но ограничьте к ним доступ. После подтверждения корректности заказов верните обработку задач и уведомлений в штатный режим.
Если база небольшая и допустимое время восстановления составляет несколько часов, полноценная репликация может быть излишней. Проверенная копия с понятным порядком запуска может быть проще и надёжнее. Если же записи не должны теряться, потребуется спроектировать синхронность, приложение и сетевую доступность как единое решение, а не выбирать режим по одной строке в тарифном описании.
Не включайте резерв в работу только из-за того, что мониторинг потерял связь с основным VPS. Причиной может быть ошибка маршрута мониторинга, а сервер продолжает принимать запросы. Используйте независимые сигналы: статус приложения с внешней точки, соединение с базой, метрики реплики и данные провайдера. Если один источник наблюдения недоступен, сначала определите, достаточно ли доказательств для переключения.
Частые вопросы
Репликация означает, что данные не потеряются?
Нет. Асинхронная реплика может отставать, а ошибки источника могут передаваться на резерв. Нужны независимые архивы и понятное целевое значение потери данных.
Можно ли переключить базу автоматически?
Можно, если заранее настроены обнаружение отказа, координация роли и защита от одновременной записи. Непроверенный автоматический переключатель может увеличить ущерб.
Стоит ли включать синхронную репликацию?
Она может уменьшить риск отставания подтверждённых записей, но влияет на время операций и доступность при проблемах сети. Сравните этот компромисс с требованиями бизнеса и проверьте его на тестовой нагрузке.
Источники и дата проверки
Проверено 11 ноября 2026 года. Использованы официальные руководства: PostgreSQL: standby и потоковая репликация, PostgreSQL: failover, MySQL 8.4: репликация и MySQL 8.4: полусинхронная репликация. Команды и возможности зависят от версии СУБД.