Принцип работы
Изменения данных автоматически регистрируются триггерами и записываются в специальные таблицы – очереди репликации. Транспортные службы непрерывно считывают из очередей репликации пакеты изменений и передают их между базами данных. Передача каждого пакета изменений начинается после фиксации транзакции SQL-сервером (commit transaction). Все пакеты изменений в процессе транспортировки проходят через специальный служебный сервер репликации – Дистрибутор. На Дистрибуторе каждый пакет проходит контроль конфликтов, проверку правил фильтрации и ряд других служебных операций. В точке назначения применение пакетов изменений происходит непрерывно по мере их поступления. При обмене строго соблюдается транзакционная целостность и транзакционная последовательность.
Транспорт:
-
Передача пакетов изменений между базами данных происходит без использования выгрузки/загрузки данных посредством внешних файлов. Данные передаются непосредственно «из таблицы в таблицу» на уровне SQL Server (из исходящей очереди одной БД во входящую очередь другой БД).
-
Из входящей очереди БД-приёмника пакеты изменений применяются непосредственно к таблицам прикладной системы.
-
Для подключения к базам данных прикладной системы и к базе Дистрибутора транспортные службы используют OLEDB (порт по умолчанию - 1433).
Рис.1. DBREPLICATION: общий принцип работы DBREPLICATION 
Модуль интеграции с 1С
Имеется специальный модуль интеграции DBREPLICATION с 1С 7 и 1С 8:
-
В пользовательских интерфейсах DBREPLICATION все объекты прикладной системы представлены в виде привычного дерева метаданных 1С;
-
Поддерживаются специфические механизмы 1С: последовательность документов, планы обмена и пр.;
-
Возможность интегрировать между собой технологию DBREPLICATION и обмен типовыми средствами 1С8 (планы обмена);
-
Не требуется внесение изменений в конфигурацию 1С;
-
Не требуется равенства имён таблиц и столбцов на уровне SQL;
-
Имеется специальный централизованный механизм обновления конфигурации 1С во всех узлах информационной системы;
-
Поддерживается обмен данными агрегационных таблиц (итоги регистров 1С).
Компоненты DBREPLICATION
В состав DBREPLICATION входят следующие основные компоненты:
-
Наборы триггеров и хранимых процедур (TSQL); они создаются во всех прикладных БД контура обмена;
-
Транспортные службы – агенты репликации (многопоточные службы Windows, устанавливаются во всех узлах контура обмена);
-
Служебная БД Дистрибутора (важнейший элемент технологии, как правило располагается на выделенном сервере);
-
Набор вспомогательных служебных БД для хранения архивов и обеспечения сервисных функций; состав этих БД может варьироваться; они разворачиваются на всех узлах контура обмена;
-
Программа «Мастер репликации» – централизованный пользовательский интерфейс для разворачивания, настройки, мониторинга и управления работой системы обмена.
-
Служба нотификации. Это многопоточная служба Windows, разворачивается как правило в единственном экземпляре в одной подсети с Дистрибутором.
Централизованное управление и контроль
Одним из важных преимуществ DBREPLICATION является то, что его механизмы управления и контроля основаны на принципе централизованности. Это значит, что административный инструментарий позволяет настраивать и контролировать обмены во всей распределённой информационной системе из «единого окна». Даже если система состоит из большого количества узлов, расположенных в разных частях страны или мира, администратор имеет возможность в режиме реального времени видеть статус обмена в каждом узле и управлять им из единого графического интерфейса.
Гибкая фильтрация данных
В составе DBREPLICATION присутствует многоуровневая система фильтрации данных. Она позволяет реализовывать самые разнообразные конфигурации потоков данных:
-
от простейших «всё-всем» и «только центр»,
-
до самых изощренных, когда маршрут каждой транзакции определяется индивидуально по сложной логике, анализирующей содержимое транзакции.
Фильтрация в 1С8
Для платформы 1С8 существует возможность интегрировать механизм фильтрации с прикладной логикой системы, когда правила фильтрации программируются непосредственно в 1С.
Двусторонний и односторонний обмен
DBREPLICATION предоставляет два режима обмена: двухсторонний и односторонний. Основные отличия заключаются в следующем:
|
Односторонний
|
Двусторонний
|
|
Базы данных строго делятся на «источники» и «приемники». Изменения передаются только из «источников» в «приемники», но не наоборот.
|
Каждая база выполняет роль и «источника», и «приемника». Изменения передаются из любой базы во все остальные в соответствии с правилами фильтрации.
|
|
Изменения, внесенные пользователем в «приемник», никуда не передаются. «Источники» защищены от попадания в них изменений, которые были внесены (специально или по ошибке) в «приёмники».
|
|
Конфликтов версионности не бывает.
|
Возможны конфликты из-за одновременного изменения данных в разных базах. Они разбираются в автоматическом режиме по принципу «побеждает первый».
|
Механизм сверки баз данных
Имеется механизм сверки данных между узлами распределенной системы:
-
сверка происходит на уровне таблиц SQL;
-
расхождения детализируются с точностью до значения в конкретном поле таблицы;
-
возможна настройка автоматической сверки по расписанию с рассылкой результатов по почте.
Система нотификации
В комплекте с DBREPLICATION поставляется система нотификации. Она позволяет гибко настраивать (конструктор) разнообразные правила по контролю показателей работы DBREPLICATION. При достижении установленных контрольных значений автоматически рассылаются оповещения на e-mail.
Сравнение DBREPLICATION с MS Replication и УРИБ 1С 8
ИСПОЛЬЗОВАНИЕ ТЕХНОЛОГИИ DB REPLICATION НА ПРАКТИКЕ
ИНТЕРРАО
Минимакс
ВТБ-страхование
Золото Камчатки
ГРИНН
Автотрейд
Омега-автопоставка
РКС: КОНСОЛИДИРОВАННАЯ БД 1С8 ДЛЯ 15-ТИ ФИЛИАЛО
МОЭСК: УСКОРЕНИЕ ОБМЕНА ДАННЫМИ МЕЖДУ БАЗАМИ 1С8, КОНСОЛИДИРОВАННАЯ БД
ВТБ-СТРАХОВАНИЕ: СВЁРТКА БАЗЫ 1С8 С ПРИМЕНЕНИЕМ DBREPLICATION
РКС: ПЕРЕХОД НА ГЕОРАСПРЕДЕЛЕННУЮ СИСТЕМУ 1С8, ОПТИМИЗАЦИЯ ПОДРАЗДЕЛЕНИЙ
ИНТЕРРАО
ПРОБЛЕМАТИКА:
Типовой обмен 1С 8 не справляется с имеющимся трафиком в распределенной системе;
Задержка синхронизации баз данных составляла в лучшем случае 1 сутки;
Необходим максимально оперативный обмен, близкий к online.
ЦЕЛИ:
Получение быстрого обмена данными в распределенной ИТ-системе;
ОСОБЕННОСТИ:
Большой поток данных (изменений)
Сложные правила фильтрации (перенаправление потока данных между узлами)
Двусторонний обмен (во всех узлах меняются данные)
РЕЗУЛЬТАТЫ:
Типовой обмен 1С заменен на DB REPLICATION
Реализована сложная схема фильтрации данных
Скорость обмена выросла на порядки: было 1 сутки и более, стало 1 минута.
Минимакс
ПРОБЛЕМАТИКА:
Имеет место лишь частичная консолидация данных с большими задержками.
ЦЕЛИ:
Создание полноценной консолидированной БД для 70 филиалов и единого Веб-портала на её основе.
Получение быстрого обмена в распределенной ИТ-системе, в том числе для консолидированной БД.
ОСОБЕННОСТИ:
Большое количество узлов распределенной ИТ-системы (до 70)
В пиках активности высокий поток данных
Сложные правила фильтрации данных (перенаправление потока данных между узлами)
Двусторонний обмен (во всех узлах меняются данные)
РЕЗУЛЬТАТЫ:
Создана консолидированная БД
Достигнуто время синхронизации между БД (в том числе консолидированная БД) менее 1 минуты
Реализована сложная схема фильтрации данных
ВТБ-страхование
ПРОБЛЕМАТИКА:
Высоконагруженная информационная система на платформе 1С 8;
Большая удельная дополнительная нагрузка в периоды формирования данных по МСФО.
ЦЕЛИ:
Перераспределение нагрузки путем реализации "горячей" копии основой БД и вынесением в неё процесса формирования данных и отчетности по МСФО
ОСОБЕННОСТИ:
Большой поток данных (изменений)
Односторонний обмен
РЕЗУЛЬТАТЫ:
Реализована "горячая" копия продуктивной БД
Скорость синхронизации данных <1 минуты
Вынесен в отдельную БД процесс формирования данных и отчетности по МСФО
Золото Камчатки
ПРОБЛЕМАТИКА:
Типовой обмен 1С 8 в условиях слабых и неустойчивых каналов связи работает нестабильно;
Задержка синхронизации баз данных не удовлетворительная, превышает иногда 1 сутки;
Синхронизация БД неполная (обмен только по части объектов 1С);
Проблемы с обновлением конфигурации 1С в удалённых узлах.
ЦЕЛИ:
Получение стабильного и быстрого обмена данными в распределенной ИТ-системе;
ОСОБЕННОСТИ:
Двусторонний обмен (во всех узлах меняются данные)
Слабые неустойчивые спутниковые каналы связи
Проект внедрения DB REPLICATION совмещен с проектом перехода на новую конфигурацию 1С
РЕЗУЛЬТАТЫ:
Типовой обмен 1С 8 заменен на DB REPLICATION
Реализована полная синхронизация данных между узлами без фильтрации
Время синхронизации данных по спутниковым каналам улучшилось на порядки – до 4-7 минут
Обмен работает стабильно в автоматическом режиме
Решена проблема с обновлениями конфигурации 1С
ГРИНН
ПРОБЛЕМАТИКА:
Высокая транзакционная нагрузка
Высокая аналитическая нагрузка (отчеты)
ЦЕЛИ:
Повышение отказоустойчивости ИТ системы за счет создания «постоянно горячей» копии БД
Балансировка аналитической нагрузки
ОСОБЕННОСТИ:
Большой поток данных (изменений)
Односторонний обмен (изменение данных в одном узле, второй узел работает только на чтение - отчеты)
Платформа 1С 7
РЕЗУЛЬТАТЫ:
Реализована "горячая" копия продуктивной БД
Скорость синхронизации данных <1 минуты
Процесс получения тяжелой аналитической отчетности вынесен в отдельную БД
Автотрейд
ПРОБЛЕМАТИКА:
Высокая транзакционная нагрузка
Высокая аналитическая нагрузка (отчеты)
ЦЕЛИ:
Повышение отказоустойчивости ИТ системы за счет создания «постоянно горячей» копии БД в резервном ЦОДе
Балансировка аналитической нагрузки (тяжелые отчеты в резервной БД)
ОСОБЕННОСТИ:
Большой поток данных (изменений)
Односторонний обмен: два узла, данные меняются в одном узле, второй узел работает только на чтение (отчеты)
Платформа 1С 7
РЕЗУЛЬТАТЫ:
Реализована "горячая" копия продуктивной БД с синхронизацией в среднем менее 1 мин
В БД-копию вынесен процесс получения тяжёлых аналитических отчетов
Омега-автопоставка
ПРОБЛЕМАТИКА:
Высокая транзакционная нагрузка
Высокая аналитическая нагрузка (отчеты)
ЦЕЛИ:
Повышение отказоустойчивости ИТ системы за счет создания «постоянно горячей» копии БД
Балансировка аналитической нагрузки (тяжелые отчеты в резервной БД)
ОСОБЕННОСТИ:
Большой поток данных (изменений)
Односторонний обмен (изменение данных в одном узле, второй узел работает только на чтение - отчеты)
РЕЗУЛЬТАТЫ:
Реализована "горячая" копия продуктивной БД с синхронизацией в среднем менее 1 мин
В БД-копию вынесен процесс получения тяжёлых аналитических отчетов
РКС: КОНСОЛИДИРОВАННАЯ БД 1С8 ДЛЯ 15-ТИ ФИЛИАЛОВ
ПРОБЛЕМАТИКА:
Механизм загрузки данных из филиальной сети посредством типового обмена 1С8 работает нестабильно, много ошибок данных. Всё это регулярно приводило к проблемам в отчетный период.
ЦЕЛИ:
Необходимо обеспечить надёжное автоматическое и своевременное поступление данных из филиальной сети в консолидированную бд
ОСОБЕННОСТИ:
Множество филиалов (15)
Односторонний обмен данными (консолидация только получает)
РЕЗУЛЬТАТЫ:
Внедрена технология DB REPLICATION, обмен функционирует автоматически и стабильно, Консолидированная бд получает данные из филиальной сети с задержкой не более 1 минуты.
МОЭСК: УСКОРЕНИЕ ОБМЕНА ДАННЫМИ МЕЖДУ БАЗАМИ 1С8, КОНСОЛИДИРОВАННАЯ БД
ПРОБЛЕМАТИКА:
Скорость обмена типовыми средствами 1С8 не удовлетворяет, требуется радикальное ускорение обмена для решения ряда бизнес-задач, в том числе необходимо сформировать консолидированную бд, загрузив в нее исторические данные из всех филиалов.
ЦЕЛИ:
Необходим быстрый обмен данными, приближенный к online, между всеми филиалами и консолидированной БД
Загрузить через систему обмена исторические данные из всех филиалов в консолидированную БД
ОСОБЕННОСТИ:
Высокий поток данных (изменений)
10 филиальных бд
РЕЗУЛЬТАТЫ:
Внедрена технология DB REPLICATION; время синхронизации баз - до 1 минуты; сформирована консолидированная БД; появилась возможность реализовать новые перспективные бизнес-процессы и улучшить сервис для клиентов компании.
ВТБ-СТРАХОВАНИЕ: СВЁРТКА БАЗЫ 1С8 С ПРИМЕНЕНИЕМ DBREPLICATION
ПРОБЛЕМАТИКА:
Оперативная база 1С8 разрослась до порядка 2.5 ТБ, из-за чего постепенно нарастают проблемы инфраструктуры, обслуживания и быстродействия. Решено свернуть неактуальные исторические данные. Имеются лишь очень короткие технологические окна, невозможно в них уложить длительную тяжелую свёртку. Простой системы в ходе свёртки недопустим.
ЦЕЛИ:
Свернуть неактуальные исторические данные без простоя системы.
ОСОБЕННОСТИ:
Нет длительных технологических окон
Односторонний обмен данными (сворачиваемая бд только получает)
РЕЗУЛЬТАТЫ:
Реализован механизм свёртки с широким применением средств TSQL.
БД успешно свёрнута без простоя системы по методике с применением технологии DB REPLICATION: свёртка происходила в бд-копии, после свёртки бд-копия подверглась глубокой детальной верификации в течение нескольких дней, технология DB REPLICATION обеспечила синхронизацию бд-копии, по окончании верификации пользователи переведены в свёрнутую бд-копию.
РКС: ПЕРЕХОД НА ГЕОРАСПРЕДЕЛЕННУЮ СИСТЕМУ 1С8, ОПТИМИЗАЦИЯ ПОДРАЗДЕЛЕНИЙ
ПРОБЛЕМАТИКА:
В связи с введением объединенного центра обслуживания (ОЦО) необходимо обеспечить стабильный доступ гео-распределенных пользователей к информационной системе. Выбран вариант, когда вместо единой базы филиала создается распределенная система из 2х БД: одна в филиале, вторая в ОЦО. Для их синхронизации нужна быстрая система обмена.
ЦЕЛИ:
Необходим быстрый и стабильный обменданными между базами 1С8 ОЦО и филиалами
Оперативная работа филиалов не должна останавливаться при отсутствии связи с ОЦО
ОСОБЕННОСТИ:
Двусторонний обмен(во всех узлах меняются данные)
15 филиалов, 30 баз данных; их количество со временем увеличивается
РЕЗУЛЬТАТЫ:
Внедрена технология DBREPLICATIONдля 30ти баз 1С8
Время синхронизации данных между базами ОЦО и филиалов в пределах 1 минуты
В случае обрыва связи филиалы продолжают работу в своей базе, после восстановления связи базы автоматически синхронизируются
- У одного документа или элемента справочника в разных БД будут одинаковые UID или разные?
- При создании нового документа или элемента справочника каждая БД 1С генерирует UID (поле _IDRref) по особому алгоритму, исключающему повторение UID-ов в разных БД. Это функционал платформы 1С. Технология DBREPLICATION передаёт документы и элементы справочников между узлами, сохраняя значения их UID.
- Как решается проблема дублирования номеров у новых документов, создаваемы в разных узлах ИС?
- Данная проблема лежит вне плоскости функционала системы обмена данными. Никакая система обмена данным, в том чисел DBReplication, эту проблему не решает. Она должна решаться на уровне логики прикладной учетной системы. В платформе 1С имеется возможность каждой базе распределенной системы назначить индивидуальный префикс, который будет автоматически добавляться к номеру каждого нового документа и к коду элемента справочника. Таким образом, у каждой БД будет собственное не пересекающееся с другими пространство номеров документов и кодов элементов справочников.
- Где должен размещаться «Эталон»?
- Эталон должен размещаться в локальной подсети Дистрибутора.
- Каковы требования к ширине канала связи для нормальной работы DBREPL?
- Однозначного четкого ответа на этот вопрос нет, т.к. всё зависит от того потока данных, который необходимо передавать между узлами. Есть примеры успешной работы DBREPL на спутниковых каналах связи от 128 Кбит/с, имеющих высокую латентность (ping до 2000 млс).
- Как отрабатывает DBREPL при обрывах связи с узлами распределенной системы?
- В случае обрыва связи с одним из узлов (или несколькими узлами), пользователи этого узла продолжают работать автономно, пакеты изменений накапливаются в очередях обмена. Как только связь восстанавливается, DBREPLICATION автоматически возобновляет обмен и доставляет все изменения по назначению.
- Как решается проблема блокировок при обмене 1С8?
- Те блокировки, которые возникают в типовом обмене 1С при больших объемах выгружаемых/загружаемых данных, обусловлены особенностями этого механизма обмена. Эти блокировки отсутствуют при использовании технология DBREPLICATION как класс, поскольку DBREPLICATION функционирует на совершенно иных принципах, чем типовой обмен 1С.
- Сколько времени длится обновление конфигурации 1С8, если используется DBREPL?
Чтобы ответить на этот вопрос, отметить несколько ключевых моментов:
-
Основную часть времени при обновлении отдельного узла занимает процесс применения изменений конфигуратором 1С (это происходит путем запуска конфигуратора в пакетном режиме со специальными параметрами).
-
Дополнительное время требуется на автоматический парсинг метаданных и актуализацию репликационных объектов. Обычно это около 2-3 минут.
-
Все узлы распределенной ИС обновляются одновременно, параллельно друг с другом, с помощью специального механизма, входящего в состав DBREPLICATION. Поэтому можно сказать, что общая длительность обновления всех узлов обычно не превышает длительности того узла, который обновляется дольше всех.
- Как в DBREPL решается задача обновления конфигурации 1С8?
- В составе технологии DBREPLICATION имеется специальный механизм, который позволяет обновлять конфигурацию 1С во всех узлах распределенной системы централизовано из единого графического интерфейса. При этом необходимо соблюдать регламент, который прорабатывается в соответствии со спецификой конкретной ИС и той задачи, которая решается с помощью DBREPLICATION.
- Дистрибутор обязательно должен быть выделенным сервером?
- Жестких ограничений на этот счёт нет. Это зависит от интенсивности трафика в распределенной системе, построенной с использованием технологии DBREPLICATION, ведь через Дистрибутор проходит весь трафик репликации. Это значит, что нагрузка на Дистрибутор тем больше, чем выше трафик. В большинстве случаев для Дистрибутора рекомендуется использовать отдельный сервер (физический или виртуальный). В особых случаях допускается совмещать на одном сервере Дистрибутор с другими базами данных, но делать это следует осмотрительно и с хорошим предварительным расчетом.
- Нужно ли на Дистрибуторе сервер приложений 1С и клиент 1С?
- Нет. Функциональность Дистрибутора такова, что он не нуждается ни в сервере приложений 1С, ни в клиентской части 1С.
- Какой SQL Server должен быть на Дистрибуторе?
- Поддерживаются
все варианты в диапазоне MSSQLServer 2005-2016 Standard– Enterprise. Для
информационных систем с низким потоком данных также возможно использование
варианта Expressedition
- Какие требования к аппаратной части Дистрибутора?
Это зависит от того трафика данных, который проходит через Дистрибутор. Вилка вариантов такая:
- CPU 4-8 процессорных ядер;
-
RAM 8-32 Гб;
- Дисковое пространство 50-150 Гб (без учета потребностей ОС).
- Где должен размещаться Дистрибутор относительно других узлов системы?
Это зависит от специфики конкретной информационной системы. Можно выделить два наиболее распространенных варианта.
-
Если имеется узел, которой генерирует на порядки больше трафика, чем другие узлы, то Дистрибутор целесообразно разместить в подсети этого узла.
-
Если в информационной системе имеется консолидированная БД, в которую стекаются данные из множества узлов, то Дистрибутор целесообразно разместить в подсети консолидированной БД.
- Можно ли настроить репликацию для разных конфигураций 1С?
- Технология DBREPLICATION применима только в гомогенных системах, где все узлы имеют одинаковую структуру реплицируемых объектов БД. С точки зрения 1С это означает, что конфигурация 1С везде должна быть идентична. Однако, в отдельных случаях возможен выход за рамки этого ограничения. Во-первых, если конфигурации 1С в узлах отличаются незначительно и при этом являются потомками одной и той же родительской конфигурации, то можно в индивидуальном порядке с некоторыми ограничениями настроить DBREPLICATION в такой системе. Во-вторых, компания Софтпоинт как вендор может в индивидуальном порядке рассмотреть возможность изменения технологии под специфику конкретной задачи, это вопрос для обследования и переговоров.
