Как защитить базу данных SQLite от повреждения - PullRequest
Новая
       8

Как защитить базу данных SQLite от повреждения

6 голосов
/ 27 июня 2010

Я пытаюсь выяснить, какая самая безопасная стратегия защиты моей (файловой) базы данных SQLite от повреждения (в данном случае я работаю с Adobe Air, но это может относиться к любому браузеру веб-набора, который используетSQLite, в том числе Mobile Safari).

Я подумываю о создании соединения с базой данных, сохраняя его в течение, возможно, 5 или 10 секунд, а затем закрывая его, если оно не использовалось в течение этого периода.Я думаю, что в случае сбоя машины или ненормального завершения работы приложения велика вероятность того, что файл уже будет закрыт и, следовательно, меньше вероятность его повреждения.Но я знаю, что чем чаще вы открываете и закрываете файловую БД, тем больше вероятность того, что у вас будет критическая ошибка.

Я уверен, что я слишком обдумываю это, но для моего приложенияочень важно, чтобы в случае сбоя системы приложение могло восстанавливаться аккуратно и быстро, а это значит, что я должен пытаться защитить БД как можно больше.

Кто-нибудь знает, какая стратегия может бытьбезопаснее?

Ответы [ 2 ]

6 голосов
/ 27 июня 2010

В конце этого документа

Блокировка файлов и параллелизм в SQLite версии 3

Есть раздел под названием «6.0 Как повредить файлы базы данных»,обсудить проблемы коррупции и гипотетических проблем в SQLite." Вещи, которые могут пойти не так ".

1 голос
/ 03 июля 2017

Во-первых, НЕ используйте journal_mode=MEMORY или =OFF.

. Мы можем использовать эти команды для уменьшения вероятности повреждения:

  1. PRAGMA synchronous=FULL или PRAGMA synchronous=EXTRA
  2. PRAGMA fullfsync=ON (работает только в Mac OS X)

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

Мы можем сделать обычные резервное копирование , но имеет 2 недостатка:

  1. Копирует весь файл БД в каждую резервную копию
  2. Мы теряем все транзакции, которые были сделаны после последней резервной копии

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

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

Для SQLite мы можем использовать litereplica .Он поддерживает восстановление на определенный момент времени, и я предлагаю использовать его с репликацией, потому что, если некоторые данные будут случайно удалены из основной базы данных, они будут реплицированы.С помощью PITR мы можем восстановить БД до предыдущего момента времени.

Еще одно важное предложение - хранить реплику в отдельном устройстве и отдельно друг от друга.По крайней мере, не в том же здании.

Выполнение команды PRAGMA integrity_check время от времени является хорошей практикой, поскольку SQLite не делает это автоматически и продолжает записывать в БД при некоторых видах повреждений.

И если ваш БД использует внешние ключи, вы можете сделать то же самое с PRAGMA foreign_key_check.

...