Cómo proteger la base de datos SQLite de la corrupción

Question

Estoy tratando de averiguar cuál es la estrategia más segura para proteger mi base de datos SQLite (basada en archivos) de la corrupción (en este caso, estoy trabajando con Adobe Air, pero esto podría se aplica a cualquier navegador webkit que use SQLite, incluido Mobile Safari).

Estoy pensando en crear una conexión de base de datos, manteniéndola por solo 5 o 10 segundos y luego cerrándola si no se ha utilizado durante ese período. Mi opinión es que si la máquina falla o la aplicación sale de manera anormal, es probable que el archivo ya esté cerrado y, por lo tanto, tenga menos posibilidades de dañarse. Pero sé que cuanto más a menudo abres y cierras una base de datos basada en archivos, es más probable que tengas un error crítico.

Estoy seguro de que estoy pensando demasiado en esto, pero para mi aplicación es crítico que en caso de un bloqueo del sistema, la aplicación pueda recuperarse limpia y rápidamente y eso significa que tengo que tratar de proteger la base de datos como tanto como puedo

¿Alguien sabe qué estrategia es más segura?

Answer 1

Al final de este documento

File Locking And Concurrency In SQLite Version 3

Hay una sección denominada "6.0 Como corromper su base de datos de archivos" que discuten los problemas de corrupción en la hipotética curroptions SQLite. "Things that can can go wrong".

Answer 2

Primero NO use journal_mode=MEMORY o =OFF.

Podemos utilizar estos comandos para reducir la probabilidad de una corrupción:

1. PRAGMA synchronous=FULL o PRAGMA synchronous=EXTRA
2. PRAGMA fullfsync=ON (sólo funciona en Mac OS X)

pero vienen con un costo de hacer que las transacciones sean más lentas E incluso con ellos, la base de datos se puede dañar debido a otras fallas en el dispositivo de almacenamiento o en la memoria, por lo que debemos estar preparados para el problema.

Podemos hacer regularmente backups, pero tiene 2 inconvenientes:

1. Se copia todo el archivo db en cada copia de seguridad
2. Perdemos todas las transacciones que se hicieron después de la última copia de seguridad

Tengo un cliente que se usó para hacer su copia de seguridad en un pen-drive y el pen-drive siempre se mantuvo enchufado a la computadora hasta que se produjo un rayo y destruyó la computadora, incluida la pen-drive. Todos los datos se perdieron. Por lo tanto, la copia de seguridad debe mantenerse separada de la computadora principal.

Una mejor alternativa es usar la replicación. Con él, cada transacción ejecutada en el db principal se replica en las réplicas.

Para SQLite podemos usar litereplica. Es compatible con la recuperación puntual y sugiero que se use con la replicación, ya que si algunos datos se eliminan accidentalmente de la base de datos principal, se replicarán. Con PITR podemos restaurar el DB a un punto anterior en el tiempo.

Otra sugerencia importante es mantener la réplica en un dispositivo separado, y separados unos de otros. Al menos no en el mismo edificio.

Ejecutar el comando PRAGMA integrity_check de vez en cuando es una buena práctica debido al hecho de que SQLite no lo hace automáticamente y continúa escribiendo a la base de datos en algunos tipos de daños.

Y si su db utiliza claves externas, puede hacer lo mismo con PRAGMA foreign_key_check.