Каталог решений - Копия базы 1С для отчетов. Как работать с репликой только для чтения

Старая проблема

Любовь к монолитам идет от самой фирмы "1С" и простирается на большинство ее партнеров и клиентов. Многие информационные системы на базе платформы 1С построены в виде единого монолита, где ведется как оперативная работа и выполнение различных регламентных операций, так и сбор разного рода отчетности.

У многих архитекторов и разработчиков, имеющих дело с платформой 1С (по крайней мере которых я знаю) есть стойкое видение, что монолит лучше разрозненных баз, т.к. исключает проблемы интеграции, проще идет разработка, нет проблем согласованности изменений между частями системы, меньше проблем с администрированием, да и вообще разделение на сервисы это "модное" зло и так далее.

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

Отсюда и появляется проблема с производительностью и надежностью. Особенно в периоды закрытия месяца и подобных "особых" периодов. Тормозит ли ваша база в период закрытия или годовой отчетности? Если да, то сочувствую. Думаю, у Вас есть архитектурные проблемы. Или проблемы с железом и пора добавить 6 ТБ оперативной памяти! (это шутка, пощадите ваших админов!).

Ниже мы поговорим о путях решения подобных проблем, рассмотрим некоторые варианты. Основное направление — это вынос отчетной, OLAP нагрузки из основной базы, чтобы никакая отчетность больше не влияла на оперативную работу. Альтернативный путь разбивания монолита на сервисы рассматривать не будем, оставим это для другой истории.

Первое, что приходит в голову

Разработчики 1С тут же предлагают сделать копию информационной базы и отправлять в нее данные основной базы с помощью стандартных или доработанных обменов данными с некоторой периодичностью (это и планы обмена, и регистрация изменений в регистре сведений и так далее). Эту копию использовать как обычными клиентскими сеансами (тонкий и толстый клиенты), так и опубликовать из нее веб-сервис и запрашивать данные через него.

Этот вариант мы рассматривать не будем, так как он имеет существенные недостатки, с которыми придется героически бороться:

• Снижение производительности и параллельности работы пользователей, особенно при использовании планов обмена.
• Повышенная нагрузка на сервер 1С как основной базы, так и копии, ведь все операции нужно более-менее дублировать.
• Сложность в сопровождении из-за потенциальных ошибок в обмене данными, ошибок в конфигурации и так далее.

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

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

В общем, этот вариант только для фанатов 1С. Бесстрашных и упрямых.

Какие еще варианты

В статье "Копия базы 1С для отчетов. Или как выжить с тяжелой отчетностью" мы рассматривали разные способы создания копии базы данных для отчетности:

• Создание копии через обычное бэкапирование.
• Через репликацию средствами СУБД, в примере был SQL Server.
• Онлайн-копии через механизм групп высокой доступности AlwaysOn, реализованном также в SQL Server. Для PostgreSQL такое также возможно через потоковую репликацию.

Кроме этого можно создавать копию через механизм доставки жарнала транзакций с учетом всех ограничений этого механизма.

Бэкапирование создает копию, которую платформа 1С может использовать без ограничений, т.к. в базу все также возможна запись данных, но актуальность данных будет сильно страдать в такой базе.

Репликация и AlwaysOn позволяют создать копию базы данных практически в онлайн режиме, но она будет доступна только для чтения. По умолчанию платформа 1С с такими базами работать нормально не сможет. Особенности работы платформы 1С с базами только для чтения описаны в этой инструкции. Самые простые способы подружить платформу 1С с такими базами это:

• Использовать толстый клиент обычного приложения, предварительно убрав из конфигурации выполнение операций записи при запуске клиента.
• Опубликовать веб-сервисы и через них обращаться к этой копии.

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

• Компания Softpoint реализовала готовый продукт Data Cluster, которая позволяет выполнять балансировку запросов между серверами. Другими словами, это промежуточное ПО позволяет отправлять читающие запросы на онлайн-копии базы данных, причем это происходит незаметно для клиента базы данных. В том числе и для платформы 1С.
• Сама фирма "1С" реализовала механизм копий баз данных, доступный с лицензией КОРП. Также позволяет создавать копии баз данных и отправлять выполнением запросов на различных серверах.

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

Выбираем способ создания копии базы

Первое, что мы выберем — это способ создания копии базы данных. Тут исходим из того, что доступно.

Для SQL Server (подробная информация о доступности функционала в разных редакциях и лицензировании):

• Доставка логов транзакций (доступен в редакциях Standard и Enterprise)
• Репликация данных (различные способы) (обычно все варианты доступны в Standard и Enterprise, но есть исключения)
• Группы высокой доступности AlwaysOn (полный функционал доступен в Enterprise, но ограниченный функционал доступен и в Standard)

Для PostgreSQL:

• Потоковая репликация
• Логическая репликация

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

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

Почему платформа не работает

Прежде чем что-то делать нужно ответить на вопрос: "Почему платформа 1С не работает с базами в режиме только для чтения?".

Если попытаться добавить такую базы в кластер 1С и запустить клиентское приложение, то с высокой вероятностью Вы получите такую ошибку.

Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/modules/call:
по причине:
Соединение с сервером баз данных непригодно для использования после разрыва соединения администратором и будет переустановлено.
Microsoft SQL Server Native Client 11.0: Failed to update database "YourDatabaseName" because the database is read-only.
HRESULT=80004005, SQLSrvr: SQLSTATE=25000, state=2, Severity=10, native=3906, line=1

Причина проста — платформа пытается записать изменения в служебные таблицы, например в "_SystemSettings" таким запросом:

INSERT INTO dbo._SystemSettings (
    _UserId,
    _ObjectKey,
    _SettingsKey,
    _Version,
    _SettingsPresentation,
    _SettingsData,
    _DataSeparationUse16249,
    _DataSeparationUse16250,
    _Fld2293,
    _Fld774) 
VALUES(@P1,@P2,@P3,@P4,@P5,@P6,@P7,@P8,@P9,@P10) 

Такую же ошибку можно получить и при явных операциях изменения данных над объектами базы (справочников, документов и так далее).

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

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

• V8Users
• DBSchema
• SchemaStorage
• Params
• Files
• _FrmDtSettings
• DepotFiles
• IBVersion
• Config
• ConfigCAS
• ConfigCASSave
• ConfigSave
• _UsersWorkHistory
• _SystemSettings
• _DynListSettings
• _CommonSettings
• _ExtensionsInfo
• _ExtensionsInfoNGS
• _ExtensionsRestruct
• _ExtensionsRestructNGS
• _YearOffset

Получается, что если мы сможем показать платформе 1С, что запись в эти таблицы возможна без каких-либо ошибок, то проблем с работой в базах с режимом "только для чтения" не будет.

Хитрый ход

Но как можно "обмануть" платформы 1С? Ведь копия базы недоступна для изменения. Но выход есть всегда!

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

Например, у нас есть база "BSL-ORIG" на основном сервере SRV-SQL-1. Подключена к серверу 1С обычным образом, все работает штатно. Через механизм групп высокой доступности AlwaysOn сделана копия этой базы на SRV-SQL-2. Копия, конечно же, доступна только для чтения.

Создаем пустую базу на SRV-SQL-2, назовем ее "BSL_COPY". Она и будет располагать все необходимые объекты базы. И именно к ней будет обращаться сервер 1С для работы.

Но прежде, чем пустить платформу 1С в огород базу нужно выполнить подготовительные действия.