DimyanПодскажите прожалуйста как решить такую проблему:
раньше все работало нормально но последнее время dbremote стал останавливатся с надписью "Выполнение завершино", я конечно перезапускаю сервис nnCron'ом для подстраховки, но тем немение dbremote получается частенько простаивает и вся репликация вместе с ним. Подскажте как от этого избавится?
Проблемы с сетью, FTP или почтовым сервером. Как вариант - не запускать сервисом, а запускать в батч-режиме (параметр -b), где он делает молча свою работы и выходит. Настроить же периодчность и вызов можно и через события ASA.

Dimyan
ASCRUS пишет:
> Проблемы с сетью, FTP или почтовым сервером. Как вариант - не запускать
> сервисом, а запускать в батч-режиме (параметр -b), где он делает молча
> свою работы и выходит. Настроить же периодчность и вызов можно и через
> события ASA.

А что вообще что из себя представляет батч-режим?
Posted via ActualForum NNTP Server 1.2
Запустился, получил изменения, отправил свои изменения, закончил работу.

Рыжий Кот ASCRUS Dimyan
ASCRUS пишет:
> Проблемы с сетью, FTP или почтовым сервером. Как вариант - не запускать
> сервисом, а запускать в батч-режиме (параметр -b), где он делает молча
> свою работы и выходит. Настроить же периодчность и вызов можно и через
> события ASA.

А что вообще что из себя представляет батч-режим?
Posted via ActualForum NNTP Server 1.2
Запустился, получил изменения, отправил свои изменения, закончил работу.

не все так гладко: если сообщение пропущено, то он все скачает, потом до него допрет, что сообщение пропущено и от отошлет реквест, и только в следующий запуск он получит все сообщения. Причем при приеме может опять что-то потеряться :). Так что без nncron пока никак...
А что, разве работая сервисом он не так же будет засыпать на установленное время, как будет запускаться с такими же интервалами через событие ?

Возвращаясь к вопросу. У нас репликация идет через FTP. Иногда сеть отваливается и соотвествующе сервис на DBRemote останавливается. Что я сделал:
1. Сервис запускаю через нормальную, а не локальную учетную запись, со следующими обязательными параметрами:
Здесь я включаю запись лога работы консолидированной БД и ошибок удаленных в файлы, так как консоли мы не видим. Плюс параметр "-k" говорит серверу репликации, что после завершения работы обязательно выйти и остановить сервис.
2. В консолидированной БД создал событие:
Теперь раз в час ASA пытается запустить сервис репликации через свою утилиту запуска сервисов. Естественно, если он уже запущен, то ничего не произойдет, а если он остановился по каким либо причинам, то будет автоматически запущен через это событие вновь.

По вкусу:
1. Как и на любое событие ASA можно навесить несколько sheduler, где например в зависимости от дней недели с разной частотой проверять и поднимать сервис.
2. Раз уж у нас есть лог-файлы хода работ, то запускаем ASA с параметром "-xs http(port=80)", пишем веб-сервис, который внутри вызывает хранимку, которая считывает через xp_read_file и возвращает лог-файл работы удаленного сервера. В итоге через браузер всегда можем быстро посмотреть, что там на сервере репликаций твориться.

Рыжий КотASCRUS,
так вот есть 2 момента:
1. может наступить такой момент, что чтобы прокачать все сообщения часа не хватит; полУчите бесконечный цикл

У меня вообще то FTP сервер по отношению к консолидированной БД на локалке висит и как я получу бесконечный цикл что то не понимаю. Ну бывает локалка мин на 5 просела раз в пару дней, чего бы это вдруг ей времени все сообщения прокачать не хватит ?

Рыжий Кот2. бывают моменты, когда сервис просто висит;
З.Ы. -k является причиной высокой латентности
Вот как раз с параметром -k и не висит. Моделировали различные ситуации, четко останавливается и через событие потом поднимается. Плюс на случай других ошибок задействована опция вызова ХП на ошибки репликации, которая автопилотом рассылает уведомления с текстом ошибок админам текущего узла. Насчет латентности честно говоря не понял.

Рыжий Котони бы СУЩЕСТВЕННО облегчили жизнь людЯм, если б:
1. при перезапуске (или запуске) сервиса dbremote сохранялась инфа, о том что закачено и начинать проверку очереди с момента прекращения работы;
2. сделать что-то вроде реинициализации, когда задается промежуток времени, спустя который, если по каналу dbremote не принял ни одного байта, проиходит новое подключение. Причем количество подключение до "выполнение завершено" задается админом.

Просто странно, что они до сих пор фигней маются
Тут не попишешь, их много просят об этом, может в 10-ке и сделают, а может и не сделают ;)

По поводу предложенного решения - если в событие не просто вызывать утилиту запуска сервиса, а получать ее ERRORLEVEL:
То случай, когда @error = 0 будет означать, что сервис был успешно запущен, то есть перед этим находился в остановленном состоянии. Соотвествующе можно опять же разослать по мылу уведомление о перезапуске сервера админимам, вывести сообщение в лог БД или еще чего нибудь сделать :)

Рыжий КотСпустя какое-то время, когда эйфория от dbremote проходит, видны все огрехи.
Разработчикам нужно всего ничего, чтобы сделать из хорошего продукта блистательный. Что им мешает?
Ну у меня все проще - интервал репликации достаточно большой, консолидированная обращается к FTP через локалку, удаленные узлы работают в запуске репликации по требованию или раз в день автоматом. Плюс обьем данных небольшой идет, поэтому конечно же таких проблем не возникает и решение предложенное мною работает.

Ну а насчет "кто мешает" - нужно идти к ним на форум и долбить, долбить, долбить ... :)