19 ответов в этой теме

[Grigorich1972]

Такая проблема, после очередной перезагрузки сервера, БД стала колом, восстановление клонированием не помогает.

До этого тоже после каждой перезагрузки сервера слетала БД, но клонированием восстанавливалась, поэтому не хочу брать БД из бэкапа. По логу вижу что нарушена какая то схема, а как это исправить?

 

Прикрепленные файлы:

•  drwcsd.log   6,08Мб   5 Скачано раз

[Kirill Polubelov]

Выполните, пожалуйста, следующее:

1. Пуск -> Выполнить... -> cmd <Enter>

2. В открывшемся окне командной строки:

cd "C:/Program Files/DrWeb Server/bin" <Enter>

drwidbsh3.exe -list ..\var\database.sqlite ".schema" >> DRIVEPATH\DIRPATH\FILENAME <Enter>

 

Где DRIVEPATH\DIRPATH\FILENAME -- это ваш выбор, например, c:\utemp\dbsc.txt - файл должен быть доступ для записи.

 

И прикрепите, пожалуйста, сюда его (файл).

Сообщение было изменено Kirill Polubelov: 03 Июль 2015 - 11:36

[Grigorich1972]

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

Прикрепленные файлы:

•  error_log.txt   469байт   7 Скачано раз

[Kirill Polubelov]

В этой ситуации остается только восстановление из бэкапа.

[Grigorich1972]

Восстановил из бэкапа, все заработало.

После перезагрузки сервера опять упала БД.

Подскажите от чего это происходит, уже достает после каждой перезагрузки восстанавливать БД.

Прикрепленные файлы:

•  drwcsd.log   8,08Мб   2 Скачано раз

[Yodjik]

Grigorich1972, как я понял, это происходит из-за того, что сервер ES не останавливается перед выключением системы. Варианта 2: вручную останавливать сервер перед перезагрузкой/выключением или переходить на вшеншюю базу данных.

Особо, я думаю, никто решать эту проблему не будет. Средства для восстановления есть, никто не заставляет использовать внутреннюю базу, никто не запрещает останавливать сервер перед перезагрузкой железа. В общем проблема для разработчиков не мажорная, думаю, находиться в разделе "когда-нибудь..."

[Afalin]

Grigorich1972, в последнем логе у Вас одновременно работали два разных серверных процесса, если мне не показалось, конечно. Вы не пытались перед этим сервер вручную остановить, а после – запустить?

Если пытались, то было бы полезно воспроизвести медленную остановку ещё раз, с детальным журналированием и желательно со снятием дампа процесса во время этой долгой остановки (procdump -ma <pid сервера>, через пару минут после начала остановки).

Есть ещё вариант – на днях должно выйти обновление с багфиксами, в том числе с фиксом проблемы, которая может давать подобные эффекты. Обновиться и посмотреть, не полегчало ли. Если нет – логи и дампы в СТП.

[Valentina Yugai]

Grigorich1972, как я понял, это происходит из-за того, что сервер ES не останавливается перед выключением системы. Варианта 2: вручную останавливать сервер перед перезагрузкой/выключением или переходить на вшеншюю базу данных.

Особо, я думаю, никто решать эту проблему не будет. Средства для восстановления есть, никто не заставляет использовать внутреннюю базу, никто не запрещает останавливать сервер перед перезагрузкой железа. В общем проблема для разработчиков не мажорная, думаю, находиться в разделе "когда-нибудь..."

 

Вообще-то это неправда. Я имею в виду, что разработчикам неинтересна эта проблема.

 

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

[basid]

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

[Yodjik]

Valentina Yugai, да я все понимаю, и очень надеюсь, что все проблемы разработчикам интересны и только обстоятельства не дают решать более актуальные(по мнению клиентов) вопросы.

 

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

 

Ну а на счет "факторов". Конечно не суперкомпьютер, но все же IBM / System x3620 M3 -[7376K8G]-, Intel Xeon E5620 2.40GHz, 16 гигабайт памяти, под систему RAID10, Win Serv 2012 R2. Сервер используется в основном как файловый, никаких тяжелых служб там не крутится. Лицензия ES на 47 машин всего. Ну не должОн он так поступать с базой нехорошо из-за "очень медленного чего-то"

[Grigorich1972]

Хмм, интересно... А почему это не происходило на версии 6?  на другом сервере стоит 6 ка и проблем при перезагрузки не возникало ни разу. Дело в том что перезагрузка происходит 1 раз в неделю по расписанию сторонней программой Airytec Switch OFF. Попробую забить команду на остановку сервера до перезагрузки.

[Yodjik]

Хмм, интересно... А почему это не происходило на версии 6?  на другом сервере стоит 6 ка и проблем при перезагрузки не возникало ни разу. Дело в том что перезагрузка происходит 1 раз в неделю по расписанию сторонней программой Airytec Switch OFF. Попробую забить команду на остановку сервера до перезагрузки.

Если не ошибаюсь, в 6й версии была другая внутренняя база.

[Afalin]

Если не ошибаюсь, в 6й версии была другая внутренняя база.

Та же самая, только предыдущей мажорной версии. Тогда SQLite2, сейчас SQLite3.
Основная гипотеза, почему в 6 версии такое не происходило, – меньшая нагрузка на СУБД. Ну и не стоит говорить, что раньше такого совсем не было, просто тогда сервер с этим чаще запускался и как-то работал, оставляя проблему незамеченной.

[Grigorich1972]

Основная гипотеза, почему в 6 версии такое не происходило, – меньшая нагрузка на СУБД. Ну и не стоит говорить, что раньше такого совсем не было, просто тогда сервер с этим чаще запускался и как-то работал, оставляя проблему незамеченной.

Все равно, в моем понимании, сервер ES работает некорректно раз рушится база после перезагрузки сервера. Я бы понимал если бы это происходило после аварийного отключения питания, но при штатной перезагрузке...

[Afalin]

Все равно, в моем понимании, сервер ES работает некорректно раз рушится база после перезагрузки сервера. Я бы понимал если бы это происходило после аварийного отключения питания, но при штатной перезагрузке...

Зависит от того, насколько штатно при этом выключается сервер, тут тоже есть тонкости.

[Afalin]

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

[Yodjik]

Зависит от того, насколько штатно при этом выключается сервер, тут тоже есть тонкости.

 

Ну если у людей недоумение, то скорее всего выключается все штатными средствами системы, а не выдергиванием пауэркорда из блока питания. Какие могут быть тонкости при перезагрузке, например, штатным "Winkey+X -- Shut down or sign out -- Restart" или из интерфейса Windows Update? Да даже shutdown /r по идее должна корректно перезагружать систему.

[Afalin]

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

Не-не-не, я имел в виду то, как системой при этом завершается процесс ES-сервера. С этим проблемы были, но не помню, полностью решены или нет.

[Grigorich1972]

Проапдейтился... посмотрим поможет или нет.

[Valentina Yugai]

 

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

Не-не-не, я имел в виду то, как системой при этом завершается процесс ES-сервера. С этим проблемы были, но не помню, полностью решены или нет.

 

 

Решены, кроме случаев, если под сервером стоит не серверная ось. У нее настройки другие, на выключение сервисов по умолчанию, если не ошибаюсь, выделяется только 5 секунд. Мы можем не успеть за это время. Поэтому и говорю - в таких случаях нужно систему донастраивать.