Реализация репликации данных

[sergeypp]

Снова поднимаю давно избитую тему. Много было сказано о том надо или не надо ее использовать, а о том как ее использовать, какими методами ее реализовывать не особо. Тема конечно затрагивалась но не раскрывалась.. но это все вода.. теперь ближе к делу.
Была поставлена задача реплицировать набор справочников из головного офиса в дочерние. Есть обязательное условие: все справочники заводятся в Центральном офисе.
На текущий момент я вижу следующие проблемы при реализации репликации
1. RecID. Генерация «своих» RecID на подписчиках.
2. Невозможность синхронизации таблиц на публикаторе при использовании стандартной репликации MSSQL
3. При стандартной репликации MSSQL проблемы с восстановлением базы из архивной копии
4. Номерные серии на подписчике
5. Добавление новых полей в таблицы сводится к пересозданию всей репликации
6. Код фирмы ‘dat’.
7. При репликации MSSQL контроль первичных ключей (По умолчанию DataAreaID и RecId). Если RecID будет меняться на подписчике, то может быть дублирование записей
8. При использовании репликации MSSQL на таблицах создаются триггеры.

Теперь краткие пояснения
1. можно конечно извратиться и написать процедуру, но сколько будет подводных камней никто не знает
2. пока таблицы будут учавствовать в репликации изменить их скуль не даст, так же как и не даст поднять базу из бакапа (не дай бог). Если же каким то хитрожопым способом удастся таблицу синхронизировать, то слетят тригеры на таблице, которые навешивает репликация. Короче, если не ветрянка, то понос.
3. см. выше
4. тут проще и можно закрыть глаза, так как справочники заводятся на публикаторе.
5. точнее так. Желание добавить поле, требует пересоздания репликации (см. 2)
6. Везде по одной компании, коды будут одинаковы. пропускаем
7. Если первичный ключ включает поле RecId, а репликация использует этот ключ, то при изменении RecId на подписчике на RecId базы подписчика может дать и точно даст сбой. при инсерте - дублирование, при апдейте и удалении, ошибка о том, что невозможно найти запись
8. см пункт 2.

Вот что мы имеем в итоге. Я хочу предложить на растерзание следующую схему
1. Данные из Аксапты попадают в специальную базу
2 Эта база реплицируется на подписчик,
3. там эти данные переносятся в аксапту

Теперь о том как это должно происходить.

1. Можно повесить тригеры, которые будут обрабатывать изменения, но при первой же синхронизации, тригеры слетят и все пойдет прахом. А программисты очень любят про это забывать.. ладно если потом скажут. Поэтому нужно другое решение. Например джоб с хранимкой, которая ослеживает по ModifyTime и перекладывает записи. Но тут могут быть проблемы с удалением. Их нельзя будет отследить.
Возможен вариант, что бы аксапта сама отслеживала изменения, внутренним функционалом, а потом делала SQL инструкцию по вставке данных в другую базу в таблицу (Кстати так и работет репликация Коруса для Кристалла). Если подписчиков будет несколько то скорее всего для каждого подписчика нужно будет создавать свою запись (планируется хранить и передавать измененные данные а не полную копию таблицы) а то потом не поймешь кто забрал а кто нет и когда запись нужно удалять. В итоге мы положили изменившиеся данные из аксапты в отдельную базу

2. База переносится на подписчики, здесь можно использовать как и репликацию транзакциями , так и передачу данных с помощью DTS . как лучше пока не знаю, может вы скажите?? В итоге мы имеем данные на сервере подписчика.

3. Как закатывать данные в аксапту? можно хранимкой, но тут возникает проблема сгенерацией RecID. Можно написать пакет в аксапте, который будет с определенной периодикой закатывать запросы к соседней базе в SQL инструкции, обрабатывать полученные данные и вставлять их внутренними средствами. Данные "успешно" отреплицировались.
Немного запутанно, но все же наверное понятно..
У кого есть какие замечания и советы по поводу этой схемы, может кто то использует другую схему, поделитесь знаниями. Что я не учел, какие проблемы еще могут возникнуть и.....
... Давайте не будем обсуждать что распределенка это плохо, давайте обсуждать КАК ее сделать..

[Андре]

Извини, постараюсь попозже найти время и более подробно ответить на вопросы.

Если в общем, то лучше с репликацией вообще не связываться.

Сделать можно (в том или ином объеме). Мы делали с помощью журнала базы данных.

Нужные таблицы журналируются, таблица 'журнал бд' экспортируется и передается по ftp, email или какому-либо другому каналу связи, а потом изменения 'проигрываются' на подписчике.

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

[gl00mie]

Цитата:

Сообщение от sergeypp

На текущий момент я вижу следующие проблемы при реализации репликации
RecID. Генерация «своих» RecID на подписчиках.
Номерные серии на подписчике
Добавление новых полей в таблицы сводится к пересозданию всей репликации
Код фирмы ‘dat’.

Мне кажется, эти и другие проблемы являются убедительными аргументами против непосредственного применения штатной MsSQL'ной репликации. По любому понадобится некая прослойка в самом приложении, которая будет заниматься репликацией и "сглаживанием острых углов". К слову, с RecId может быть связано множество нехороших побочных эффектов, например, это может проявиться в таблице адресов, текстов склада и прочих, использующих связи по RecId.

Цитата:

Сообщение от sergeypp

Возможен вариант, что бы аксапта сама отслеживала изменения, внутренним функционалом, а потом делала SQL инструкцию по вставке данных в другую базу в таблицу (Кстати так и работет репликация Коруса для Кристалла)

Ну вот и подтверждение обоснованности такого варианта

Цитата:

Сообщение от sergeypp

Как закатывать данные в аксапту? можно хранимкой, но тут возникает проблема сгенерацией RecID. Можно написать пакет в аксапте, который будет с определенной периодикой закатывать запросы к соседней базе в SQL инструкции, обрабатывать полученные данные и вставлять их внутренними средствами.

Если реализовать репликацию с использованием прослойки в приложении, то эта же прослойка может давать сигнал подписчикам, что есть данные для обновления и следует их загрузить. При этом можно не "заставлять" подписчиков загружать данные, а именно информировать, а уж подписчик при наличии такого сигнала отработает репликацию в подходящий момент. Именно так, во всяком случае, происходит репликация данных Active Directory между доменными контроллерами...

[sergeypp]

Цитата:

К слову, с RecId может быть связано множество нехороших побочных эффектов, например, это может проявиться в таблице адресов, текстов склада и прочих, использующих связи по RecId.

я позже перечислю список таблиц для репликации, что бы более предметно вести разговор

[Alexius]

На мой взгляд репликация имеет право на существование при существенных ограничениях. У нас реализована репликация транзакций ВСЕЙ виртуальной компании - полет нормальный. Теперь детально:
1. Нет проблем, были в начале, когда в Аксапте подписчике были права на изменения и добавления в виртуальных таблицах.
2. Да, надо переинициализировать репликацию после синхронизации.
3. Не вижу проблем
4. Нет проблем при односторонней репликации
5. Да, надо переинициализировать репликацию после синхронизации.
6. ???
7. При однонаправленной репликации, нет проблем.
8. При использовании репликации транзакций MSSQL на таблицах не создаются триггеры.

[George Nordic]

3йка или 4ка? В 4ке не будет проблем с RecId.

Можно просто перегонять данные в промежуточную таблицу и закачивать в основную (или через журналы). Тогда не будет проблем ни с RecId, ни с номерными сериями. Вопрос, насколько точная нужна репликация. Надеюсь, не с точностью до номерной серии и RecId.

С Уважением,
Георгий

[sergeypp]

Цитата:

Сообщение от George Nordic

3йка или 4ка? В 4ке не будет проблем с RecId.

3-ка sp3

Цитата:

Сообщение от George Nordic

Можно просто перегонять данные в промежуточную таблицу и закачивать в основную (или через журналы). Тогда не будет проблем ни с RecId, ни с номерными сериями. Вопрос, насколько точная нужна репликация. Надеюсь, не с точностью до номерной серии и RecId.

Как сказать.. точная или нет.. нужно что бы данные были одинаковы.. До RecID конечно нет, а номерная серия должна сохраняться. но она будет нужна только на публикаторе. на подписчике данные меняться не будут

Цитата:

Сообщение от Alexius

1. Нет проблем, были в начале, когда в Аксапте подписчике были права на изменения и добавления в виртуальных таблицах.
2. Да, надо переинициализировать репликацию после синхронизации.
3. Не вижу проблем
4. Нет проблем при односторонней репликации
5. Да, надо переинициализировать репликацию после синхронизации.
6. ???
7. При однонаправленной репликации, нет проблем.
8. При использовании репликации транзакций MSSQL на таблицах не создаются триггеры.

1. А можно по-подробнее про виртуальные таблицы?
3. Пока база в репликации, восстановить себя она не даст, нужно будет отвязывать всех подписчиков
7. Сомнительно.. возможны частные случаи
8. Еще как создаются. создаются тригеры на добавление, удаление и изменение , которые пишут данные в журнал

Просто возможно существуют другие варианты , например без использования скулевой репликации как таковой вообще.
Данные можно кидать и DTS? правда я не знаю насколько DTS требователен к каналу??.
Интересный вариант и с журналом.. сейчас покопаю туда.
Просто еще вопрос стоит под следующим углом.. Если механизм передачи данных инкапсулировать от пользователей, то последние начинают придумывать ввсякие небылицы о том что данные не пришли или пришли криво, оправдывая тем самым свои ошибки. А если что то действительно начнет работать наперекосяк, можно смело тащить раскладушку на работу. Даже в перепроверенной системе могут вылезти непредвиденные ошибки.
Может дейсвительно есть резон отказаться от схем "теневой" передачи, а выкладывать данные на фтп как вариант и административно принудить пользователей самим обновлять систему. Тогда странных предположений от подльзователей будет намного меньше. Залили файл - данные обновились, Не залили - не обновились, но опять таки разовая заливка может оказаться ресурсоемкой, тогда будут возникать другие жалобы, что они не успевают и не могут работать.. Ньюансов много.. как сделать лучше, пока непонятно

[sergeypp]

Есть методы оценки конечно, но какие критерии выбирать за основу, мне тоже пока не ясно ))
Если у кого то есть реализации репликации, не стесьняйтесь - рассказывайте.. буду благодарен.
2 Alexius. а у Вас 2 базы просто соединены обычной скулевой репликацией транзакциями?? насколько разнесены базы.. база подписчик оперативная или для отчетов, как посупили с RecID ??

[Alexius]

Цитата:

Сообщение от sergeypp

1. А можно по-подробнее про виртуальные таблицы?

Слегка оговорился, имеются в виду таблицы включенные в виртуальную компанию. Это справочники.

Цитата:

Сообщение от sergeypp

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

Да, но разве это проблема по сравнению с потерей рабочей БД ?

Цитата:

Сообщение от sergeypp

7. Сомнительно.. возможны частные случаи

У нас в базе подписчике пользователи лишены прав на редактирование реплицируемых таблиц.

Цитата:

Сообщение от sergeypp

8. Еще как создаются. создаются тригеры на добавление, удаление и изменение , которые пишут данные в журнал

У меня нет никаких триггеров на реплицируемых таблицах MS SQL 2005 SP2 при транзакционной репликации.

[Alexius]

Цитата:

Сообщение от sergeypp

у Вас 2 базы просто соединены обычной скулевой репликацией транзакциями??

Да

Цитата:

Сообщение от sergeypp

насколько разнесены базы..

Локальная сеть единая, сервера БД разные

Цитата:

Сообщение от sergeypp

база подписчик оперативная или для отчетов

Оперативная

Цитата:

Сообщение от sergeypp

, как посупили с RecID ??

Виртуальная компания транслируется полностью, создание и редактирование записей разрешено только на базе-публикаторе, на подписчике эти данные(справочники) используются только для чтения, RecId реплицирутся как и все остальные поля.

[glibs]

Я бы попробовал в данном случае проработать такой вариант. Некоторые таблицы из ЦО средствами MS SQL реплицируются в отдельную БД в филиале. Пакетное задание... предположим, по дате обновления записи... анализирует таблицу в отдельной БД в филиале, и пытается синхронизировать справочник в БД Аксапты в филиале.

Удалять, надеюсь, не нужно? И с переименованием будет непросто. Возможно, придется допиливать и приложение ЦО.

[KiselevSA]

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

[glibs]

Цитата:

Сообщение от KiselevSA

...
Надо будет только модифицировать выгрузку так, чтобы она брала только модифицированные записи
...

Уж лучше свою написать, чем корежить стандартную.

Тут вопрос формата данных?

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

Что касается отслеживания — есть нюансы. Например. Допустим, что номенклатуру удалять мы не будем. Но пересчет единиц измерения или какой-нибудь штрих-код, по идее, можем. Тупым импортом не отделаться. Именно такие вещи я имел в виду, когда писал "пытается синхронизировать справочник в БД Аксапты в филиале".

[twilight]

По-моему лучше сделать выгрузку и загрузку справочников через xml файлы

[sergeypp]

Цитата:

Сообщение от Alexius

на подписчике эти данные(справочники) используются только для чтения, RecId реплицирутся как и все остальные поля.

А проблем с пересечением не может быть? как этот момент обошли?

у меня 2000 скуль.. значит на 2005 другой механизм репликации


А если тупо выкачивать данные с помощью DTS ориентируясь на поля ModifyDate и ModifyTime. А на подписчике заливать их прямо в таблицы.
Насколько DTS требователен к каналу?? Кто нибудь сталкивался?

[TasmanianDevil]

sergeypp, а Вы не подумали , что произойдет с Вашими данными после (не дай бог, конечно) дефрагментации RecId в базе-источнике ?

[Alexius]

Цитата:

Сообщение от sergeypp

А проблем с пересечением не может быть? как этот момент обошли?

В АХ 3.0 RecId выделяется для компании (реальной/виртуальной), т.к. реплицируется вся виртуальная компания, а на подписчике заведение новых записей запрещено, то пересечение RecId исключается.

[sergeypp]

Цитата:

Сообщение от TasmanianDevil

sergeypp, а Вы не подумали , что произойдет с Вашими данными после (не дай бог, конечно) дефрагментации RecId в базе-источнике ?

А разве при дефрагментации меняются поля Modify... ?
при вставке можно подменять RecID.
А еще хотел расспросить про виртуальную компанию..
Т.е. создается виртуальная компания, в нее переносят ся все таблицы справочники.
Для них выделяется свой диапазон RecID
На базе подписчике тоже нужно создавать вирт компанию?? или можно без нее..
после этого мы реплицируем справочники из вирт компании и след не имеем проблем с генерацией и пересечением RecID/
я правильно понял?

[Alexius]

Цитата:

Сообщение от sergeypp

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

Да

Цитата:

Сообщение от sergeypp

На базе подписчике тоже нужно создавать вирт компанию?? или можно без нее..

Нужно

Цитата:

Сообщение от sergeypp

после этого мы реплицируем справочники из вирт компании и след не имеем проблем с генерацией и пересечением RecID/
я правильно понял?

Да, если подписчик ReadOnly.

[sergeypp]

А на подписчике и публикаторе при создании вирт компании RecID в одинаковых диапазонах выделяются и в каких?