12.01.2026

Как настроить отказоустойчивость СУБД на импортозамещенном ПО: опыт «Диасофт»

По материалам вебинара компании «Диасофт» 

О чем эта статья?

В материале рассматриваются практические подходы к обеспечению отказоустойчивой работы систем управления базами данных на импортозамещенном ПО, в первую очередь – на базе PostgreSQL. Вы узнаете о физической и логической репликации, настройке кластеров под управлением Patroni и etcd, а также о реальных кейсах внедрения.

Кому будет полезно?

Администраторам баз данных, системным архитекторам, IT-руководителям, которые занимаются переводом систем на отечественное ПО и обеспечением непрерывности бизнеса.

Материал основан на реальном опыте компании «Диасофт» в проектах миграции и настройки высокодоступных систем для крупных банков и финансовых организаций.

Основные задачи обеспечения отказоустойчивости СУБД

Обеспечение отказоустойчивой работы систем управления базами данных – это не просто техническая задача, а комплексный подход к защите бизнес-процессов организации. При проектировании отказоустойчивой инфраструктуры необходимо решить несколько ключевых задач:

• обеспечить требуемый уровень доступности системы – определить целевые показатели RTO (Recovery Time Objective) и RPO (Recovery Point Objective);
• определить соразмерность вложений и рисков – не всегда нужна дорогая кластерная конфигурация, иногда достаточно резервного копирования;
• учесть все, что влияет на производительность – синхронная репликация может существенно замедлить работу системы;
• обеспечить полную готовность прикладного решения: инфраструктура – это необходимое, но недостаточное условие для надежной работы.

Важный момент

 Вложения в отказоустойчивую СУБД должны быть соразмерны рискам потери данных и простоя системы. Не для всех систем нужна кластерная конфигурация – иногда достаточно иметь резервную копию, которую можно восстановить, при этом восстановление может занять больше времени, чем ожидают пользователи.

 Варианты обеспечения отказоустойчивости СУБД

Существует три основных подхода к обеспечению отказоустойчивости баз данных, и каждый из них имеет свои преимущества и свою область применения.

Резервное копирование базы данных (физическая репликация)

Физическая репликация предполагает создание полной копии базы данных на резервном сервере. Это может быть реализовано различными способами:

• создание резервных копий (бэкапов) базы данных и логов транзакций;
• логшиппинг (log shipping) – автоматическая передача журналов транзакций;
• зеркалирование (mirroring) – синхронизации серверов СУБД;
• потоковая репликация (streaming replication).

Синхронная репликация гарантирует, что данные на резервном сервере полностью идентичны основному. Транзакция на рабочей среде не завершается, пока изменения не применены на резерве. При этом RPO = 0, но может существенно влиять на производительность.

Асинхронная репликация позволяет рабочей базе продолжать работу, не дожидаясь реплик резерва. Этот метод имеет минимальное влияние на производительность, но небольшая потеря данных при отказе возможна (RPO > 0). 
[Скриншот 1]

Схема физической репликации: синхронный и асинхронный режимы

Логическая репликация
Логическая репликация передает не все изменения в базе, а только изменения в выбранных таблицах. Этот подход имеет ряд особенностей:

• не реплицируются DDL-команды (создание объектов, изменение структуры);
• передаются только изменения данных в таблицах;
• резервная база доступна для записи и создания дополнительных объектов;
• можно реплицировать только часть таблиц;
• подходит для переноса аналитической нагрузки.

Практическое применение
Логическая репликация активно используется в АБС «Диасофт» для переноса аналитической нагрузки и интеграции с внешними системами. Это позволяет снизить нагрузку на основную базу и использовать резервное оборудование для решения бизнес-задач.

 [Скриншот 2]
Схема логической репликации и использования резервной базы для аналитики
Автоматизация переключения

 Репликации – это хорошо, но здесь критически важна скорость переключения на резерв при отказе основной системы. Для систем с требованиями работы в режиме 24/7 необходима полная автоматизация:

• автоматическое определение отказа основного сервера;
• переключение на резервную ноду без участия администратора;
• перенаправление приложений на новый мастер;
• автоматическая синхронизация после восстановления.

Решения для систем с низкими требованиями к восстановлению

Не все системы требуют дорогостоящих кластерных конфигураций. Для систем, где допустимо время восстановления от 30 минут до нескольких часов, можно применить более простые решения.

Архивирование логов базы данных
Этот подход особенно полезен для защиты от логических ошибок. Если в базе была удалена важная информация или произошла другая логическая ошибка, физическая репликация мгновенно размножит эту ошибку на все реплики.

Проблема физической репликации
При удалении данных или объекта в основной базе это изменение через логшиппинг или потоковую репликацию тут же применится на резервных средах. В результате логически некорректная база окажется и на резерве.

 Архивирование логов без автоматического восстановления позволяет:

• восстановить базу на момент до возникновения логической ошибки;
• накатить изменения до нужной временной точки;
• при необходимости выгрузить корректные данные, введенные после ошибки;
• объединить данные и продолжить работу.

Полная копия базы данных

Для быстрого переключения при отказе оборудования используется полная копия базы – идентичная онлайн-реплика, готовая к работе.

  Илья Виссарионов, руководитель департамента «Аппаратно-системная платформа» компании «Диасофт»: «В синхронном режиме коммиты на рабочей среде не пройдут, пока они не применятся на резерве. В случае интенсивного изменения данных или проблем с сетью между площадками мы получаем явные задержки на production, что может быть критично для производительности».

[Скриншот 3]

Сравнение режимов работы: архивирование логов vs полная репликация

Кластерная конфигурация на базе Patroni и etcd

Для систем с высокими требованиями к доступности необходима автоматизированная кластерная конфигурация. Для импортозамещенных решений на базе PostgreSQL компания «Диасофт» рекомендует классический тип кластера под управлением Patroni и etcd.

Архитектура решения

• Patroni – система управления высокодоступным кластером PostgreSQL, обеспечивает автоматический failover.
• etcd – распределенное хранилище конфигурации, хранит информацию о кластере и его состоянии: о лидере (мастере) и репликах кластера PostgreSQL.
• VIP-менеджер – обеспечивает единую точку входа через виртуальный IP-адрес, который автоматически переезжает на активную ноду.

Преимущества единой точки входа

Использование VIP-адреса позволяет приложениям подключаться к кластеру по одному IP, вне зависимости от того, какая нода сейчас является мастером. При переключении приложению достаточно просто переподключиться – VIP автоматически направит на актуальную ноду.
[Скриншот 4]
Схема кластера PostgreSQL под управлением Patroni и etcd с VIP-менеджером
Что решение автоматизирует?

 Классический кластер под управлением Patroni избавляет администратора от ручных действий при выполнении следующих задач:

• определение текущего мастера – система сама определит, какая нода сейчас активна;
• переключение IP-адреса – VIP-менеджер автоматически переезжает на новую мастер-ноду;
• перенастройка приложений – не требуется менять строки подключения;
• автоматический failover – при отказе мастера реплика автоматически повышается до мастера.

Требования к приложению

От приложения требуется только одно – умение переподключаться при потере соединения. При автоматическом переключении кластера приложение должно делать повторные запросы. В процессе повторных попыток оно автоматически подключится к новой активной ноде.

 Digital Q.DataBase – готовое решение «Диасофт»

Digital Q.DataBase – это комплексная СУБД со встроенными инструментами отказоустойчивости, разработанная компанией «Диасофт» на базе PostgreSQL. Это коробочное решение, которое включает все необходимые компоненты для работы в продакшене и отличается следующими преимуществами:

• все компоненты для настройки отказоустойчивости включены в поставку;
• Patroni, etcd, VIP-менеджер и другие утилиты протестированы на совместимость;
• исключает необходимость самостоятельного подбора совместимых версий из сторонних репозиториев;
• содержит расширения для неявного приведения типов, обеспечивает совместимость с запросами от Oracle и MS SQL Server;
• включает инструменты для работы с логической репликацией и автоматической синхронизацией DDL;
• отличается высокой производительностью, сравнимой с западными СУБД.

Узнать больше о Digital Q.DataBase →

 [Скриншот 5]

Интерфейс управления Digital Q.DataBase и состав компонентов платформы

Илья Виссарионов: «Мы предоставляем уже готовое надежное, высокопроизводительное решение. В нашу систему включены дополнительные пакеты, которые позволяют ей работать в режимах, сравнимых с западными СУБД, такими как Oracle и Microsoft SQL Server».

Практические кейсы и решенные проблемы

За время работы с импортозамещенными решениями специалисты «Диасофт» столкнулись с множеством нюансов, которые важно учитывать при настройке отказоустойчивости.

Переполнение дискового пространства на репликах

Проблема

До версии PostgreSQL 15.6 существовала проблема переполнения дискового пространства на резервных нодах. Автовакуум и вакуум преодолевались, место в базе высвобождалось, но на уровне файловой системы пространство продолжало занимать место. Со временем это приводило к переполнению дискового пространства и падению СУБД.

Решение: обновление системы до версии PostgreSQL 15.6 и выше, где эта проблема исправлена.

Проблемы версионности компонентов

Реальный кейс

В одном из проектов настройка кластера проводилась с рекомендованными версиями Patroni и etcd. Однако заказчик, исходя из лучших побуждений, установил обновленные версии этих компонентов. Подготовленные конфигурационные файлы оказались некорректными для новых версий.

Последствия: при отказе основной базы не происходило автоматическое переключение на резерв – для банка это катастрофа.

Решение: после долгих исследований проблема была выявлена, конфигурационные файлы скорректированы под новые версии, система заработала корректно.

Вывод: крайне важно использовать точно те версии компонентов, которые протестированы на совместимость.

Безопасность взаимодействия компонентов

По умолчанию etcd, Patroni и PostgreSQL обмениваются информацией по незашифрованным каналам. Это угрожает информационной безопасности: существует возможность перехватить трафик и выполнять команды на инстансах СУБД с правами суперпользователя без знания паролей.

Решение в Digital Q.DataBase: использование шифрованных механизмов работы между всеми компонентами кластера для снижения рисков несанкционированного доступа.

[Скриншот 6]

Схема защищенного взаимодействия компонентов кластера

Логическая репликация: возможности и применение

Физическая репликация дает полную копию базы, но имеет существенный недостаток: резервное оборудование фактически простаивает. Логическая репликация решает эту проблему.

Ключевые преимущества

Характеристика	Физическая репликация	Логическая репликация
Доступ на чтение	Да (не всегда)	Да
Доступ на запись	Нет	Да
Реплицируется	Вся база целиком	Выбранные таблицы
DDL-команды	Да	Нет (требуется дополнительная настройка)
Использование резерва	Только для отказоустойчивости	Для аналитики, интеграций, отчетности

Снижение влияния аналитической нагрузки

Даже в системах с хорошей архитектурой длинные аналитические запросы влияют на производительность транзакционных операций пользователей:

• объекты блокируются; 
• скорость доступа к данным в кэше снижается;
• возникает конкуренция за ресурсы сервера.

Илья Виссарионов: «Для процессов, которые работают очень быстро – секунды, десятки секунд, влияние тяжелого отчета, обрабатывающего те же таблицы, может быть существенным. Они начинают работать заметно дольше».  Перенос аналитических отчетов на базу логической репликации позволяет разделить OLAP- и OLTP-нагрузку, обеспечивая нормальную производительность для обоих типов задач.

Проблема «горизонта событий» в PostgreSQL

Особенность PostgreSQL

Из-за использования MVCC (многоверсионности) длинные незакрытые транзакции создают «горизонт событий» – препятствуют работе автовакуума. Таблицы начинают «пухнуть», производительность деградирует даже для операций, не пересекающихся с длинной транзакцией по данным.

Это делает разнесение аналитической и транзакционной нагрузки еще более актуальным для PostgreSQL, чем для других СУБД.
[Скриншот 7]
Схема распределения нагрузки: OLTP на основной базе, OLAP на реплике

Работа с кластером и продолжение репликации

Важная задача – обеспечить, чтобы логическая репликация продолжала работать при переключении физического кластера на другую ноду. В противном случае при каждом failover придется пересоздавать логическую репликацию.

Решение в Digital Q.DataBase
Логическая репликация подписывается не на конкретную ноду, а на кластер в целом. При автоматическом переключении мастера Patroni логическая репликация продолжает работать с новой активной ноды без разрушения.

Автоматизация работы с DDL

Логическая репликация не передает DDL-команды (создание и изменение объектов). Это создает проблему поддержания идентичности структуры баз.

 В Digital Q.DataBase включены расширения, которые:

• отслеживают изменения структуры на production-среде;
• автоматически передают DDL-команды на резервную среду;
• обеспечивают автоматическое включение новых таблиц в репликацию;
• делают возможной синхронизацию данных при добавлении новых объектов.

Применение для онлайн-миграции версий СУБД

 Логическая репликация может использоваться не только для распределения нагрузки, но и для миграции между разными версиями СУБД с минимальным простоем:

• создание начальной копии через backup;
• настройка логической репликации с источника на целевую систему;
• догрузка накопившихся изменений в онлайн-режиме;
• переключение пользователей на новую систему в момент завершения синхронизации.

[Скриншот 8]

Использование логической репликации для онлайн-миграции версий СУБД

Интеграция с прикладными решениями

Настройка отказоустойчивости на уровне СУБД и инфраструктуры – это необходимое, но недостаточное условие. Прикладное решение должно уметь корректно работать с кластерной конфигурацией.
Доработки АБС «Диасофт»

В автоматизированной банковской системе (АБС) компании «Диасофт» реализованы:

• поддержка групп доступности Always On в Microsoft SQL Server;
• поддержка кластеров PostgreSQL под управлением Patroni и etcd;
• автоматическая обработка переключения между нодами;
• лицензионный модуль с автоматической привязкой к новой ноде;
• сброс системных счетчиков при переключении.

Илья Виссарионов: «При переключении кластера пользователю нужно «перезайти» в систему, но все административные действия – изменение файла лицензии, привязка к новой ноде, сброс счетчиков – выполняются автоматически лицензионным модулем».

Работа с логической репликацией на уровне приложения

Для удобства работы с аналитической нагрузкой в АБС «Диасофт» реализован механизм прозрачного использования репликационной базы:

• администратор указывает в настройках рабочую и репликационную базы;
• для объектов (например, отчетов) выставляется настройка использования standby-базы;
• пользователь запускает отчет через обычный интерфейс;
• система автоматически направляет запрос на репликационную базу;
• результат возвращается пользователю без необходимости переподключения.

Гибкость управления

При увеличении задержки репликации или отказе standby-базы администратор может быстро перенести выполнение отчетов обратно на рабочую среду. Пользователям не нужно даже перелогиниваться – отчеты просто начнут выполняться на основной базе.

  [Скриншот 9]

  Интерфейс настройки использования репликационной базы для отчетов в АБС
Визуальные инсталляторы и автоматизация

Digital Q.DataBase и прикладные продукты «Диасофт» включают механизмы, снижающие нагрузку на администраторов:

• визуальные инсталляторы для настройки кластеров;
• автоматическая передача DDL-команд на резервную среду;
• контроль консистентности структуры между базами;
• инструменты мониторинга состояния репликации.

Методология внедрения отказоустойчивости

Успешное внедрение отказоустойчивой конфигурации требует системного подхода. «Диасофт» рекомендует следующую последовательность действий:

 Этап 1. Обследование и определение требований:

• анализ текущей инфраструктуры – возможности оборудования, сети, хранилищ;
• оценка системного ПО – версии, совместимость, ограничения;
• определение RTO и RPO – допустимое время простоя и потери данных;
• требования к автоматизации – что должно быть автоматизировано;
• бюджет проекта – соразмерность инвестиций и рисков.

Правильная постановка задачи

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

Этап 2. Проектирование решения

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

Требования	Рекомендуемое решение
Низкие требования, допустим простой до двух часов	Резервное копирование + архивирование логов
Средние требования, простой до 30 минут	Асинхронная потоковая репликация + ручное переключение
Высокие требования, простой до пяти минут	Синхронная репликация + автоматический failover (patroni)
Критичные системы, простой недопустим	Синхронная репликация + Patroni + георепликация

Этап 3. Функциональное тестирование

Первичная настройка проводится на тестовой среде с обязательной проверкой:

• корректности репликации данных;
• автоматического переключения при отказе мастера;
• времени переключения (соответствия RTO);
• отсутствия потери данных (соответствия RPO);
• работы приложений после переключения;
• обратного переключения (failback).

На этом этапе важно доказать бизнес-заказчикам, что система соответствует заявленным RTO и RPO. Без этого невозможно гарантировать непрерывность бизнеса.

Этап 4. Нагрузочное тестирование

  Для систем, чувствительных к производительности, обязательно проводится нагрузочное тестирование:

• имитация реальной нагрузки пользователей;
• измерение влияния синхронной репликации на производительность;
• оценка деградации при проблемах с сетью;
• тестирование поведения системы при пиковых нагрузках.

Илья Виссарионов: «Пользователи считают, что при синхронной репликации все будет работать так же быстро. Нет, всегда будут небольшие замедления. Важно показать, насколько сильно это влияние. Замедление на 10–20% может быть приемлемой платой, но если это 50–70% или разница в разы – на это мало кто согласится».
 
[Скриншот 10]
Результаты нагрузочного тестирования: производительность с репликацией и без репликации

Этап 5. Донастройка и оптимизация

 На основании результатов тестирования проводятся корректировки:

• оптимизация настроек Patroni (timeout, retry, loop_wait);
• настройка параметров PostgreSQL для репликации;
• оптимизация сетевого взаимодействия;
• балансировка между производительностью и отказоустойчивостью.

Этап 6. Внедрение на production

После успешного тестирования системы настраивается боевая отказоустойчивая конфигурация с переносом всех доработок и оптимизаций.

Этап 7. Мониторинг и регулярный аудит

Важно понимать: то, что работает сегодня, может перестать работать завтра. Система постоянно меняется: растут объемы данных, добавляется новый функционал, меняется интенсивность работы. То, что было оптимально при внедрении, может стать узким местом через год.

Необходим регулярный мониторинг:

• состояния репликации и задержек;
• использования дискового пространства;
• производительности и времени отклика;
• логов ошибок и предупреждений;
• результатов периодического тестирования failover.

Илья Виссарионов: «Проблемы появляются не на следующий день, а через несколько месяцев или год. Лучше работать на предупреждение, видеть намечающиеся деградации и исправлять их заранее, чем доводить до ЧП, когда всем нужно засесть за работу, пока все не будет исправлено».

Планы развития и будущие возможности

Компания «Диасофт» продолжает развивать инструментарий отказоустойчивости систем. В планах на 2025 год:

Развитие систем мониторинга

Расширение возможностей мониторинга на базе различных платформ (Zabbix, Prometheus, Grafana, Diasoft Sensor):

• отображение корректности работы репликации;
• мониторинг задержек между площадками;
• контроль консистентности данных между нодами;
• предиктивная аналитика для выявления проблем;
• автоматические алерты при отклонениях.

Автоматизация настройки и управления

PostgreSQL традиционно требует работы со скриптами и конфигурационными файлами. «Диасофт» планирует максимально автоматизировать:

• графические интерфейсы для настройки кластеров;
• визарды для типовых сценариев;
• генерацию конфигураций;
• упрощенное управление репликацией.

Илья Виссарионов: «Мы привыкли работать с дружелюбными интерфейсами в Microsoft и Oracle. Сложные операции можно делать из командной строки, но базовые задачи должны решаться через удобный графический интерфейс. Мы стремимся к этому в Digital Q.DataBase».
 
[Скриншот 11]

Заключение

Обеспечение отказоустойчивости систем управления базами данных на импортозамещенном ПО – это выполнимая задача, но она требует комплексного подхода и глубокой экспертизы. Доказательство тому – опыт проектов «Диасофт».

Ключевые рекомендации «Диасофт»:

• Правильно определяйте требования – не все системы нуждаются в дорогих кластерных конфигурациях.
• Учитывайте версионность – используйте протестированные совместимые версии компонентов.
• Обеспечивайте безопасность – шифруйте взаимодействие между компонентами кластера.
• Используйте логическую репликацию – для снижения нагрузки и эффективного использования оборудования.
• Дорабатывайте приложения: инфраструктура – это необходимое, но недостаточное условие.
• Тестируйте перед внедрением – функциональное и нагрузочное тестирование обязательны.
• Мониторьте постоянно – системы меняются, как и требования к ним.
• Рассмотрите готовые решения – Digital Q.DataBase включает все необходимое «из коробки».

Переход на импортозамещенное ПО – это не просто замена одной СУБД на другую. Это возможность пересмотреть архитектуру, оптимизировать процессы и внедрить современные практики обеспечения высокой доступности.

Опыт «Диасофт» в десятках проектов миграции показывает: при правильном подходе импортозамещенные решения на базе PostgreSQL способны обеспечить уровень надежности и производительности, сравнимый с западными СУБД, а в некоторых аспектах – даже превосходящий их.

Нужна помощь в настройке отказоустойчивости?

Специалисты «Диасофт» готовы помочь с проектированием, внедрением и поддержкой отказоустойчивых конфигураций на базе Digital Q.DataBase и других импортозамещенных СУБД.

Связаться с экспертами →


Дополнительные материалы