Подготовка к репликации

Материал из Info

Перейти к: навигация, поиск

Репликация базы данных представляет собой одно из преимуществ продуктов Microinvest. Через популярную и отлично работающую технологию, пользователи Microinvest могут создавать сложные системы из удаленных объектов и обмениваться данными между собой в реальном времени. Данные объединяются на уровне SQL сервера, могут быть изменены динамически в следствии оперативных задач и представляют собой одно целое. Репликация требует определенных знаний по ее создании, ввода номенклатур и базовых настроек. Данный материал рассматривает основы создании номенклатуры, определения прав доступа и роль каждого участника в системе.

Содержание

Основы репликации

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

  • Технология Publisher – Subscriber. При которой существует центральный сервер, являющейся основным в системе. Он принимает и отправляет данные к отдельным серверам;
  • Технология Master-Master. Каждый сервер является основным для следующего в цепочке и подчиненным для предыдущего. Это так называемая круговая репликация;
  • Технология Master-Slave. Данная технология требует одновременную работу с двумя серверами, где один является центральным, а другой служит для облегчения трафика через Internet. Между двумя серверами обязательно требуется непрерывная Internet связь.

В текущей статье затронуты все 3 варианта репликации, где за последнее время на практике утвердился только Вариант 1. Данный вариант является самым стабильным при временном отсутствии Internet связи и гарантирует беспроблемную работу. Кроме того он и самый логичный с точки зрения пользователей и дает равноправную связь между всеми удаленными объектами, без нарушении работы при временном отсутствии связи.

Подготовка системы

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

Первые шаги

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

  • Репликация сохраняет зеркальную копию всех данных между SQL серверами. Это является причиной по которой основную часть номенклатуры нужно настроить до создания репликации. Репликация должна передавать только разницу;
  • Сервера обменивают данные асинхронно. Это означает, что определенная операция может быть совершена в одном объекте, но все еще не передана к другим объектам. Следовательно каждый оператор должен работать только в своем объекте и ни в коем случае не мешать работе другого объекта. Используется прикрепление операторов к объектам;
  • Если нет активной Internet связи, диапазон нумерации документов определяется локально. Потому объекты должны рассчитывать только на собственный сервер и иметь индивидуальную нумерацию по объектам. Не позволено одному оператору работать с нескольких объектов;
  • Каждый сервер отвечает за операции на своем объекте. Ни в коем случае нельзя смешивать приходы и продажи одного оператора в разных объектах. Потому обязательно делается прикрепление операторов к локальному серверу и он должен работать только со своего объекта.
  • При необходимости произвести операции для конкретного объекта, важно подключаться к конкретному подписчику, так как если операция влияет на остатки, сразу возникнет конфликтная ситуация обновления остатков. Для таких целей используется подключение с командным параметром /config#, в котором содержатся данные для связи с выбранным подписчиком.

Указанные правила являются минимальным условием для начальной подготовки и старта режима репликации данных. Важно ввести строгие и ограничительные права доступа операторам, каждый с заданными правами и уровнем доступа.

Создание номенклатуры

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

  • Объекты. Планирование объектов обязательно должно быть совершено перед созданием всех остальных номенклатур;
  • Пользователи. Создание номенклатуры пользователей связано с их распределением по объектам.

Таким образом, список объектов и пользователей должен быть создан в центральной базе. После этого следует точная настройка пользователей и прав доступа, и только потом строится репликация между серверами. Так как эти номенклатуры управляются централизованно, их правильное планирование - ключ к работоспособности всей системы.

Права доступа и ограничение

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

  1. Каждый оператор работает единственно со своим объектом. В тоже время пользователи работают с локальным сервером и не имеют доступ до удаленного;
  2. Права доступа имеют ограничительный характер и позволяют только необходимые операции, нет доступа до всей системы. Необходимо максимально точно ограничить действия пользователей;
  3. Номенклатуры строятся вначале, они относительно постоянны и изменения делаются в соответствии предварительно созданной системы на уровне фирмы. Введенные принципы должны исключать дублирование номенклатуры (например централизованный ввод);
  4. Про добавлении новой номенклатуры необходимо сохранить общие правила организации, например первый объект с кодом 1000, второй с кодом 2000 и т.д. разделение номенклатуры по времени является другой возможностью, определенные позиции добавляются утром, другие после обеда и таким образом нет смешивания данных.

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

Автоматическая нумерация номенклатуры

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

Нумерация объектов

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

  1. Каждый объект должен работать в собственном диапазоне. Этот диапазон должен быть достаточно большим, чтобы номера одних документов не совпадали c номерами документов другого объекта, даже после 2-3 лет работы. Обыкновенно, диапазон от 100 000 до 1 000 000 номеров между объектами вполне достаточен;
  2. Каждый отдельный сервер должен работать только с одним объектом или с несколькими объектами, которые не обрабатываются другими серверами. Принцип состоит в том, что каждый сервер обрабатывает только свои объекты. Настройка объектов наиболее важна для правильной работы всей системы. Даже у опытных администраторов настройка должна быть проверена несколько раз, прежде чем перейти к следующему шагу.

Создание и прикрепление пользователей

Пользователи - это основная часть системы репликации. Создается номенклатура, после чего каждый пользователь прикрепляется к своему объекту таким образом, чтобы он мог работать только со своим объектом. Это особенно важно для снижения путаницы с нумерацией документов. Недопустимо, чтобы пользователь работал на чужом объекте, который не в его собственном сервере. Правильное распределение деятельности требует четкое определение процессов. Через ограничение прав пользователей и привязки по объектам исключаются коллизии в системе, когда один пользователь проводит операции на своем сервере, а другой пользователь редактирует уже проведенные операции. Желательно права доступа сильно ограничить. Ввод дополнительных ограничений делает систему значительно стабильней и не нарушает стандартную работу пользователей.

Права доступа

Правильное распределение деятельности требует точной формулировки и настройки прав доступа. Через ограничение пользователей исключаются случаи в системе, когда один пользователь совершает операцию в собственном сервере, а другой меняет уже сделанные операции. Желательно, чтобы право доступа было сильно ограничено. Введение больших ограничений делает систему значительно стабильнее.

Создание репликации

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

Краткая последовательность

Все эти действия могут быть описаны в следующей краткой последовательности:

  1. Создание номенклатуры объектов;
  2. Запуск и настройка нумерации по объектам;
  3. Создание пользователей. Каждый пользователь прикрепляется к своему объекту;
  4. Определяются права доступа. Каждый работает только в своем объекте, со своим сервером;
  5. Создается основная номенклатура товаров и партнеров;
  6. Устанавливается Microinvest Utility Center и настраивается расписание в 30 минут для модуля Rebuild Store согласно документации;
  7. База переключается в режим репликации, и каждое рабочее место связывается только с своим SQL сервером.

Эти действия гарантируют 100% успеха в каждой отдельной репликации.

Часто встречающиеся ошибки

Ошибки, которые часто встречаются и нужно избегать:

  1. Не выполнены основные требования:
    • Работа без настроенной нумерации по объектам;
    • Отсутствие привязки операторов к объектам;
    • Не заданы права доступа операторам, когда один оператор может работать от имени другого объекта;
    • Неправильная конфигурация времени репликации данных на уровне SQL сервера. В таком случае будет огромное замедление работы или даже потеря данных на уровне SQL сервера.
  2. Работа одного оператора в удаленном для него объекте. Например оператор с Магазина 1, связан с сервером 1, выполняет продажи с удаленного для него Магазина 2, который обслуживает SQL сервер 2. Так пересекается нумерация документов удаленного объекта. Потому каждый оператор должен работать только со своего объекта.
  3. Одновременный ввод номенклатуры с разных мест без предварительной синхронизации. Таким образом можно ввести Товар А с кодом 1, а на другом сервере ввести Товар Б с кодом 1, на третьем Товар В с кодом 1. Вся картина товаров получится когда все сервера синхронизируются и объединится номенклатура. В данном случае будет несколько наименований товаров с одним и тем же кодом , вопреки тому что программа не предупредила операторов об этом (перед синхронизацией нет обмена данными и потому реально нет дублирования данных).
  4. Остановка репликации более чем на 14 дней без возможности альтернативной синхронизации. В таком случае необходимо повторно инициализировать репликацию и восстановить данные и процессы;
  5. Изменение IP адреса на одном из SQL сервера без отображения на центральной машине. В таких случаях теряется связь между удаленным компьютером и центральным сервером.

Если избегать подобные ошибки можно гарантировать беспроблемную работу целой системы за очень долгий период времени.

Частоиспользуемые скрипты для управления MSSQL Merge репликацией

-- Выборка покажет где какие диапазоны
Select [name], [pub_range], [range], [threshold] FROM sysmergearticles WHERE [threshold] IS NOT NULL

-- Обновление поменяет на 1000000
update sysmergearticles set [pub_range] = 1000000, [range] = 1000000, [threshold] = 95 WHERE [threshold] IS NOT NULL
-- После чего необходимо делать сдвиг диапазонов, указав имя публикации
sp_adjustpublisheridentityrange @publication = ''

-- Просмотр наличия конфликтов при нескольких реплицированных базах
EXEC sp_MSforeachdb 'USE ? IF (SELECT ISNULL((SELECT OBJECT_ID(''msmerge_Conflicts_info'')),0)) > 0 
SELECT ''?'', * from dbo.msmerge_Conflicts_info'

-- Даты последнего успешного обмена с подписчиками
SELECT 
	ID, subscriber_name, msmerge_agents.publisher_db, max(start_time) AS [LatestSuccess], retention
FROM 
	distribution.dbo.MSmerge_sessions 
	INNER JOIN distribution.dbo.msMerge_agents ON msmerge_agents.id = msmerge_sessions.agent_id 
	LEFT JOIN distribution.dbo.MSpublications ON msmerge_agents.publisher_db = MSpublications.publisher_db
WHERE 1=1
	AND runstatus = 2
GROUP BY subscriber_name, msmerge_agents.publisher_db, ID, retention

Надежность

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

Другие

Продукты Microinvest используют все возможности одной из самых прогрессивных технологий управления данными – репликация между отдельными SQL серверами. Для успешного старта процессов репликации достаточно выполнить указания в данной статье. Настройка и поддержка стабильно работающей системы в режиме репликации не сложная и требует минимум усилий со стороны технической поддержки. Основные вопросы затрагивают организацию персонала , права доступа отдельных пользователей и сохранение основных принципов совместной работы. Когда все настроено по требованию еще с самого начала, тогда нет никаких затруднений в оперативной работе.

Некоторые полезные ресурсы