Вопрос обеспечения бесперебойной работы корпоративных информационных систем стоит остро для любого бизнеса. Когда речь заходит о 1С:Предприятии на базе MS SQL Server, администраторы часто ищут способы организовать "горячий" резерв или возможность быстрого переключения на запасной сервер в случае аварии. Часто первым приходящим на ум решением становится "Репликация". Однако в контексте 1С это понятие имеет множество нюансов.
В этой статье мы подробно разберем, работает ли штатная репликация SQL с базами 1С, с какими подводными камнями придется столкнуться, и какие альтернативные (и более надежные) методы существуют для организации отказоустойчивого кластера, особенно в условиях ограниченного бюджета.
Давайте сразу проясним терминологию. Под "репликацией" в MS SQL Server обычно понимают Transactional Replication. Это механизм, который синхронизирует данные между базами на уровне отдельных объектов (таблиц, хранимых процедур). Казалось бы, идеальный вариант: изменения на основном сервере тут же летят на резервный.
Однако при попытке "скрестить" этот механизм с платформой 1С мы сталкиваемся с фундаментальными проблемами:
Primary Key. Хотя современные версии 1С создают кластерные индексы, исторически некоторые таблицы (например, временные или служебные таблицы настроек) могут не соответствовать жестким требованиям репликации. Это потребует сложной фильтрации объектов публикации, что превращает администрирование в кошмар. Чтобы лучше понять структуру ваших таблиц, вы можете проанализировать SQL сервер глазами 1С-ника с помощью специализированных инструментов — для этого подойдёт анализатор структуры таблиц и индексов базы 1С.
Таким образом, использование классической Transactional Replication для полного зеркалирования базы 1С — это путь к постоянным ошибкам при каждом обновлении конфигурации.
Если бюджет клиента ограничен ("клиент не богатый") и покупка дорогих лицензий SQL Enterprise невозможна, самым надежным и простым решением является технология Log Shipping.
Давайте разберем, как это работает и как это организовать:
Суть метода:
Преимущества:
Режим Standby и "Только чтение":
Многие хотят использовать вторую базу для тяжелых отчетов, чтобы разгрузить основной сервер. Log Shipping позволяет настроить базу в режиме Standby (доступна для чтения). Однако здесь есть важный нюанс:
В момент, когда приходит очередной лог (каждые 15 минут), SQL Server должен получить монопольный доступ к базе для его применения. Это значит, что все пользователи, читающие отчеты, будут принудительно отключены. Если отчет формируется дольше 15 минут, он никогда не достроится. Увеличение интервала (например, до раз в сутки) повышает риск потери данных при аварии.
Рекомендация по настройке:
Для "небогатого" клиента оптимальная схема выглядит так:
В случае падения основного сервера («железный» сбой) администратор выполняет следующую процедуру:
-- На резервном сервере
RESTORE DATABASE [Base1C] WITH RECOVERY;
Эта команда переводит базу из состояния восстановления в рабочее состояние. После этого остается только переключить строку соединения в 1С или сменить DNS-запись. Потеря данных составит не более 15 минут (время последнего лога).
Если мы говорим о современном подходе (начиная с SQL Server 2016), то Microsoft представила технологию Basic AlwaysOn. Это отличная замена устаревшему "Зеркалированию" (Database Mirroring), которое Microsoft официально объявила устаревшим (Deprecated).
Особенности Basic AlwaysOn:
Это идеальный вариант для организации отказоустойчивости (High Availability) без возможности использования базы для отчетов.
При настройке любого вида репликации или зеркалирования для 1С необходимо учитывать специфику работы платформы и обслуживания индексов.
1. Режим RCSI (Read Committed Snapshot Isolation)
Для корректной работы 1С:Предприятие 8 требует включения режима версионирования строк:
ALTER DATABASE [BaseName] SET READ_COMMITTED_SNAPSHOT ON;
При использовании технологий AlwaysOn или Mirroring, нагрузка на системную базу tempdb на вторичном сервере может быть значительной. При планировании "железа" нельзя ставить медленные диски под tempdb, иначе репликация будет "тормозить" основной сервер. Кроме того, важно регулярно выполнять адаптивное обновление индексов MS SQL, чтобы поддерживать производительность на обоих узлах.
2. Обслуживание индексов и блокировки
При обслуживании баз 1С часто возникают проблемы с блокировками. Рекомендуется использовать доработанное решение IndexOptimize, которое корректно обрабатывает параметры блокировок на уровне страниц, что особенно важно в высоконагруженных системах с репликацией.
3. Лицензирование
Если вы используете второй сервер только как "холодный" или "теплый" резерв (Passive Failover) и не читаете с него данные, не делаете бэкапы и не строите отчеты — то при наличии подписки Software Assurance (SA) лицензия на второй экземпляр SQL Server может быть бесплатной.
Если же вы планируете использовать реплику для отчетов (Readable Secondary в Enterprise версии) или Log Shipping в режиме Standby для чтения — необходимо покупать полную лицензию SQL Server на оба узла.
Подведем итог обсуждения, выбрав подходящее решение в зависимости от задач.
WITH RECOVERY.
Ответ на вопрос автора темы: Репликация MS SQL Server для баз 1С технически возможна, но стандартная транзакционная репликация не рекомендуется из-за несовместимости с механизмами обновления 1С.
Для защиты данных "небогатого клиента" следует использовать регулярные бэкапы журнала транзакций (Log Shipping) или, если позволяет версия SQL Server (2016+ Standard), настроить Basic AlwaysOn. Это обеспечит надежную защиту от аппаратных сбоев без необходимости покупать дорогостоящее оборудование или лицензии Enterprise уровня.