Я использую db_archive Berkeley DB для перемещения неиспользуемых журналов транзакций в резервное хранилище с целью аварийного восстановления. Намерение состоит в том, чтобы уменьшить окно потери данных до N минут. Следовательно, я выполняю db_archive каждые N минут. Если пропускная способность транзакции достаточно высока, так что максимальный размер журнала транзакций приводит к созданию нового журнала транзакций и возникновению контрольных точек базы данных, которые приводят к неиспользованию старого журнала, эта стратегия работает должным образом. Однако, если пропускная способность минимальна, архивирование будет происходить только после того, как будет достигнут максимальный размер журнала транзакций и контрольная точка освободит старый журнал. Следовательно, эти изменения не могут быть восстановлены, поскольку журналы не архивируются.
Есть ли способ заставить ротацию журнала транзакций, чтобы гарантировать, что даже изменения, которые не приводят к созданию нового журнала транзакций, будут архивироваться через регулярные промежутки времени? Уменьшая максимальный размер журнала транзакций, ситуацию можно улучшить, но не разрешить. Все, что я могу придумать, - это принудительно выполнить ротацию, записав пользовательскую запись в журнале транзакций соответствующего размера с использованием Berkeley DB API DB_ENV-> log_put () перед запуском контрольной точки и вызовом db_archive, но это все еще не похоже на готовое к производству решение .
Заранее благодарим за любую дополнительную информацию по этому вопросу!
Это можно сделать, но, согласно существующим сайтам вызовов в источнике 4.7.25 / 6.2.23, сценарий определенно требует кода для этого (ни одна из утилит не вызывает помощника). Внутренняя функция __log_newfile можно использовать для переключения на новый файл журнала:
int __log_newfile __P((DB_LOG *, DB_LSN *, u_int32_t, u_int32_t));
После контрольной точки старый файл журнала перестанет использоваться и подлежит архивации.