Recuperación en un Punto en el Tiempo (PITR) en PostgreSQL

La recuperación en un punto en el tiempo (PITR) es una característica robusta en PostgreSQL que se ha vuelto aún más eficiente y fácil de usar con la llegada de PostgreSQL. Permite a los administradores restaurar una base de datos de PostgreSQL a un momento específico en el pasado. Esto es particularmente útil si gestionas la recuperación ante desastres de un sistema a gran escala con una gran carga de transacciones.

Este blog explorará PITR y te equipará con conocimientos sobre posibles trampas y sus soluciones, asegurando una implementación suave y exitosa. También compartiremos sus beneficios clave y detallaremos una implementación paso a paso de PostgreSQL.

Componentes Clave

Implementar PITR implica dos componentes clave:

1. Copia de Seguridad Base

Una copia de seguridad base es una instantánea de la base de datos en un momento específico. Incluye todos los archivos de datos, archivos de configuración y metadatos necesarios para restaurar la base de datos a su estado original. La copia de seguridad base sirve como el punto de partida para PITR.

2. Registros de Escritura Adelantada (WAL)

Los archivos WAL registran cada cambio realizado en la base de datos. Estos registros almacenan los cambios necesarios para recuperar la base de datos a su estado en un momento específico. Cuando realizas un PITR, reproduces los archivos WAL secuencialmente para recrear el estado deseado de la base de datos.

¿Por qué usar PITR?

PITR es beneficioso en varios escenarios:

Deshacer Cambios Accidentales

Operaciones accidentales, como una declaración de DELETE o DROP sin una cláusula WHERE, pueden resultar en una pérdida significativa de datos. Con PITR, puedes recuperar la base de datos a un estado justo antes del error, preservando datos críticos.

Recuperar de la Corrupción de Datos

Los errores de la aplicación, fallos de hardware o corrupción de disco pueden causar inconsistencias en los datos. PITR te permite restaurar una instantánea limpia de la base de datos y reproducir solo cambios válidos, minimizando el tiempo de inactividad y la pérdida de datos.

Restaurar para Pruebas o Depuración

Los desarrolladores a menudo necesitan replicar una base de datos de producción para fines de depuración o pruebas. PITR permite la creación de una instantánea de la base de datos en un momento específico, facilitando experimentos controlados sin afectar los datos en vivo.

Recuperación de Desastres

PITR es esencial para las estrategias de recuperación de desastres. En fallos catastróficos, como desastres naturales o ciberataques, puedes restaurar rápidamente la base de datos a su último estado consistente, asegurando la continuidad del negocio.

Uso Eficiente de Recursos

Al combinar copias de seguridad base periódicas con archivos WAL, el PITR minimiza la necesidad de copias de seguridad completas frecuentes, ahorrando espacio de almacenamiento y reduciendo los tiempos de copia de seguridad. El PITR también es un método de recuperación exacto, lo que permite recuperar hasta un segundo específico y minimiza el riesgo de pérdida de datos durante un incidente. Es lo suficientemente flexible como para manejar diversos escenarios de recuperación, desde un retroceso de una sola transacción hasta una restauración completa de la base de datos de manera eficiente.

¿Qué hay de nuevo en PostgreSQL 17 para PITR?

PostgreSQL 17 introduce varias mejoras para el PITR, centrándose en el rendimiento, la usabilidad y la compatibilidad:

Sincronización de Slots de Failover

Los slots de replicación lógica ahora soportan sincronización durante los failovers. Esto asegura que los WAL necesarios para el PITR se mantengan incluso después de un failover, reduciendo la intervención manual.

Compresión de WAL Mejorada

El algoritmo de compresión de WAL ha sido actualizado para mejorar la eficiencia de almacenamiento, reduciendo el espacio requerido para archivar los WAL. Esto es particularmente beneficioso para sistemas a gran escala con altas tasas de transacción.

Velocidades de Recuperación Más Rápidas

Las optimizaciones en el proceso de reproducción de WAL resultan en tiempos de recuperación más rápidos, particularmente para conjuntos de datos grandes.

Mejor compatibilidad con la replicación lógica

PITR ahora se integra mejor con configuraciones de replicación lógica, facilitando la recuperación de clústeres que aprovechan la replicación física y lógica.

Control granular de la archivación de WAL

PostgreSQL 17 ofrece más control sobre la archivación de WAL, permitiéndote ajustar las políticas de retención para coincidir con los requisitos de recuperación.

Pasos detallados para realizar PITR en PostgreSQL

Sigue estos pasos para configurar y realizar PITR. Antes de usar PITR, necesitarás:

• Archivado de WAL: Habilita y configura el archivado de WAL.
• Copia de seguridad base: Realiza una copia de seguridad completa de la base utilizando pg_basebackup o pgBackRest.
• Almacenamiento seguro: Asegúrate de que las copias de seguridad y los archivos WAL se almacenen de forma segura, preferiblemente fuera del sitio.

1. Configurar el archivado de WAL

El archivado de WAL es crítico para PITR, ya que almacena los cambios incrementales entre copias de seguridad. Para configurar el archivado de WAL, actualiza el archivo postgresql.conf, estableciendo:

wal_level = replica          # Ensures sufficient logging for recovery

​

archive_mode = on            # Enables WAL archiving

​

archive_command = 'cp %p /path/to/wal_archive/%f'  # Command to archive WALs

​

max_wal_senders = 3          # Allows replication and archiving

Luego, después de establecer los parámetros de configuración, reinicia el servidor de PostgreSQL:

sudo systemctl restart postgresql

Verifica el estado del archivado de WAL con el siguiente comando:

SELECT * FROM pg_stat_archiver;

Busque cualquier error en la vista pg_stat_archiver o en los registros de PostgreSQL.

2. Realizar una copia de seguridad base

Tome una copia de seguridad base para usar como punto de partida para PITR; utilizando pg_basebackup, el comando tiene la forma:

pg_basebackup -D /path/to/backup_directory -Fp -Xs -P

Esto crea un snapshot consistente de la base de datos y asegura que los archivos WAL sean archivados para la recuperación.

3. Validar la integridad de la copia de seguridad

Utilice pg_verifybackup para validar la integridad de su copia de seguridad:

pg_verifybackup /path/to/backup_directory

4. Simular una falla

Con fines de demostración, puede simular una falla. Por ejemplo, eliminar datos accidentalmente:

DELETE FROM critical_table WHERE id = 123;

5. Restaurar la copia de seguridad base

Antes de restaurar la copia de seguridad base, detenga el servidor de PostgreSQL:

sudo systemctl stop postgresql

Luego, use el siguiente comando para cambiar el nombre del directorio de datos existente:

mv /var/lib/pgsql/17/data /var/lib/pgsql/17/data_old

Después, reemplace el directorio de datos con la copia de seguridad base:

cp -r /path/to/backup_directory /var/lib/pgsql/17/data

Actualice los permisos en el directorio de datos:

chown -R postgres:postgres /var/lib/pgsql/17/data

6. Configurar la recuperación

Para habilitar el modo de recuperación, primero necesita crear un archivo recovery.signal en el directorio de datos de PostgreSQL:

touch /var/lib/pgsql/17/data/recovery.signal

Luego, actualice postgresql.conf, añadiendo los siguientes parámetros:

restore_command = 'cp /path/to/wal_archive/%f "%p"'  # Restore archived WALs

​

recovery_target_time = '2024-11-19 12:00:00'    # Specify target time

​

Alternatively, use recovery_target_lsn or recovery_target_name for more advanced scenarios.

7. Iniciar PostgreSQL en modo de recuperación

Reinicie el servidor de PostgreSQL con el comando:

sudo systemctl start postgresql

Monitoree los registros para el progreso de la recuperación:

tail -f /var/lib/pgsql/17/pg_log/postgresql.log

PostgreSQL saldrá automáticamente del modo de recuperación y se volverá operativo cuando la recuperación esté completa.

8. Verificar la Recuperación

Después de la recuperación, valida el estado de la base de datos:

SELECT * FROM critical_table WHERE id = 123;

Abordando Problemas Potenciales

Archivos WAL Faltantes o Corrompidos

Problema

Los archivos WAL requeridos para la recuperación están faltantes o corruptos.

Solución

• Asegúrate de que las copias de seguridad y los archivos WAL se validen regularmente utilizando herramientas como pg_verifybackup.
• Utiliza almacenamiento redundante para los archivos WAL.

Objetivo de Recuperación Incorrecto

Problema

La recuperación se detiene en un estado no deseado.

Solución

• Verifica el recovery_target_time, recovery_target_lsn o recovery_target_name.
• Utiliza pg_waldump para inspeccionar los archivos WAL en busca de eventos objetivo.

Cuellos de Botella de Rendimiento Durante la Recuperación

Problema

La recuperación tarda demasiado debido a archivos WAL grandes.

Solución

• Optimiza el rendimiento de la recuperación aumentando maintenance_work_mem y max_parallel_workers.
• Utiliza compresión WAL para reducir el tamaño del archivo.

Problemas de Desviación de Reloj

Problema

Las marcas de tiempo de recuperación necesitan estar alineadas debido a diferencias de reloj.

Solución

Sincroniza los relojes del servidor utilizando herramientas como NTP.

Archivado WAL Mal Configurado

Problema

Un archive_command incorrecto causa fallos en la archivación de WAL.

Solución

• Prueba el archive_command manualmente: cp /path/to/test_wal /path/to/wal_archive/.
• Asegúrate de tener permisos suficientes para el directorio de archivo.

Mejores Prácticas para PITR

1. Automatizar copias de seguridad: Utiliza herramientas como pgBackRest o Barman para copias de seguridad programadas y archivación de WAL.
2. Monitorear la archivación de WAL: Revisa regularmente pg_stat_archiver en busca de problemas.
3. Validar copias de seguridad: Siempre verifica la integridad de la copia de seguridad usando pg_verifybackup.
4. Probar procedimientos de recuperación: Simula regularmente escenarios de recuperación para asegurar la preparación.
5. Asegurar archivos WAL: Para archivos WAL, utiliza almacenamiento seguro y redundante, como servicios en la nube o discos configurados en RAID.

Conclusión

La recuperación a un punto en el tiempo (PITR) es crítica para mantener la fiabilidad de la base de datos y mitigar la pérdida de datos en caso de un incidente. Las mejoras de pgEdge y PostgreSQL 17 hacen que PITR sea más rápido, eficiente y fácil de gestionar, especialmente para sistemas a gran escala o altamente disponibles.

Seguir los pasos y mejores prácticas de esta guía te ayudará a implementar y gestionar PITR de manera efectiva en tus entornos de PostgreSQL. Las pruebas y el monitoreo regulares son esenciales para garantizar que los procesos de recuperación estén disponibles cuando más los necesites.