He notado que elWAL (Registro de escritura anticipada)Los archivos (*.sqlite-wal) asociados con las bases de datos SQLite (*.sqlite) utilizadas por el navegador web Firefox suelen ser bastante grandes. Literalmente pueden alcanzar más de 150 veces el tamaño de las bases de datos SQLite asociadas y mantener ese tamaño durante meses (¿años? ¿para siempre?).
De acuerdo aesta respuesta de StackOverflow, una posible solución puede ser ejecutar el siguiente comando SQLite pragma en cada base de datos de almacenamiento afectada:
PRAGMA schema.wal_checkpoint(TRUNCATE);
En teoría, se podría usar una herramienta SQLite externa a Firefox para realizar esta acción, pero he aprendido que realizar accionesdentroFirefox generalmente produce los mejores resultados. (Por ejemplo, intente trabajar omni.jarfuera de Firefox... puede ser un PITA porque Mozilla usa una estructura JAR atípica).
Dentro de Firefox, ¿hay alguna manera de vaciar todas sus bases de datos de almacenamiento SQLite para que su contenido se escriba completamente dentro de los .sqlitearchivos correspondientes?
ACTUALIZAR:
Me gustaría mencionar que uno de los objetivos principales al publicar esta pregunta es manejar de manera segura el storage-sync-v2.sqlite-walarchivo que crece hasta alcanzar los 32 MB en cada perfil de Firefox. La base de datos correspondiente, storage-sync-v2.sqlitetambién tiene un storage-sync-v2.shmarchivo, pero tiende a ser bastante pequeña. Para mantener las cosas enfocadasun tema por pregunta, escribí unpregunta relacionada para abordar específicamente ese objetivo.
Respuesta1
Salga de la instancia de Firefox que utiliza el perfil que contiene las bases de datos en cuestión.
Inicie Firefox desde un perfil temporal. Abra la consola del navegador y pegue el siguiente fragmento. Edite la cadena de ruta para que apunte al perfil de destino. PrensaEnter
Repita para cada base de datos sqlite.
Con suerte, esto funcionará a las mil maravillas, pero no estaría de más hacer una copia de seguridad de tu perfil antes de intentar cualquier cosa.
(()=>{
let file = new FileUtils.File("/pathToTargetProfile/places.sqlite"); // edit this string
let db = Services.storage.openDatabase(file);
let stmt = db.createStatement("PRAGMA wal_checkpoint(TRUNCATE)");
stmt.executeStep();
console.log(stmt.row); //this might provide useful info
stmt.finalize();
db.close();
})();
Respuesta2
En realidad, esta es una muy buena pregunta, que no mucha gente hace.
El .sqlite-walarchivo crece hasta el límite de 32 MB, ya que este es probablemente el límite del diario de transacciones que usted (o el creador de su paquete) definió durante la compilación de sqlite de Firefox.
La directiva con la que puede ajustar el límite del diario de transacciones durante el tiempo de compilación se llamaSQLITE_DEFAULT_JOURNAL_SIZE_LIMITy se define enbytes. En tu caso son 32MB.
También puede ajustar el límite del diario de transacciones más adelante en sqlite con:
PRAGMA schema.journal_size_limit = N ;(de nuevonortees enbytes, el número negativo no establece límite)
Lo que tienes que entender es que esto eslímite suave, no es difícil. Si tiene un proceso activo que está escribiendo en el diario; continuará escribiendo incluso cuando se alcance el límite especificado. Puede alcanzar fácilmente los 2 GB incluso cuando tiene definido un límite de 20 MB.
Este límite es parainactivodiario de transacciones. Creo que los desarrolladores de Firefox decidieron que 32 MB es el equilibrio adecuado entre tener un registro de escritura anticipada y velocidad.
Si desea ajustar el tamaño de PRAGMA después de la compilación, debe hacerlo para cada perfil que tenga. Si planea utilizar muchos perfiles/bases de datos, probablemente desee volver a compilarlos con el SQLITE_DEFAULT_JOURNAL_SIZE_LIMITconjunto.
Para citar secciones válidas del hombre:
En modo WAL, el archivo de registro de escritura anticipada no se trunca después de un punto de control. En cambio, SQLite reutiliza el archivo existente para entradas WAL posteriores, ya que sobrescribir es más rápido que agregar.
El pragma journal_size_limit se puede utilizar para limitar el tamaño de los archivos WAL y del diario de reversión que quedan en el sistema de archivos después de transacciones o puntos de control. Cada vez que se confirma una transacción o se restablece un archivo WAL, SQLite compara el tamaño del archivo de diario de reversión o el archivo WAL que queda en el sistema de archivos con el límite de tamaño establecido por este pragma y si el diario o el archivo WAL es más grande, se trunca. al limite.
La segunda forma del pragma enumerado anteriormente se utiliza para establecer un nuevo límite en bytes para la base de datos especificada. Un número negativo implica que no hay límite. Para truncar siempre los diarios de reversión y los archivos WAL a su tamaño mínimo, establezca el límite de tamaño de diario en cero. Tanto la primera como la segunda forma del pragma enumerado anteriormente devuelven una única fila de resultado que contiene una única columna entera: el valor del límite de tamaño del diario en bytes. El límite de tamaño de diario predeterminado es -1 (sin límite). La macro de preprocesador SQLITE_DEFAULT_JOURNAL_SIZE_LIMIT se puede utilizar para cambiar el límite de tamaño del diario predeterminado en tiempo de compilación.
Este pragma solo funciona en la base de datos única especificada antes del nombre del pragma (o en la base de datos "principal" si no se especifica ninguna base de datos). No hay forma de cambiar el límite de tamaño del diario en todas las bases de datos adjuntas usando una única declaración PRAGMA. El límite de tamaño debe establecerse por separado para cada base de datos adjunta.
Una actualización:
Olvidé mencionar un parámetro importante de SQLite. wal_autocheckpoint=N;(donde N esnúmerode 32 KBpaginasen un diario de 512 KiB). (Que OP ya mencionó al truncar los datos)
Puede configurarlo para utilizar puntos de control automático más pequeños. Tenga en cuenta que esto afecta el rendimiento de SQLite y, por tanto, del navegador. Demasiados puntos de control ralentizarán el navegador.
Para correctamenteconfigurar punto de control automáticoSigue el link.
Lo que también es importante tener en cuenta es que los puntos de control iniciados de esta manera sonPASIVO. Lo que significa que SQLite debería hacer todo lo posible sin bloquearse.
Para citar al hombre del modo PASIVO:
SQLITE_CHECKPOINT_PASSIVE Controle tantos fotogramas como sea posible sin esperar a que finalicen los lectores o escritores de la base de datos, luego sincronice el archivo de la base de datos si se controlaron todos los fotogramas en el registro. La devolución de llamada del controlador de ocupado nunca se invoca en el modo SQLITE_CHECKPOINT_PASSIVE. Por otro lado, el modo pasivo podría dejar el punto de control sin terminar si hay lectores o escritores simultáneos.
Igual que en la nota de actualización anterior, también puede configurar esta opción durante el tiempo de compilación conSQLITE_DEFAULT_WAL_AUTOCHECKPOINT=<pages>.
Del hombre:
Esta macro establece el recuento de páginas predeterminado para la función de control automático de WAL. Si no se especifica, el recuento de páginas predeterminado es 1000.