mirror of
https://origin.cursor.com/mrdevmx/panels.git
synced 2026-10-09 11:23:18 +00:00
d36c287a82
Fase 5 (migracion de datos): - api/scripts/migrate-sqlite-to-postgres.ts: ETL unico SQLite -> Postgres. Pre-flight (CURP/RFC duplicados case-insensitive, FKs huerfanas, tenant_id invalido, fechas mal formateadas) -> carga por base/esquema con credenciales _owner (setval de secuencias, OVERRIDING SYSTEM VALUE, ON CONFLICT DO NOTHING idempotente) -> verificacion de conteos y sumas de dinero con tolerancia. Probado end-to-end contra un dataset SQLite legacy sintetico y un Postgres limpio (solo schema+catalogos, sin contexto dev): 100% de las filas migradas, sumas de dinero exactas, snapshot de uploaded_by/created_by resuelto correctamente. - db/RUNBOOK-corte.md: checklist go/no-go para el corte por ambiente. - Fix de bug real encontrado al probar: sin --context-filter explicito, Liquibase corre TAMBIEN los changesets context=dev (comportamiento por defecto, no "modo seguro") -- documentado en db/README.md con el ejemplo correcto (--context-filter='!dev' para staging/produccion). Fase 5b: patron de compensacion para createTenant ya resuelto en el rewrite de saas.ts (fase 3/4). Fase 6 (backups): db/backups/ con plantillas pgBackRest por base, politica de retencion, nota de persistencia minima de Redis (RDB, sin retencion de negocio), checklist de simulacro de restauracion mensual, y la validacion pendiente de si Coolify permite WAL archiving antes de comprometerse a PITR real. Fase 7 (limpieza y CI): - Dockerfile.api simplificado (sin JRE/Liquibase/FFI). Dockerfile.migrate y Dockerfile.provision nuevos, de un solo uso, para el paso explicito de deploy (nunca sirven trafico). - docker-compose.yml: postgres+redis+provision+migrate para dev local end-to-end; api ya no arranca hasta que migrate termina bien. - docs/coolify.md y .env.example actualizados al modelo de 2 bases + Redis + Contabo. - api/schema.sql eliminado (desincronizado, competia con Liquibase como fuente de verdad). - .github/workflows/ci.yml: Postgres+Redis de servicio, aprovisiona roles/ACLs, dry-run de Liquibase (updateSQL) antes de aplicar, verify-isolation.sh, deno check + deno test, build de los dos frontends. Co-authored-by: alberto.martinez <alberto.martinez@mrdev.mx>
1.5 KiB
1.5 KiB
Persistencia de Redis (mínima, no es backup de negocio)
Redis guarda sesiones (iam:session:*) y cache (core:cache:*, ver
Fase 4e). Ninguno de los dos es fuente de verdad:
- Sesión perdida → el usuario hace login de nuevo. Molesto, no es pérdida de datos.
- Cache perdido → la siguiente lectura recalcula desde Postgres.
Por eso Redis no entra en la política de backup con retención/PITR de las bases Postgres (Fase 6 del plan). Lo único que vale la pena es evitar que un reinicio del contenedor Redis deslogueé a todos los tenants a la vez -- eso se resuelve con RDB, no con un pipeline de backup.
Configuración recomendada (solo producción)
# redis.conf del recurso de Coolify (o el equivalente que exponga)
save 900 1 # snapshot si hubo >=1 cambio en 15 min
save 300 10 # snapshot si hubo >=10 cambios en 5 min
save 60 10000 # snapshot si hubo >=10000 cambios en 1 min
appendonly no # AOF no hace falta -- RDB alcanza para el objetivo (evitar
# deslogueo masivo), y agrega complejidad/IO sin beneficio
# dado que nada aquí es irremplazable.
En dev/staging, ni siquiera hace falta esto -- perder las sesiones de desarrollo no tiene costo real.
Qué NO hacer
- No configurar
pgbackrest/backups con retención larga para Redis -- sería tratar como "fuente de verdad" algo que por diseño no lo es. - No mezclar la política de respaldo de Redis con la de Postgres en la misma automatización -- son necesidades distintas (ver Fase 6 del plan).