DBReplication

DBREPLICATION
Репликация информационных баз

МНОГОЦЕЛЕВОЕ РЕШЕНИЕ ВЫСОКОСКОРОСТНОГО ОБМЕНА ДАННЫМИ МЕЖДУ БАЗАМИ MS SQL SERVER
Результат

Стабильный высокоскоростной обмен между базами - от 5 секунд 24х7 

Решение широкого спектра задач с помощью скоростного обмена

Гарантия

Прогнозируемые результаты

Повышенная отказоустойчивость и надежность


Надёжный обмен даже на плохих каналах связи

Внедрение

Срок внедрения от 1 недели


Отработанная годами методика внедрения


Без стресса для пользователей

Инвестиции

Стоимость от 250 тыс.руб.

DBReplication это самостоятельная запатентованная технология обмена данными, альтернатива обменам 1С, репликации MS SQL Server и пр.

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

Основные возможности:

  • Высокая скорость обмена - синхронизация баз данных от 3 секунд;
  • Гарантия доставки данных даже при длительных обрывах связи;
  • Передача изменений немедленно после фиксации транзакции в базе данных;
  • Полностью автоматическое функционирование и разрешение конфликтов;
  • Отсутствие длительных блокировок при обмене;
  • Работа на любых каналах связи, в том числе слабых и неустойчивых;
  • Централизованный интерфейс мониторинга и управления процессами обмена;
  • Гибкая масштабируемость: простое подключение новых узлов информационной системы к DBREPLICATION;
  • Не требует изменения структуры хранения данных;
  • Не требует изменения функционала бизнес-приложения;
  • Оптимизация трафика: при передаче данные сжимаются;
  • Гибкая настройка фильтрации обмена.
  • При обмене строго соблюдается транзакционная целостность и транзакционная последовательность.
  • Любые версии MS SQL сервер.
  • Модуль адаптация под 1С7 и 1С8, возможна адаптация под другие платформы.

Решаемые задачи:

Принцип работы

Изменения данных автоматически регистрируются триггерами и записываются в специальные таблицы – очереди репликации. Транспортные службы непрерывно считывают из очередей репликации пакеты изменений и передают их между базами данных. Передача каждого пакета изменений начинается после фиксации транзакции SQL-сервером (commit transaction). Все пакеты изменений в процессе транспортировки проходят через специальный служебный сервер репликации – Дистрибутор. На Дистрибуторе каждый пакет проходит контроль конфликтов, проверку правил фильтрации и ряд других служебных операций. В точке назначения применение пакетов изменений происходит непрерывно по мере их поступления. При обмене строго соблюдается транзакционная целостность и транзакционная последовательность.

Транспорт:

  • Передача пакетов изменений между базами данных происходит без использования выгрузки/загрузки данных посредством внешних файлов. Данные передаются непосредственно «из таблицы в таблицу» на уровне SQL Server (из исходящей очереди одной БД во входящую очередь другой БД). 
  • Из входящей очереди БД-приёмника пакеты изменений применяются непосредственно к таблицам прикладной системы.
  • Для подключения к базам данных прикладной системы и к базе Дистрибутора транспортные службы используют OLEDB (порт по умолчанию - 1433).

Рис.1. DBREPLICATION: общий принцип работы DBREPLICATION  Рис.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

Сравнение DBREPLICATION с MS Replication
Сравнение DBREPLICATION с УРИБ 1С 8


Информация скоро появится на сайте

ИСПОЛЬЗОВАНИЕ ТЕХНОЛОГИИ DB REPLICATION НА ПРАКТИКЕ

ИНТЕРРАО
Минимакс
ВТБ-страхование
Золото Камчатки
ГРИНН
Автотрейд
Омега-автопоставка

ИНТЕРРАО

ПРОБЛЕМАТИКА:

Типовой обмен 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 мин

В БД-копию вынесен процесс получения тяжёлых аналитических отчетов



У одного документа или элемента справочника в разных БД будут одинаковые 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. Поэтому можно сказать, что общая длительность обновления всех узлов обычно не превышает длительности того узла, который обновляется дольше всех.
Screenshot_12.jpg

Как в 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 в такой системе. Во-вторых, компания Софтпоинт как вендор может в индивидуальном порядке рассмотреть возможность изменения технологии под специфику конкретной задачи, это вопрос для обследования и переговоров.

Возврат к списку