docs: leer la sqlite de n8n con cp se salta el WAL

Un barrido hecho con cp dijo que un cambio recien escrito no estaba, media
hora despues de escribirlo. La copia no tiene los ultimos commits y no da
ningun error.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-07-31 16:15:30 +00:00
co-authored by Claude Opus 5
parent d9e8de9e17
commit 97ff13cc83
+18
View File
@@ -47,6 +47,24 @@ durante media hora. Regla: `kubectl -n n8n rollout restart deploy/n8n` y
comprobar que el `startTime` del pod es POSTERIOR a la escritura, antes de dar comprobar que el `startTime` del pod es POSTERIOR a la escritura, antes de dar
por buena ninguna prueba. por buena ninguna prueba.
## Leer `/data/n8n/database.sqlite` con `cp` enseña el pasado
La BD va en **WAL**. Un `cp` del fichero principal deja fuera el `-wal`, así que
la copia no tiene los últimos commits y **no da ningún error**: enseña
tranquilamente valores viejos. El 2026-07-31 un barrido hecho así dijo que un
cambio recién escrito no estaba, media hora después de escribirlo.
Para leer siempre en frío y completo:
```python
src = sqlite3.connect("file:/data/n8n/database.sqlite?mode=ro", uri=True)
dst = sqlite3.connect(":memory:"); src.backup(dst) # o a un fichero
```
Vale igual para el `sqlite3` del host: apuntarlo al fichero directamente sí lee
el WAL, pero **cualquier copia previa con `cp`, no**. Es la misma razón por la
que las copias de seguridad usan `.backup` y no `cp`.
## Antes de tocar una BD de un pod: desarmar ArgoCD ## Antes de tocar una BD de un pod: desarmar ArgoCD
Casi todo está bajo Applications con `automated{selfHeal,prune}`. Un Casi todo está bajo Applications con `automated{selfHeal,prune}`. Un