Репликация данных АСКПС - "Инфотэкс

iluha · 14-10-2010, 16:00

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

на данный момент в версии репликатора 1.0.0.10 выявлена проблема при двустороннем обмене данными (с применением фильтра). ошибка возникает при передаче данных таблицы T_DRAWOBJ (duplicate key). эта проблема будет решена в ближайшее время в следующей версии репликатора.

Цитата:

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


	8. Есть еще одно неудобство: сейчас сформированы схемы на отделениях, допустим я хочу добавить стыки(и тут возвращаемся к пункту №6 как реплицировать с фильтрацией, девайсы не идут, может конечно я кривой, но мне кажется дело в репликаторе). При ручной конвертации девайсов в базу сервера, при репликации девайсов на сервер, мне придется руками удалить таблицу дравтобжект и заново создать схемы ибо не будет заполняться поле рефсерверайди и не будет привязки к схеме девайсов, а при репликации еще и историю репликатора стирать нада. При условии что вагонники официально бумагой требуют вывести стыки по отделениям и другим дорогам станции до ближайшего ПТО. Как поступать ?

ничего не понял. звоните.

п.6 - проблема выявлена

Цитата:

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


	6. Проверили еще раз при включении фильтра девайсы не реплицируются. Как настроить стыки с помощью нового репликатора?

еще из письма с ВСЖД:

Цитата:


	При добавлении в фильтр репликатора кода (DeviceID) дальнейшая репликация нововведенного устройства не происходит

репликатор запоминает ID последней переданной записи. если у КТСМ после включения его в фильтр конфигурация не менялась - то она (конфигурация) передана не будет (таблицы T_NSI_DEVICES, T_LOG_DEVICES). подумаем, как это решить. а пока что хинт - после добавления устройства в фильтр измените его конфигурацию (параметр какой-нибудь измените и верните назад)

iluha · 14-10-2010, 16:27

Внимание! для репликации БД АСКПС в ИНФОТЭКС необходимо всем администраторам АСКПС сообщить мне хосты репликаторов (IP : port), на которых доступна дорожная база данных. имя пользователя должно выглядеть как SR_ASCPS_xx, где xx - код дороги.

на данный момент мы получаем информацию со следующих дорог:
01 - Октябрьская
17 - Московская
24 - Горьковская
28 - Северная
51 - Северо-Кавказская
63 - Куйбышевская
76 - Свердловская
80 - Южно-Уральская
83 - Западно-Сибирская
92 - Восточно-Сибирская
94 - Забайкальская
96 - Дальневосточная

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

в случае отсутствия доступа на хост репликатора необходимо на уровне дороги обеспечить такой доступ для IP ИНФОТЭКС - 10.76.0.74

iluha · 14-10-2010, 17:21

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

iluha · 20-10-2010, 11:51

привожу ответ письмо с МЖД насчет возникшей проблемы. при возникновении подобных случаев - руководство к действию.

===
Здравствуйте, Болотин!

Wednesday, October 20, 2010, 10:00:52 AM, Вы писали:

БАЮ> После внесения изменений в схеме на сервере-архиваторе
БАЮ> развалилась БД на основном терминальном сервере, который получает
БАЮ> информацию от архиватора посредствам ПО "Репликатор"

какого рода изменения были сделаны?

БАЮ> Какие будут рекомендации по исправлению ситуации?

во-первых - зазипуйте подкаталог "tmp" принимающего репликатора и
пришлите мне.

БАЮ> 2010-10-20 08:42:50.184 SQL: ""
БАЮ> error: 1062, "Duplicate entry '1701-1245' for key 'PRIMARY'"
БАЮ> query: INSERT INTO t_log_devices

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

delete from t_log_devices where ServerID = 1701 and DevLogID >= 1245

если аналогичная ошибка возникнет для t_drawobj, то запрос будет
выглядеть так:

delete from t_drawobj where SerevrID = 1701 and DrawID >= ...

С уважением,
Илья Компанец
===

PS. процитированная ситуация, как выяснилось, произошла в результате изменения конфигурации ЦПК в реплицированной БД! Это грубое нарушение. Вносить изменения в БД, полученную путём репликации, категорически нельзя. Исключение - таблица T_DRAWOBJ, в которой разрешается создавать схемы с уникальным ServerID (не совпадающим ни с одним из реплицированных). То есть, схему общую сделать в Редакторе ЦПК можно, но конфигурацию устройств менять нельзя.

u-1 · 21-10-2010, 14:19

Сейчас настроена репликация стыковых девайсов между отделениями. Девайсы, все данные - всё как полагается - благополучно реплицируются согласно фильтру. Т.е. с НОД-4 на НОД-1 приходят данные по 12 КТСМам. Всё ок.
Нельзя ли как-то ограничить репликацию t_drawobj ? Потому что на сервере НОД-1 совершенно не нужны схемы с НОД-4. В принципе, критичного, конечно, ничего нет, просто лишняя ненужная информация на сервере. По сути, репликация t_drawobj мне на данный момент вообще не нужна (хотя может, пока?).

iluha · 13-11-2010, 16:43

Цитата:

Сообщение от u-1


	Сейчас настроена репликация стыковых девайсов между отделениями. Девайсы, все данные - всё как полагается - благополучно реплицируются согласно фильтру. Т.е. с НОД-4 на НОД-1 приходят данные по 12 КТСМам. Всё ок. Нельзя ли как-то ограничить репликацию t_drawobj ? Потому что на сервере НОД-1 совершенно не нужны схемы с НОД-4. В принципе, критичного, конечно, ничего нет, просто лишняя ненужная информация на сервере. По сути, репликация t_drawobj мне на данный момент вообще не нужна (хотя может, пока?).

это решено в версии репликатора 1.0.0.12, доступна для скачивания с FTP:
ftp://10.76.0.80/pub/updates/repld-1.0.0.12.zip

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

u-1 · 25-11-2010, 17:01

1. Если в существующий фильтр добавить новый девайс -- он не реплицируется.
т.е. если в Filter: 1111 ( DeviceID in (1,2) ) дописать третий id -- фильтр его не подхватит, данные будут продолжать идти только по двум.

2. В предыдущем репликаторе можно было инклюдами прописывать логические имена. В новом фильтр по логическим именам не настроить - t_nsi_devices приходят те, что надо, но база льётся абсолютно вся.
Так делать, конечно, совсем не по документации, может оно и не требуется, но по-моему было бы удобней передать логические имена на соседнюю дорогу для репликации, чем выискивать их DeviceID из АРМа или из базы.

iluha · 25-11-2010, 17:34

Цитата:

Сообщение от u-1


	1. Если в существующий фильтр добавить новый девайс -- он не реплицируется. т.е. если в Filter: 1111 ( DeviceID in (1,2) ) дописать третий id -- фильтр его не подхватит, данные будут продолжать идти только по двум.

см. выше:

Цитата:


	репликатор запоминает ID последней переданной записи. если у КТСМ после включения его в фильтр конфигурация не менялась - то она (конфигурация) передана не будет (таблицы T_NSI_DEVICES, T_LOG_DEVICES). подумаем, как это решить. а пока что хинт - после добавления устройства в фильтр измените его конфигурацию (параметр какой-нибудь измените и верните назад)

и это скоро будет внесено в документацию. иначе никак.

Цитата:

Сообщение от u-1


	2. В предыдущем репликаторе можно было инклюдами прописывать логические имена. В новом фильтр по логическим именам не настроить - t_nsi_devices приходят те, что надо, но база льётся абсолютно вся.

откуда такой вывод? фильтруются все таблицы

Цитата:

Сообщение от u-1


	было бы удобней передать логические имена на соседнюю дорогу для репликации, чем выискивать их DeviceID из АРМа или из базы.

насчет удобства - согласен. в новой версии ЦПК я сделаю более удобным процесс вычленения DeviceID из конфигурации

u-1 · 25-11-2010, 17:50

Цитата:


	откуда такой вывод? фильтруются все таблицы

беглым осмотром t_train

iluha · 25-11-2010, 18:00

Цитата:

Сообщение от u-1


	беглым осмотром t_train

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

14-10-2010, 16:27	#2
iluha Эксперт Регистрация: 17-03-2003 Город: Екатеринбург (ИНФОТЭКС АТ) Сообщения: 741	Внимание! для репликации БД АСКПС в ИНФОТЭКС необходимо всем администраторам АСКПС сообщить мне хосты репликаторов (IP : port), на которых доступна дорожная база данных. имя пользователя должно выглядеть как SR_ASCPS_xx, где xx - код дороги. на данный момент мы получаем информацию со следующих дорог: 01 - Октябрьская 17 - Московская 24 - Горьковская 28 - Северная 51 - Северо-Кавказская 63 - Куйбышевская 76 - Свердловская 80 - Южно-Уральская 83 - Западно-Сибирская 92 - Восточно-Сибирская 94 - Забайкальская 96 - Дальневосточная остальным дорогам просьба настроить серверного клиента для репликации в ближайшее время. в первую очередь интересуют дороги, которые уже выключили репликацию данных по версии 2.0.5.4, но не обеспечили репликацию по версии 2.0.8.0 в случае отсутствия доступа на хост репликатора необходимо на уровне дороги обеспечить такой доступ для IP ИНФОТЭКС - 10.76.0.74 __________________ с уважением, Илья Компанец e-mail: iluha@svrw.rzd skype: iluha_com ICQ: 6897292 Последний раз редактировалось iluha, 13-11-2010 в 16:38.

14-10-2010, 17:21	#3
iluha Эксперт Регистрация: 17-03-2003 Город: Екатеринбург (ИНФОТЭКС АТ) Сообщения: 741	и еще, для отладки репликации и оперативного устранения ошибок обсепечьте доступ на сервера, где работают репликаторы. желательно по RAdmin. и прошу учесть, что стандартный порт RAdmin закрыт безопасниками - его надо менять. доступ необходим с адреса 10.76.0.74. все пароли-явки - мне по почте __________________ с уважением, Илья Компанец e-mail: iluha@svrw.rzd skype: iluha_com ICQ: 6897292

20-10-2010, 11:51	#4
iluha Эксперт Регистрация: 17-03-2003 Город: Екатеринбург (ИНФОТЭКС АТ) Сообщения: 741	проблема при репликации привожу ответ письмо с МЖД насчет возникшей проблемы. при возникновении подобных случаев - руководство к действию. === Здравствуйте, Болотин! Wednesday, October 20, 2010, 10:00:52 AM, Вы писали: БАЮ> После внесения изменений в схеме на сервере-архиваторе БАЮ> развалилась БД на основном терминальном сервере, который получает БАЮ> информацию от архиватора посредствам ПО "Репликатор" какого рода изменения были сделаны? БАЮ> Какие будут рекомендации по исправлению ситуации? во-первых - зазипуйте подкаталог "tmp" принимающего репликатора и пришлите мне. БАЮ> 2010-10-20 08:42:50.184 SQL: "" БАЮ> error: 1062, "Duplicate entry '1701-1245' for key 'PRIMARY'" БАЮ> query: INSERT INTO t_log_devices при аналогичных ошибках удалите на принимающей стороне записи, начиная с указанной по первичному ключу. для примера выше запрос будет выглядеть так: delete from t_log_devices where ServerID = 1701 and DevLogID >= 1245 если аналогичная ошибка возникнет для t_drawobj, то запрос будет выглядеть так: delete from t_drawobj where SerevrID = 1701 and DrawID >= ... С уважением, Илья Компанец === PS. процитированная ситуация, как выяснилось, произошла в результате изменения конфигурации ЦПК в реплицированной БД! Это грубое нарушение. Вносить изменения в БД, полученную путём репликации, категорически нельзя. Исключение - таблица T_DRAWOBJ, в которой разрешается создавать схемы с уникальным ServerID (не совпадающим ни с одним из реплицированных). То есть, схему общую сделать в Редакторе ЦПК можно, но конфигурацию устройств менять нельзя. __________________ с уважением, Илья Компанец e-mail: iluha@svrw.rzd skype: iluha_com ICQ: 6897292 Последний раз редактировалось iluha, 20-10-2010 в 19:40.

21-10-2010, 14:19	#5
u-1 Новичок Регистрация: 18-08-2006 Город: Ярославль (Северная ж.д./ЦПК АСКПС) Сообщения: 32	Пожелание Сейчас настроена репликация стыковых девайсов между отделениями. Девайсы, все данные - всё как полагается - благополучно реплицируются согласно фильтру. Т.е. с НОД-4 на НОД-1 приходят данные по 12 КТСМам. Всё ок. Нельзя ли как-то ограничить репликацию t_drawobj ? Потому что на сервере НОД-1 совершенно не нужны схемы с НОД-4. В принципе, критичного, конечно, ничего нет, просто лишняя ненужная информация на сервере. По сути, репликация t_drawobj мне на данный момент вообще не нужна (хотя может, пока?).

25-11-2010, 17:01	#7
u-1 Новичок Регистрация: 18-08-2006 Город: Ярославль (Северная ж.д./ЦПК АСКПС) Сообщения: 32	1. Если в существующий фильтр добавить новый девайс -- он не реплицируется. т.е. если в Filter: 1111 ( DeviceID in (1,2) ) дописать третий id -- фильтр его не подхватит, данные будут продолжать идти только по двум. 2. В предыдущем репликаторе можно было инклюдами прописывать логические имена. В новом фильтр по логическим именам не настроить - t_nsi_devices приходят те, что надо, но база льётся абсолютно вся. Так делать, конечно, совсем не по документации, может оно и не требуется, но по-моему было бы удобней передать логические имена на соседнюю дорогу для репликации, чем выискивать их DeviceID из АРМа или из базы.