WWW.NVTO.RU



Навигация






карта работы АСКУЭ MetCon









Печать E-mail

Автор: admin1   
Дата публикации:  12.10.2017 г.
Источник: WWW.NVTO.RU

Решение задачи репликации данных в АСКУЭ "MetCon"

    Репликация данных (далее репликация) – это обновление базы данных (БД) – приемника на основе данных БД – источника. Принимая во внимание тот факт, что это самый простой случай репликации, было бы неверно ограничиться этим определением. Реальные распределенные системы обработки данных требуют более сложных схем обмена данными. Множество таблиц требуют полной или частичной синхронизации на нескольких десятках БД. Нередко требуется выполнять сложные преобразования данных, например, при сборе только обобщенных данных в центральной БД. Отдельно стоит проблема обмена данными между разными системами обработки данных, которые, работая, по сути, с одними и теми же данными, имеют различное их представление в БД и, не редко работающих на разных платформах. Разовые операции переноса данных между БД не являются репликацией. Репликация выполняется автоматически в соответствии с заданными параметрами...

    В широком смысле репликация данных – это приведение распределенной базы данных в актуальное состояние.

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

  - все механизмы репликации реализуются только между одинаковыми SQL-серверами (репликация с другими SQL-серверами, как правило, имеет массу ограничений);
  - часто производитель не включает возможности репликации во все варианты поставок своего SQL-сервера, поэтому требуется дополнительно приобретать варианты поставок с полной комплектацией или покупать специализированное ПО репликации данных сторонних разработчиков;
  - сложные механизмы репликации при больших объемах данных требуют соответствующих вычислительных мощностей (сейчас для большинства предприятий это не проблема), быстрых и устойчивых каналов связи (эта проблема встречается чаще);
  - не всегда возможно организовать репликацию встроенными средствами SQL-сервера без изменения структуры БД, которая наследована еще с ранних версий системы и является её основой.

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

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

    К таким же выводам пришло множество разработчиков пытающихся «приручить» механизмы репликации SQL-серверов для нужд своих систем обработки данных. В Сети не сложно найти статьи и форумы, где поднимаются такие же вопросы и предлагаются различные решения задачи репликации данных.

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

    В настоящее время для решения задачи репликации в АСКУЭ «Спрут» применяет сервер «Репликатор» (далее «Репликатор») написанный собственными силами. Автор в программном продукте постарался учесть всё выше сказанное.

    “Репликатор” разрабатывался как средство организации автоматического непрерывного тиражирования, консолидации и обмена данными между произвольным количеством БД. Предполагалось не охватывать сразу все многообразие возможных вариантов репликации, а дорабатывать все необходимые функции тогда, когда в этом возникает непосредственная необходимость и постановка задачи ясна. Поэтому при разработке внутренней архитектуры “Репликатора” особо обращалось внимание на последующее её развитие.

    На рисунках 1 и 2 показаны схемы взаимодействия двух “Репликаторов”

схемы взаимодействия двух “Репликаторов”
Рисунок 1. Репликация данных между двумя SQL-серверами с использованием сервера электронной почты

Репликация данных между двумя SQL-серверами с использованием сервера электронной почты
Рисунок 2. Репликация данных между двумя SQL-серверами с использованием прямого IP-соединения

    Для доступа к БД “Репликатор” использует ODBC, что обеспечивает независимость от реализации SQL-сервера и позволяет выполнять репликацию данных между разными SQL-серверами (на пример между MS SQL и Oracle).

    Основные характеристики применяемых алгоритмов обработки данных:

  - не требуется дополнительного изменения структуры БД;
  - поддерживается репликация любых данных, их сочетаний и преобразований (“Репликатор” оперирует SQL-запросами);
  - настройка репликации фрагмента БД выполняется как отдельное «задание», что позволяет избирательно реплицировать данные из БД;
  - передаются только новые данные или обновленные данные (новая строка идентифицируется первичным ключом – список полей);
  - предусмотрена возможность принудительно выполнить полную синхронизацию данных для каждого отдельного «задания»;
  - для повышения производительности, возможен контроль изменения данных за заданное количество дней;
  - протокол обмена между “Репликаторами” допускает потерю «заданий», «пакетов новых данных» и «квитанций», что позволяет даже при большом количестве сбоев в работе гарантировать целостность данных.
    Передача данных выполняется через электронную почту (смотрите рисунок 1), что дает целый ряд преимуществ:
  - возможность работы через медленные и неустойчивые каналы;
  - не требуется одновременного непосредственного соединения двух взаимодействующих “Репликаторов” – почтовый сервер исполняет роль буфера;
  - выход в Интернет “Репликатор” выполняет через стандартные почтовые протоколы или корпоративный почтовый сервер – поэтому не стоит проблема решения вопросов безопасности внутренней сети предприятия (службы информационной безопасности на предприятиях часто бывают весьма не сговорчивы).

    Реализована возможность автоматического установления соединения удаленного доступа к почтовому серверу (или Интернет) через модем.
    Репликация данных через прямое IP-соединение двух “Репликаторов” (смотрите рисунок 2) позволяет существенно уменьшить время и объемы передачи данных, но лишится всех преимуществ передачи данных через электронную почту.
    Управление синхронизацией данных выполняется при помощи гибкой системы расписаний. Также возможно вручную запускать процессы синхронизации данных.
    Вопросы безопасности решаются шифрованием всего обмена данными и командами, а целостность данных обеспечивается защитой 32-битной контрольной суммой.
    Мониторинг работы распределенной сети “Репликаторов” решается простой рассылкой электронной почтой администраторам фрагментов лог-файлов заданного размера по заданному расписанию. Это позволяет конфигурировать репликацию и оперативно реагировать на проблемы, но требует помощи персонала, работающего рядом с удаленным “Репликатором”.

    Настройка параметров репликации выполняется в файле конфигурации. Заложенная при проектировании, гибкость конфигурирования позволяет выполнять описание «заданий» репликации в конфигурационном файле любого из взаимодействующих “Репликаторов”. Таким образом, не навязывается централизованное или децентрализованное управление – у конфигуратора репликации есть выбор.
    Для дополнительной гарантии устойчивой работы предусмотрена автоматическая перегрузка в случае зависания или аварийного завершения.
    С начала 2003 года “Репликатор” успешно применяется для решения всех задач передачи данных между БД АСКУЭ «Спрут» и для обмена данными с БД других систем. Следует отметить, что во всех вариантах репликации выполняются преобразования данных: изменение структуры, приведение к общему первичному ключу, фильтрация по различным значениям полей, корректировка времени и преобразование численных данных.

    В заключении хотелось бы отметить, что управление распределенной БД намного сложнее управления централизованной БД, поэтому мало иметь надежные средства репликации, дополнительно требуется тщательный анализ, планирование и тестирование. Важно также глубоко понимать суть конкретного используемого механизма репликации и реально оценивать технические возможности каналов связи, оборудования и программного обеспечения. Только тогда возможно построить распределенную систему обработки данных, которая поддерживает данные на требуемом уровне актуальности и гарантирует их целостность.
Последнее обновление ( 12.10.2017 г. )
 
« Пред.


Использование любых материалов с сайта возможно только с письменного разрешения администрации.
При цитировании активная ссылка на сайт обязательна.
Идея сайта :  Фёдоров Д.В.
Дизайн и вёрстка :  Фокеев Д.А.
Художник :  Савоськина Л.В.
Copyright © НВТО Все права защищены.

Rambler's Top100