Обеспечение идентичности конфигурационных баз данных SQL

29 июля 2014

 

Поделитесь статьей в социальных сетях

0

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

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

Минимальное количество серверов для схемы резервирования — 3, непосредственно 2 логгера и 1 ОРС-сервер. Сборщики (коллектора) — обязательный компонент программного продукта — размещаются на тех же серверах, что и логгеры. Максимальное количество используемых серверов — 6. Два ОРС-сервера, 2 коллектора и 2 логгера. Второй вариант системы имеет самую высокую степень отказоустойчивости. По умолчанию каждый из логгеров имеют свою собственную конфигурационнцю базу данных и базу данных. В рамках данной статьи определимся с терминами. Конфигурационная база данных содержит все настройки логгера HyperHistorian64, а база данных — архивируемые значения технологического процесса.

Таков краткий экскурс для дальнейшего понимания проблемы, описываемой в статье.

Настройка резервирования — очень тонкая работа. Почему? Задача логгеров — архивировать данные технологического процесса и поддерживать идентичность базы данных. Для этого логгеры постоянно синхронизируются между собой. Синхронизация работает только в том случае, когда конфигурационные базы данных на обоих серверах абсолютно идентичны. Изначально в этом нет ничего сложного: скопировали конфигурационную базу с одного сервера на второй. Сложнее, когда в процессе работы системы требуется внести какие-либо изменения (добавить/удалить тег, изменить временные настройки и т. д.), что приводит к неидентичности некоторых параметров конфигурационных баз данных. Далее я приведу несколько способов обеспечения идентичности.

1) Функция «Pack and Go»

Сразу отмечу, что такой способ не работает в силу того, что некоторые таблицы конфигурационной базы данных не «захватываются» этой функцией. Функция встроена в GENESIS64 для переноса связанных файлов с одной машины на другую. Она напоминает всем известную возможность Эспорта/Импорта. Изначально конфигурация полностью настраивается на одном сервере, после чего с помощью «Pack and Go» упаковывается в XML-файл, переносится на второй сервер и разворачивается на нем.

Pack and Go

2) Функция Backup/Restore

Порядок действий схож с первым способом тем, что необходимо создать конфигурацию на одном сервере и скопировать на второй. Но в этом случае копирование осуществляется средствами SQL Express с помощью функции Backup/Restore. Порядок действий следующий:

  1. На первом сервере выполнить для конфигурационной базы команду Backup.
  2. Перенести файл бэкапа на другой сервер.
  3. На втором сервере для конфигурационной базы выполнить команду Restore.

Операцию необходимо выполнять после каждой правки конфигурации логгера.

Ограничение: уже накопленные данные не интегрируются в «новую» конфигурационную баху данных и становятся недоступными для дальнейшего анализа.

 Backup

Restore

3) Использование одной конфигурационной базы данных для двух логгеров HyperHistorian64

Смысл, я думаю, ясен из названия заголовка. В этом случае изменение конфигурации затрагивает оба сервера. Добавлю, что хранить конфигурационную базу данных надежнее на отдельном сервере. На локалных SQL-серверах командой Attach указать нужную базу.

Ограничение: желательно использование дополнительного сервера под хранение конфигурации.

Оставшийся, четвертый, способ в силу большого объема информации я разберу в отдельной статье.

Продолжение следует…


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*