|
1 2 |
ERROR: database is not accepting commands to avoid wraparound data loss in database "mydb" HINT: Stop the postmaster and use a standalone backend to VACUUM in "mydb". |
The short story
Si has llegado hasta aquí buscando el mensaje anterior, ya deberías saber que tienes un problema de los gordos, o sea que no te voy a entretener mucho.
Tu base de datos no ha perdido información, pero no acepta escrituras por lo que, probablemente, tu aplicación tiene una funcionalidad muy limitada. No te preocupes, no has perdido nada.
En resumen, te has encontrado con lo que se conocer como transaction wraparound. Básicamente, estás borrando o modificando tuplas de alguna tabla mucho más rápidamente de lo que el autovacuum de postgres puede limpiar. O quizás tienes el autovacuum desactivado.
Tienes dos alternativas evidentes: Ejecutar ese vacuum, como te indica el mensaje de error, o bien arrancar otra base de datos limpia con una copia de la actual. Personalmente te recomiendo la opción del backup. Mi propuesta es:
- Exportar la base de datos actual via pg_dump.
- Crear una base de datos nueva con los mismos roles y extensiones que la original.
- Restaurar la nueva base de datos usando pg_restore, con el volcado del paso 1.
- Configurar tu aplicación para que use la nueva base de datos.
- Configurar autovacuum correctamente para evitar el mismo problema en el futuro.
Una vez empiezas con el punto 3), quizás puedas seguir el consejo de postgres y ejecutar el vacuum en single mode. En nuestro caso, no funcionó. Usamos un servicio cloud que no nos permite arrancar en single mode pero, además, nuestra tabla problemática era tan grande que no había manera de pasar el vacuum. Simplemente, no acaba.
Enlaces interesantes:
Preventing Transaction ID Wraparound Failures
pg_dump
pg_restore
The long story
Continuará…