Replicación continua de una versión heredada de PostgreSQL a una versión más nueva usando Slony

La replicación de transmisión nativa en PostgreSQL solo funciona entre servidores que ejecutan la misma versión principal. Discutimos la replicación lógica en nuestra publicación de blog anterior. En esa publicación, vimos cómo la replicación lógica podría ayudar a configurar la migración entre dos versiones de PostgreSQL. Sin embargo, la replicación lógica solo funciona para las versiones compatibles actualmente de PostgreSQL, por ejemplo, entre PostgreSQL 9.4 y PostgreSQL 11. Entonces, ¿qué versiones heredadas son anteriores a la 9.4? Slony-yo podría ayudar a cumplir con este requisito de replicación.

La replicación entre diferentes versiones de PostgreSQL con Slony-I es útil para migrar desde instalaciones de bases de datos heredadas a la última versión disponible. Entonces, ¿qué es Slony y cómo funciona?

Esta publicación es la cuarta de nuestra serie de Actualización o migración de su PostgreSQL heredado a versiones más nuevas de PostgreSQL, donde exploraremos varios métodos disponibles para actualizar sus bases de datos de PostgreSQL.

slony

Slony es una implementación de replicación lógica a nivel de aplicación para PostgreSQL. Más bien, podemos decir que es una herramienta de replicación externa que requiere una instalación y configuración por separado. Slony ha existido durante bastante tiempo. La última versión es compatible con las versiones de PostgreSQL desde la 8.4 hasta la 11.

El objetivo principal de la replicación es enviar cambios de un servidor de base de datos a otro. Para comprender mejor la arquitectura, debe conocer términos como Slon, Events y Slonik en Slony-I.

La parte: slony significa elefantes en ruso, y los elefantes tienen fama de tener una gran memoria. Un elefante un poco enojado, pero aún hermoso «.Slonik«, se puede ver en la imagen del logotipo de PostgreSQL.

Slón

Slon es un demonio que se ejecuta en todos los nodos de PostgreSQL en la replicación Slony-I. Estos demonios se utilizan para procesar eventos de configuración y replicación para cada servidor PostgreSQL. Cada servidor PostgreSQL se denomina «nodo». Todos los nodos juntos forman un «cluster» de Slony.

El «nodo editor» es una fuente para los cambios replicados. Mientras que los nodos «suscriptores» reciben y aplican cambios desde el nodo publicador.

Para instalar la replicación, debemos especificar todas las tablas replicadas o «establecidas». La suscripción actual funciona en un sector específico. Los cambios en las tablas que se replican se agrupan en SYNC. Estos grupos de transacciones se aplican juntos a los nodos suscritos.

Eventos

Los cambios son transferidos por el editor en forma de «eventos». Cuando el demonio slon procesa un evento en un nodo remoto, genera una «confirmación». Los eventos también se utilizan para notificar a los nodos sobre los cambios de configuración, como agregar/eliminar nuevos nodos, nuevas suscripciones o cambios de DDL.

Cada evento tiene un identificador de fuente único, un número de secuencia, un ID de transacción para la instantánea en el nodo del proveedor para ese evento, varios argumentos y una marca de tiempo con la zona horaria.

Los activadores escritos en PL/pgSQL registran todos los cambios en las tablas replicadas. Desafortunadamente, también existe una forma confiable de manejar cambios en objetos grandes (BLOB), DDL o cambios en usuarios y roles..

slonik

Slonik significa un pequeño elefante. Es una utilidad de línea de comandos con analizador e intérprete y acepta «scripts slonik», un lenguaje de script declarativo simple. Se pretende superar las limitaciones del lenguaje procesal. Utilice los comandos de slonik para configurar o modificar la replicación de slony y se pueden incrustar en scripts de shell. Puede aceptar comandos de entradas estándar o de archivos. El siguiente ejemplo muestra cómo se alimenta un script slonik a la utilidad slonik y luego se incrusta en scripts de shell.

El script para crear la configuración inicial para la configuración simple maestro-esclavo de nuestra base de datos pgbench se ve así:

¿Por qué Slony es útil para las migraciones?

A pesar de los beneficios de la replicación lógica interna, esta solución externa es la mejor para migrar entre diferentes versiones anteriores a PostgreSQL 9.4. El enfoque basado en disparadores depende de la API de la base de datos: las versiones más antiguas y más nuevas deben ser compatibles con la sintaxis PL/pgSQL y SQL.

¿Cómo adaptar su base de datos para usarla con Slony?

  • Sus tablas deben tener claves primarias. Agregue un campo serial a todas las tablas sin una clave principal
  • Los blobs de OID no replicaron sus cambios. Si tiene columnas con valores de longitud pequeños, puede convertirlos a BYTEA. Para un objeto realmente grande como la imagen, es mejor almacenar los datos externamente, por ejemplo, usando S3 en la nube de Amazon. Si es demasiado difícil cambiar su aplicación, puede aplicar cambios de blob en el último paso de migración.
  • ALTER TABLE y otras operaciones DDL. Slony no puede detectar cambios en la estructura de la tabla. En su lugar, debe usar un comando slonik EXECUTE SCRIPT para aplicar un archivo SQL con cadenas DDL o SQL a todo el clúster de replicación.

Migración en línea desde el legado de PostgreSQL

  1. Cree un usuario de replicación con privilegios de superusuario. Es posible usar buenos privilegios, pero son significativamente más difíciles de instalar.
  2. Crear una base de datos de destino, configurar el acceso TCP/IP
  3. Copie las definiciones de la tabla de maestro a esclavo
  4. Instale Slony-I. En servidores con una distribución de SO más antigua, puede que le resulte más fácil instalar Slony-I desde el código fuente.
  5. Clúster definido, conjunto de tablas e información de conexión a nodos como una lista de comandos slonik
  6. Inicie el demonio slon en cada servidor postgresql. Compruebe la salida estándar o los archivos de registro en busca de errores de comunicación.
  7. Ejecute los comandos de suscripción de slonik para iniciar la sincronización
  8. Pruebe sus preguntas de solo lectura con una versión más nueva de postgres
  9. Una vez que todos los datos se hayan replicado y estén sincronizados, detenga sus aplicaciones y regrese al nuevo servidor de Postgres.
  10. Use «nodo de desinstalación» en la última versión de PostgreSQL para eliminar todos los rastros de la replicación de Slony

Pasos de degradación

Para degradar, siga el mismo procedimiento que para actualizar. Slony le permite replicar hacia y desde cualquier versión de PosgreSQL compatible con su versión de slony. La versión mínima admitida es 8.4.

Resumen

Hasta ahora, hemos visto una descripción general de alto nivel de cómo Slony puede ayudarlo a realizar una actualización con un tiempo de inactividad mínimo. Venga a ver más de esto en acción durante nuestro Webinar. Y no se olvide de Percona Live en Austin, del 28 al 30 de mayo de 2019, tendremos dos días de contenido de PostgreSQL en una pista dedicada a postgres.


Imagen derivada de la foto de chen hu sobre Unsplash

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario