En sistemas de alta disponibilidad es necesario minimizar los tiempos de los mantenimientos, incluyendo la actualización.

En el caso de un servidor de bases de datos con PostgreSQL, una actualización del sistema operativo adJ que incluye actualización a la pila de software (con PostgreSQL) puede tomar entre dos horas y varios días dependiendo de la cantidad de información en la base de datos y del método que se use para actualizar (es crítico cuando se requiere actualizar la versión mayor del motor de PostgreSQL, pues de usar pg_dumpall se requiere primero volcado de la versión anterior y después restauración del volcado en la nueva versión).

Con un segundo servidor que pueda actualizarse primero para tomar el rol de servidor principal, podría disminuirse el tiempo, pero no es trivial como se explora en este documento, con mediciones bajo las siguientes circunstancias

  • Servidor fuente: ** Sistema operativo: OpenBSD/adJ 6.6 ** Memoria: 32G ** Procesador: Intel Core i7-7700 ** Versión de PostgreSQL: 12.2 ** Tamaño de la base de datos: 22G medidos desde el sistema operativo con du -sh /var/postgresql/data.
  • Servidor destino: ** Sistema operativo: OpenBSD/adJ 6.7 ** Memoria: 32G ** Procesador: Intel Core i7-4790 ** Versión de PostgreSQL: 12.2

Con pg_dumpall

Al sacar copias de respaldo con PostgreSQL hemos notado que el método más portable entre diversas versiones de PostgreSQL es el volcado que genera INSERTs en SQL (con opciones --inserts y --column-inserts de pg_dump y de pg_dumpall).

Opciones para pg_dumpall Tamaño del volcado Tiempo de volcado Transferencia a 2do servidor Velocidad
Ninguna 12.7G 317s .040 G/s  
--inserts --columns-inserts 14.4G 365s .039 G/s  
--inserts 13.2G 371s .035 G/s  
--column-inserts 14.4G 364s .039 G/s  

Con pg_dump

Según [SOR2020] las opciones -j y -F de pg_dump permitirían mayor velocidad en la restauración de una base de datos con pg_restore. Pero como pg_dumpall no soporta tales opciones inicialmente hacemos una medición del uso de pg_dump. Cómo pg_dump sólo permite sacar volcado de una base de datos hicimos inicialmente la medición sacando copia de una base de 1.2G medida desde psql con select pg_database_size('nombrebase');

Opciones para pg_dump Tamaño del volcado Tiempo de volcado Velocidad
Ninguna 6.9G 187s 0.03 G/s
--column-inserts 7.3G 183s 0.03G/s
--inserts 6.9G 193s 0.03 G/s
-Fc 1.5G 293s 0.005 G/s
-j 8 -Fd -f /tmp/volcado-pg8.dir 1.5G 323s 0.004 G/s
-j 32 -Fd -f /tmp/volcado-pg32.dir 1.5G 323s 0.004 G/s

Conclusión

El método de sacar un volcado, actualizar motor y después restaurar el volcado es lento con pg_dumpall y pg_dump.

Es más rápido emplear pg_upgrade que describimos inicialmente en https://dhobsd.pasosdejesus.org/actualizacion-de-postgresql-con-pg-upgrade.html

Referencias

  • [PGD13] https://www.postgresql.org/docs/13/app-pg-dumpall.html
  • [SOR2020] https://stackoverflow.com/questions/2094963/postgresql-improving-pg-dump-pg-restore-performance