La semana pasada estuve en el Nordic PGDay 2018 y tuve bastantes conversaciones sobre la herramienta que escribí, a saber, pglupgrade. , para automatizar las actualizaciones de versiones principales de PostgreSQL en una configuración de clúster de replicación. Me alegró mucho que se haya escuchado y que algunas otras personas en diferentes comunidades hayan dado charlas en reuniones y otras conferencias sobre actualizaciones de tiempo de inactividad casi nulo mediante la replicación lógica. Dado que hay una charla que di en PGDAY'17 Rusia, PGConf.EU 2017 en Varsovia y, por último, en FOSDEM PGDay 2018 en Bruselas, pensé que era mejor crear una publicación de blog para mantener esta presentación disponible para las personas que pudieran no asistir a ninguna de las conferencias antes mencionadas. Si desea ir directamente a la charla y omitir la lectura de esta publicación de blog, aquí está su enlace:Actualizaciones automatizadas con tiempo de inactividad casi nulo de los clústeres de PostgreSQL en la nube
La principal motivación detrás del desarrollo de esta herramienta fue proponer una solución para minimizar el tiempo de inactividad durante las actualizaciones de versiones principales que, lamentablemente, afectan a casi todos los que usan PostgreSQL. Actualmente, no contamos con una herramienta que permita a los usuarios de PostgreSQL actualizar sus bases de datos sin tiempo de inactividad y claramente es un problema para muchos usuarios, especialmente para las empresas. Y, si vamos a resolver el problema de la actualización, deberíamos pensar en más de un servidor (a partir de ahora nos referiremos a un clúster), simplemente porque ya no mucha gente usa un solo servidor de base de datos. El escenario más común es tener una configuración de replicación de transmisión física ya sea para fines de alta disponibilidad o para escalar las consultas de lectura.
Actualizaciones de la base de datos
Antes de sumergirnos en la solución, analicemos un poco cómo funcionan las actualizaciones de la base de datos en general. Hay cuatro enfoques principales posibles para las actualizaciones de bases de datos:
- El primer enfoque sería que las bases de datos mantuvieran su formato de almacenamiento igual o al menos compatible entre versiones. Sin embargo, esto es difícil de garantizar a largo plazo, ya que las nuevas funciones pueden requerir cambios en la forma en que se almacenan los datos o agregar más información de metadatos para que funcionen correctamente. Además, a menudo se mejora el rendimiento mediante la optimización de las estructuras de datos.
- El segundo enfoque es hacer una copia lógica (volcado) del servidor anterior y cargarlo en el nuevo servidor. Este es el enfoque más tradicional que requiere que el servidor anterior no reciba ninguna actualización durante el proceso y da como resultado tiempos de inactividad prolongados de horas o incluso días en grandes bases de datos.
- La tercera opción es convertir los datos del formato antiguo al nuevo. Esto se puede hacer sobre la marcha mientras se ejecuta el nuevo sistema, pero incurre en una penalización de rendimiento que es difícil de predecir, ya que depende de los patrones de acceso a los datos, o se puede hacer fuera de línea mientras los servidores están inactivos, lo que nuevamente incurre en prolongación tiempos de inactividad (aunque a menudo más corto que el segundo método).
- El cuarto método es usar un volcado lógico para guardar y restaurar la base de datos mientras se capturan los cambios que ocurren mientras tanto y replicarlos lógicamente en la nueva base de datos una vez finalizada la restauración inicial. Este método requiere la orquestación de varios componentes, pero también reduce la cantidad de tiempo que la base de datos no puede responder a las consultas.
Métodos de actualización en PostgreSQL
Las actualizaciones de PostgreSQL se pueden combinar con los cuatro métodos enumerados anteriormente. Por ejemplo, las versiones menores de PostgreSQL, que no contienen nuevas funciones sino solo correcciones, no cambian el formato de datos existente y se ajustan al primer enfoque. Para el segundo enfoque, PostgreSQL proporciona herramientas llamadas pg_dump y pg_restore que realizan la copia de seguridad y restauración lógica. También existe la herramienta pg_upgrade (era un módulo de contribución y se movió al árbol principal en PostgreSQL 9.5) que realiza la conversión fuera de línea (los servidores no se están ejecutando) del directorio de datos anterior al nuevo, que puede encajar en la tercera opción. Para el cuarto enfoque, existen soluciones basadas en disparadores de terceros, como Slony, para actualizar, pero tienen algunas advertencias que trataremos más adelante.
Los métodos tradicionales de actualización solo pueden actualice el servidor principal mientras que los servidores de réplica deben reconstruirse después (conversión fuera de línea) . Esto genera problemas adicionales tanto con la disponibilidad como con la capacidad del clúster, lo que aumenta de manera efectiva el tiempo de inactividad percibido. de la base de datos desde el punto de vista tanto de las aplicaciones como de los usuarios. La replicación lógica permite replicar mientras el sistema está en funcionamiento y el esfuerzo de prueba se puede manejar mientras tanto (conversión en línea) .
Hay diferentes métodos de actualización aplicables para diferentes entornos. Por ejemplo, pg_dump permite actualizar desde versiones muy antiguas (es decir, 7.0) a versiones recientes, por lo que si está ejecutando una versión antigua de PostgreSQL, el mejor método es usar pg_dump/restore (¡y mejor hacerlo ahora!). Si su versión de PostgreSQL es 8.4 y posteriores puedes usar pg_upgrade . Si está utilizando PostgreSQL 9.4 y versiones posteriores esto significa que tiene "Descodificación lógica" en el núcleo y puedes usar el pglogical extensión como medio de actualización. Finalmente, si está utilizando PostgreSQL 10 , tendrá la oportunidad de actualizar su base de datos a PostgreSQL 11 y posterior (una vez que estén disponibles) mediante el uso de "Replicación lógica" en el núcleo (¡sí!).
Replicación lógica para actualizaciones
¿Dónde está la idea de actualizar PostgreSQL mediante el uso de replicación lógica ¿de dónde viene?Claramente, pglogical no reclama el propósito de la actualización abiertamente como pg_upgrade hace (este fue un argumento en contra de pglogical en la fiesta de la conferencia ), pero esto no significa que no podamos usar la herramienta para actualizaciones. De hecho, cuando se diseñó pglogical, los desarrolladores de la extensión consideraron las actualizaciones con tiempo de inactividad casi nulo como uno de los casos de uso esperados.
A diferencia de la replicación física, que captura los cambios en los datos sin procesar del disco, la replicación lógica captura los cambios lógicos en los registros individuales de la base de datos y los replica. Los registros lógicos funcionan en las principales versiones , por lo tanto, la replicación lógica puede usarse para actualizar de un lanzamiento a otro. La idea de usar la replicación lógica como medio de actualización de la versión está lejos de ser nueva, las herramientas de replicación basadas en disparadores han estado haciendo actualizaciones de una manera lógica al capturar y enviar los cambios a través de disparadores (¡porque los disparadores también pueden funcionar independientemente de las versiones de la base de datos! ).
Si puede utilizar soluciones de replicación basadas en disparadores para actualizaciones de tiempo de inactividad mínimo, ¿por qué debería preferir la replicación lógica en su lugar? En un mecanismo basado en disparadores, todos los cambios se capturan mediante disparadores y se escriben en tablas de cola. Este procedimiento duplica las operaciones de escritura, duplica los archivos de registro y ralentiza el sistema ya que todos los cambios deben escribirse dos veces; lo que resulta en más E/S de disco y carga en el servidor de origen. Por el contrario, la replicación lógica en el núcleo (lo mismo ocurre con la extensión pglogical) se basa en la decodificación lógica. La decodificación lógica es un mecanismo que extrae información de archivos WAL en cambios lógicos (INSERTAR/ACTUALIZAR/ELIMINAR). Dado que los datos del mecanismo WAL se utilizan para decodificar los registros de transacciones, no hay amplificación de escritura. como en el caso de las soluciones de replicación basadas en activadores, por lo que este método funciona mejor . Como resultado, las soluciones basadas en decodificación lógica simplemente tienen un menor impacto en el sistema que las soluciones basadas en disparadores.
Conclusión
En esta publicación introductoria, quería dar una idea de por qué deberíamos considerar el uso de la replicación lógica para lograr un tiempo de inactividad mínimo durante las actualizaciones de versiones principales. Continuaremos con los detalles de la arquitectura e implementación de la herramienta en el próximo post.
