Восстановление после сбоя
Если у вас есть бэкапы, вы всегда сможете восстановить все транзакции которые были совершены до сбоя. Для восстановления после сбоя вам требует журнала транзакций хранящийся на отдельном устройстве от файла базы данных. Информации хранящийся в обоих файлах хватит с избытком. Регулярное резервное копирование файла базы данных и журнала транзакций позволяет сократить время восстановления после сбоя.
Первым шагом в восстановлении после сбоя является чистка, переформатирование или смена устройства, которое дало сбой.
Следующие шаги восстановления зависят от того, на каком устройстве произошел сбой, на том что хранит файл базы данных или на том, что хранит журнал транзакций.
Сбой на устройстве с файлом базы данных.
В случае если ваш журнал транзакций остается целым, а файл базы данных был поврежден, процесс восстановления зависит от того, сохраняли ли вы файлы при инкрементном бэкапе или удаляли.
Если вы имеете единственный журнал транзакций.
Если вы не удаляли или не перезапускали журнал транзакций с последнего полного резервного копирования, журнал транзакций будет содержать все данные, с последнего бэкапа. Процесс восстановления состоит из четырех шагов:
— Сделайте резервную копию журнала транзакций. Файла базы данных нет.
— Восстановите самый последний полный бэкап (файл базы данных).
— Используя СУБД с опцией применения журнала транзакций ( -a ), примените журнал транзакций для приведения базы в актуальное состояние:
DBENG7 psdemodb.db -a psdemodb.log
— Запустите базу данных как обычно. СУБД должена запуститься, применить все изменения и записать их в новый журнал транзакций.
Если вы имеете несколько журналов транзакций.
Если вы уже сохраняли и удаляли журнал транзакций после последнего полного бэкапа, вас надо применить каждый журнал транзакций для приведение базы в актуальное состояние.
— Сделайте резервную копию журнала транзакций.
— Восстановите самый последний полный бэкап (файл базы данных).
— Начинайте с самого первого журнала транзакций после полного резервного копирования, применяя все архивные журналы транзакций в СУБД с ключом ( -a ).
Например, если последняя полная резервная копия была сделана в воскресенье, а файл базы данных был поврежден в четверг, то:
DBENG7 psdemodb.db -a mon.log
DBENG7 psdemodb.db -a tue.log
DBENG7 psdemodb.db -a wed.log
DBENG7 psdemodb.db -a sample.log
— SQL Anywhere не позволит вам применять журналы транзакций в неправильном порядке или делать пропуски в последовательности.
— Запустите базу данных как обычно. СУБД должна запуститься, применить все изменения и записать их в новый журнал транзакций.
Сбой в журнале транзакций.
В ситуации когда файл базы данных остается целым, но вы потеряли файл транзакций, процесс восстановления следующий:
— Сделайте резервную копию файла базы данных.
— Перезапустите базу данных с ключом –f
DBENG7 psdemodb.db -f
Без ключа, СУБД будет ругаться на отсутствие журнала транзакций. С ключом же СУБД восстановит базу на самую последнюю точку и затем откатит любые транзакции которые не были завершены до этой точки. Новый журнал транзакций будет создан.
Последствия отказа журнала транзакций.
Отказ журнала транзакций может иметь более серьезные последствия чем отказ файла базы данных. Когда вы теряете журнал транзакций, все изменения с последней точки будут потеряны. Это может быть проблемой, когда у вас случается системный сбой и отказ одновременно (Например когда произойдет сбой питания, который приведет к повреждению диска). Частые точки минимизируют потенциальные потери данных, но создадут дополнительную работу для СУБД.
Для запуска приложений требующих большого объема или критически важных приложений, можно защитить журнал транзакций от повреждений, зеркалированием или используя специально предназначенные для этого устройства, которые делают это автоматически. Если вы используете SQL Anywhere Server для NetWare, вы можете автоматически делать зеркалирование NetWare тома.
Для более подробной информации про зеркалирование, смотрите тут
Возможно переведу про зеркалирование.. Но позже.
3 комментария
RSS / trackback