The Dude 6.40.8 - ошибка базы данных: диск образа базы повреждён

Удалите хранилище dude и импортируйте более старую резервную копию dude.

Я импортировал старую резервную копию Dude, но меня беспокоит, что это может повториться. Свободного места у меня хватает.

Ты (или кто-то ещё) знаете, что это вызывает?

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

Мой друг dB тоже работает с SD-карты. Я подумываю поменять micro SD на USB-to-SATA переходник и подключить небольшой SSD для базы данных. Я пробовал подключать жесткий диск через USB-to-SATA, диск определяется, я его отформатировал, но как только пытаюсь записать данные, Mikrotik перезагружается. Похоже, ему не хватает питания, чтобы запустить HDD через USB, так что попробую найти USB-to-SATA адаптер с питанием или возьму SSD — надеюсь, роутер сможет его нормально запитать.

Чувак в CHR 6.43.2 делает то же самое. Mikrotik был официально уведомлен. Я открыл тикет по этой проблеме [Ticket#2017090222000354], и, как видишь, ему несколько дней назад исполнился год. Всё ещё нет положительного ответа, никаких надежд…

Мои последние наблюдения привели меня к выводу, что в случае этой ошибки достаточно просто перезапустить Dude. Чем скорее, тем лучше, чтобы минимизировать разрыв в записываемых данных. В итоге я создал и запланировал регулярный запуск скрипта, который проверяет статус “running”, а в любом другом случае фиксирует ситуацию в лог и перезапускает Dude. Скрипт также ведёт счётчик перезапусков, дату и время последнего перезапуска и последний нежелательный статус Dude. Исключения делать не нужно, даже если в этот момент идёт резервное копирование базы данных. Можете спокойно использовать и модифицировать под свои задачи, а если что-то улучшите — делитесь здесь для всех.

Для удобства просто вставьте это в терминал:

/system scheduler  
add interval=5m name=DudeCheck on-event=DudeCheck policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-time=startup

/system script  
add dont-require-permissions=no name=DudeCheck policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source=":global DudeA [/dude get status];
\n:global DudeW running;  
\n:global DudeLR;  
\n:global DudeR;  
\n:global DudeT;  
\n  
\n:if ($DudeA != $DudeW) do={  
\n:log info \"Dude status: $DudeA.\";  
\n:set DudeT [/system clock get date];
\n:set DudeT ($DudeT . \" \" . [/system clock get time] );
\n:set DudeLR [/dude get status];
\n:set DudeR ($DudeR + 1);  
\n:log info \"Dude не запущен, выполняется автоматический перезапуск.\";  
\n/dude set enabled=no;  
\n:delay 5s;  
\n/dude set enabled=yes  
\n}"

В моём случае было похоже с rb750gr3 / microSD. Теперь, когда я перестал запускать на нём этого парня и перенёс на CHR, простой перезапуск решает проблему на несколько дней без каких-либо заметных побочных эффектов. Пока что… советую тебе последовать моему примеру. Поведение клиента тоже гораздо плавнее с сервером на CHR, чем на rb750gr3. Размер моего файла базы данных — 300 МБ, бэкап в tgz — 115 МБ.

Запущено на версии 6.42.7, и вот с этого началось (14 октября 2018): чувак, критическая ошибка базы данных: образ диска базы данных повреждён. Это база на 750Г r3 Hex с 30Гб SD. Собираюсь перейти на виртуальную машину. Спасибо за советы. Билл