Отправляет email-рассылки с помощью сервиса Sendsay

Полезные советы по автоматизации малого бизнеса

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Свой Бизнес: идеи, советы, секреты" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Декабрь 2008   →
 1
 2
 3
 4
04.12.2008
14:02:25
14:14:50
 5
 6
 7
 8
 9
10
10.12.2008
11:28:35
12:40:35
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
Smbiz.Narod.Ru

Статистика

384 подписчиков
0 за неделю
←   Все выпуски   →

Полезные советы по автоматизации малого бизнеса: Репликация распределенной базы данных


Репликация распределенной базы данных

 

Известно, что современные SQL-серверы имеют встроенные средства репликации баз данных.

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

Даже MySQL имеет средства репликации, по крайней мере в режиме master-slave она вполне работоспособна.

Но для данных системы учета все это использовать я лично категорически не рекомендую. И я в этом не одинок. Конечно, если вы спросите специалистов, они вам расскажу и что совсем не страшно использовать встроенные библиотеки, и что алгоритмы созданы надежные. Хотите - верьте им. Не хотите - не верьте.

Не верьте ни разу, если вы вознамерились заплатить этим самым специалистам за реализацию репликации (ну или иными словами, синхронизации баз данных разных подразделений).

Я приведу в качестве антипримера “Парус”. Я могу это сделать, потому что своими ушами слышал рассказ не самых низкопоставленных менеджеров о том, как идет обмен данными между подразделениями крупной российской нефтегазовой компании.

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

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

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

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

А все остальные аспекты реализации менее важны. Вы можете использовать текстовый формат, XML, сливать новые данные в DBF - это неважно, выбирайте то, с чем удобнее работать (и что меньше места займет).

Вы можете изобрести механизм квитовки - отсылание авторской БД квитанции об успешном вводе порции данных. Мы много лет работали без квитовки, ничего страшного не произошло.

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

Дам только две рекомендации по реализации репликации данных, реализуемой самостоятельно. Первую подсмотрел, вторую вывел сам.

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

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

Еще по теме
В избранное