PostgreSQL 9.6 acaba de ser lanzado y la mayoría de los usuarios de Postgres comenzarán a preguntarse cómo actualizar a la nueva versión principal. Esta publicación tiene la intención de mostrar diferentes procedimientos para actualizar su servidor PostgreSQL.
Actualizar a una nueva versión principal es una tarea que tiene una alta proporción de preparación sobre el tiempo total de ejecución. Específicamente cuando se salta una versión en el medio, por ejemplo, cuando salta de la versión 9.3 a la versión 9.5.
Lanzamientos puntuales
Por otro lado, las actualizaciones de lanzamiento puntual no necesitan tanta preparación. Generalmente, el único requisito es que se reinicie el servicio de postgres. No hay cambios en la estructura de datos subyacente, por lo que no es necesario volcar ni restaurar. En el peor de los casos, es posible que deba volver a crear algunos de sus índices una vez que haya terminado de actualizar la versión puntual.
Es muy aconsejable permanecer siempre en la última versión de punto, para que no tropiece con un error conocido (y probablemente solucionado). Esto significa que una vez que salga la última versión, programe el tiempo para la actualización lo antes posible.
Actualización de versión principal
Al realizar tareas complejas como esta, es bueno considerar todas las opciones posibles para lograr el resultado final.
Para actualizaciones de versiones importantes, hay tres caminos posibles que puede tomar:
- Restauración de actualización desde un volcado lógico
- Actualización física
- Actualización en línea
Permítanme explicar cada uno en detalle:
1) Restauración de actualización desde un volcado lógico
Esta es la forma más sencilla de actualizar la estructura de datos de su clúster.
Para abreviar, el proceso aquí requiere un volcado lógico usando pg_dump de la versión anterior y pg_restore en un clúster limpio creado con la versión recién instalada.
Los puntos clave a favor de utilizar este camino son:
- Es el más probado
- La compatibilidad se remonta a las versiones 7.0, por lo que eventualmente podría actualizar de 7.x a una de las versiones recientes
Razones por las que debería evitar usar esta opción:
- El tiempo de inactividad total en bases de datos grandes puede ser un problema, ya que debe detener las conexiones de escritura antes de comenzar a ejecutar pg_dump;
- Si hay muchos objetos grandes en la base de datos, pg_dump será lento. Incluso al hacerlo en paralelo. La restauración será incluso más lenta que pg_dump cuando se almacenen muchos objetos grandes en la base de datos;
- Requiere el doble de espacio en disco o la eliminación del clúster anterior antes de la restauración;
En servidores con varios núcleos de CPU, es posible ejecutar pg_dump en paralelo utilizando el formato de directorio. Una vez que haya terminado, restaure también en paralelo, usando el modificador -j tanto en pg_dump como en pg_restore. Pero no puede iniciar el proceso de restauración hasta que todo el volcado haya terminado.
2) Actualización física
Este tipo de actualizaciones han estado disponibles desde la versión 9.0 para realizar actualizaciones en el lugar desde versiones tan antiguas como la 8.3. Se denominan "in situ" porque se realizan en el mismo servidor y, preferiblemente, en el mismo directorio de datos.
Ventajas de este tipo de actualizaciones:
- No necesita espacio para otra copia del clúster.
- El tiempo de inactividad es mucho menor en comparación con el uso de pg_dump.
Hay bastantes desventajas:
- Una vez que inicie la nueva versión de PostgreSQL, no podrá volver a la versión anterior (a partir de ese momento, el clúster funcionará solo con la nueva versión).
- Las estadísticas se ponen a cero después de la actualización, por lo que inmediatamente después de iniciar la nueva versión de PostgreSQL se debe ejecutar un análisis de todo el clúster.
- Se han encontrado muchos errores en los últimos años con respecto a pg_upgrade, lo que hace que algunos administradores de bases de datos se muestren reacios a usar este método para actualizar.
- Algunas personas han tenido problemas al omitir una versión principal, por ejemplo, al pasar de la versión 9.2 a la versión 9.4.
- Con catálogos grandes, tendrá un rendimiento deficiente (clústeres con muchas bases de datos o bases de datos con muchos miles de objetos).
También puede ejecutar pg_upgrade sin la opción –link (en este caso, pg_upgrade generará una segunda copia en el disco de su clúster) para que pueda volver a la versión anterior. Pero perderá las dos ventajas mencionadas anteriormente.
3) Actualización en línea
El procedimiento a seguir para este método sería así:
- Instala ambas versiones para que puedas hacer que funcionen en paralelo. Esto se puede hacer en el mismo servidor o usando dos servidores físicos.
- Cree una copia inicial y replique los cambios desde el momento en que inició la copia en el nodo de origen (esto sería similar a un pg_dump inicial).
- Siga replicando lógicamente los cambios hasta que el retraso sea cercano a cero.
- Vuelva a señalar la información de conexión del servidor de aplicaciones para conectarse al nuevo servidor.
Este tipo de actualización ha estado disponible desde que aparecieron las primeras soluciones de replicación basadas en activadores. En otras palabras, desde que Slony-I estaba presente.
A las soluciones de replicación basadas en activadores no les importa qué versión tiene de un lado o del otro, ya que copia los cambios mediante comandos SQL compatibles.
Las herramientas de replicación basadas en disparadores recomendadas, en el orden en que aparecen son:
- skytools:PgQ + londiste
- Slony-I
Esta debería ser la forma preferida de actualización. Veamos las ventajas de usar este método:
- ¡Cero tiempo de inactividad!
- Ideal para actualizar a hardware más nuevo también.
- Pruebas en línea del clúster con la nueva versión (consultas de solo lectura, o podría terminar con conflictos).
- Reduce drásticamente todas las tablas e índices hinchados.
Hay algunas desventajas:
- Necesita el doble de espacio de almacenamiento, ya que tiene que almacenar una segunda copia de sus datos.
- Como se basa en disparadores, el sistema tiene que escribir cada cambio dos veces, lo que significa que habrá más E/S de disco en el servidor de origen (versión anterior del clúster).
- Todas las tablas deben tener una clave principal, para que la herramienta de replicación pueda individualizar las tuplas que se actualizan o eliminan
- No replica tablas de catálogo, por lo que no replicará objetos grandes.
- El uso básico no cubre los cambios de esquema. Se puede hacer, pero no de forma transparente.
Una nueva frontera con pglogical
Desde PostgreSQL 9.4 tenemos decodificación lógica de los registros de transacciones. Esto significa que ahora podemos decodificar las transacciones del WAL y manipular la salida.
Todo un nuevo mundo de posibilidades apareció en el campo de la replicación. ¡Los disparadores ya no son necesarios para lograr la replicación lógica!
Básicamente, esto significa que ya no es necesario guardar una copia separada de todas las inserciones, actualizaciones y eliminaciones usando activadores. Simplemente puede obtener esas operaciones de manipulación de datos de los registros de transacciones, decodificándolos. Luego, es la herramienta que está utilizando la que tiene que manipular la salida y enviarla al nodo descendente suscrito. En este caso esa herramienta es pglogical.
Entonces, ¿qué significa todo esto?
Bien, si tiene una versión 9.4 o 9.5 de PostgreSQL y desea actualizar a la 9.6, puede realizar una actualización en línea como la detallada anteriormente, pero usando pglogical en lugar de una de las soluciones de replicación basadas en activadores.
No entraré en más detalles ya que hay otros blogs sobre este tema en particular, como este escrito por Petr Jelinek:Paquetes PGLogical 1.1 para PostgreSQL 9.6beta1
Conclusiones
Según el esquema de su base de datos, el tamaño de los datos, la posible ventana de tiempo de inactividad, la versión de la instalación actual de PostgreSQL, puede elegir una opción sobre otra o lo que mejor se adapte.
- Si su base de datos es pequeña y hay una ventana de mantenimiento adecuada que puede usar, puede optar por ejecutar pg_dump y pg_restore. Dependiendo del tamaño del conjunto de datos, hay un punto en el que la opción ya no es factible.
- Si tiene una base de datos grande (varios cientos de GB o incluso TB de datos), tendrá que buscar otras opciones, como una actualización en el lugar con pg_upgrade o una actualización en línea.
- Si actualiza desde la versión 8.3 o superior a cualquier versión 9.x, puede usar pg_upgrade.
- Para versiones anteriores a la 8.3, deberá optar por una de las soluciones de replicación lógica como londiste o slony.
- Si está en una base de datos 9.4 o 9.5, es mejor que use pglogical.
Recuerde siempre que para la replicación lógica las tablas deben tener una clave principal.
Con pglogical esa regla no es tan estricta:puede replicar tablas de solo inserción. Pero para actualizaciones y eliminaciones, sigue siendo obligatorio tener una clave principal o una IDENTIDAD DE RÉPLICA sobre la mesa.
Si necesita ayuda para actualizar su base de datos PostgreSQL, puede consultar los
servicios de actualización de 2ndQuadrant.
