Восстановление убитого кэша Беркли (BerkeleyDB)

[zed]

Можно ли прервать восстановление без ущерба для данных?

Можно.

[cycler]

Йессс!!! В режиме Recover environment [cmd: db_recover -v] всё оч.быстро восстановилось.
У меня есть подозрение, почему кеш упал. Я ему предварительно, видимо, помог. Я поставил на папку /cache_db запрет на удаление файлов/папок.

скрытый текст: показать

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

Когда запустил восстановление в режиме Recover environment, он мне в первую очередь ругнулся, что не может удалить DB_CONFIG. Зачем удалять конфиги..? Ладно, запрет на удаление снял, отрекавилось буквально за 30сек и в новой версии САС всё заработало (в старой не пробовал)! Ура, товарищи!!!

[zed]

Я ему предварительно, видимо, помог. Я поставил на папку /cache_db запрет на удаление файлов/папок.

Зачем? Если вы хотели подключить кэш в режиме только для чтения, то для этого есть специальный конфиг. Подробности в тикете: 0001874: Berkeley cache: READ-ONLY

он мне в первую очередь ругнулся, что не может удалить DB_CONFIG. Зачем удалять конфиги..?

Возможно вы его сами попросили, поставив галочку в настройках. И оно хотело перезаписать конфиг, в соответствии с выбранными настройками.

[DJ VK]

Итак, вопрос. Почистили мы карту. переместили, удалили что-то. База естественно похудела лишь виртуально.
Нет ли возможности аналогично reset LSN и verification сделать такую же консольную оптимизацию данных, с чисткой места мертвых тайлов?
или даже засунуть этот процесс в первый пункт.

[zed]

Есть два варианта:
1. Использовать связку из 2-х утилит: db_dump + db_load. Эта операция является аналогом команды VACUUM для SQLite, с тем отличием что тут данные вначале будут распакованы во временный файл (db_dump), а затем из этого временного файла будет создан файл БД (db_load). В SQLite же это выполняется за одну операцию.

2. Написать свою утилиту и использовать там метод: DB->compact. Это метод "щадящей" оптимизации (без пересоздания файла БД), поддерживает множество опций, но консольной утилиты для этой операции они почему-то не сделали. Возможно из-за того, что при обычных операциях записи в БД, там такая оптимизация проводится по-умолчанию, но не для всей БД, а только для тех страниц, которые используются для поиска/записи текущего ключа (key). Т.е. структура БД самооптимизирующаяся.

[Parasite]

Есть два варианта:
1. Использовать связку из 2-х утилит: db_dump + db_load. Эта операция является аналогом команды VACUUM для SQLite, с тем отличием что тут данные вначале будут распакованы во временный файл (db_dump), а затем из этого временного файла будет создан файл БД (db_load). В SQLite же это выполняется за одну операцию.

2. Написать свою утилиту и использовать там метод: DB->compact. Это метод "щадящей" оптимизации (без пересоздания файла БД), поддерживает множество опций, но консольной утилиты для этой операции они почему-то не сделали. Возможно из-за того, что при обычных операциях записи в БД, там такая оптимизация проводится по-умолчанию, но не для всей БД, а только для тех страниц, которые используются для поиска/записи текущего ключа (key). Т.е. структура БД самооптимизирующаяся.

3. Переименовать нужный файл базы в .bad, и заюзать zedову утиль в режиме восстановления .bad (и оно сделает автоматом п.1)

[zed]

Новая версия: sdb_util_1.0.2.8.7z

Изменения касаются DB_CONFIG:
- убрана строчка, определяющая зарезервированное число мьютексов (mutex_set_max 30000), поскольку новые версии SAS умеют более точно определять это число
- по-умолчанию включён пресет High Durability. В этом же режиме работает и SAS, при отсутствии DB_CONFIG.

[Gma]

После установки дополнительных карт (слоёв) _Coverage сломался кэш Я-карт, хранимый в беркли. все попытки восстановления с помощью sdb_util не удались

[zed]

В sdb.log ошибки у двух карт:

1. s:\sas\cache_db\imagery\

Код: Выделить всё

BerkeleyDB: file z15\9\4\38.19.sdb has LSN 4/2426893, past end of log at 1/1066665 [root path: s:\sas\cache_db\imagery\]

2. s:\sas\cache_db\yamapng\

Код: Выделить всё

BerkeleyDB Env: unable to join the environment [root path: s:\sas\cache_db\yamapng\]

Для первого кэша нужно запустить проверку sdb файлов (опция Restore cache after crash: Recover & Verify (default) в sdb_util), у второго кэша нужно попробовать удалить файл env\__db.register и запустить восстановление (опция Recover environment [cmd: db_recover -v]).

Подозреваю, что проблемы с кэшем появились из-за старого файла с настройками DB_CONFIG. После того, как восстановите кэш, удалите эти файлы и пускай SAS создаст актуальные настройки (при этом нужно взять последний релиз, а не какую-то лохматую версию).

[Gma]

Имеджери работает, а Ях так и не хочет. весия САСа была 14009 (не такая уж и старая) сейчас крайняя ночнушка. результат одинаков. Версия утилиты даже моложе выложенной тут.