La replicación de transmisión nativa en PostgreSQL solo funciona entre servidores con la misma versión principal. Hablamos sobre la replicación lógica en una publicación anterior . Vimos cómo la replicación lógica ayuda a mover datos de una versión de PostgreSQL a otra. Pero la replicación lógica solo es adecuada para versiones compatibles de PostgreSQL, por ejemplo, PostgreSQL 9.4 y PostgreSQL 11. ¿Qué hacer con las versiones anteriores a 9.4? Usa Slony-I .
Use la replicación con Slony-I para transferir datos de bases de datos antiguas a la última versión de PostgreSQL. ¿Qué es Slony y cómo funciona?
Esta es la cuarta publicación de nuestra serie Actualización o migración de versiones anteriores de PostgreSQL a otras nuevas , donde aprendemos diferentes métodos para actualizar las bases de datos PostgreSQL.
Slony
Slony es una implementación de replicación lógica a nivel de aplicación para PostgreSQL. O más bien, es una herramienta de replicación de terceros que requiere instalación y configuración por separado. Slony ha existido por mucho tiempo. La última versión admite PostgreSQL de 8.4 a 11.
El objetivo principal de la replicación es transferir los cambios de un servidor de base de datos a otro. Para comprender mejor la arquitectura, veamos los términos: Slon, eventos y slonik.
Por cierto, Slony, si no lo has adivinado, estos son "elefantes". Y realmente tienen un gran recuerdo. No es casualidad que un elefante estricto pero lindo haga alarde del logotipo de PostgreSQL.
Slon
Slon es un demonio que se ejecuta en todos los nodos de PostgreSQL en la replicación de Slony-I. Estos demonios se usan para manejar eventos de configuración y replicación para cada servidor PostgreSQL. Cada servidor PostgreSQL se llama host. Todos los nodos juntos forman un clúster Slony.
El nodo del editor es la fuente de los cambios, y el nodo del suscriptor recibe y aplica los cambios del editor.
Para configurar la replicación, debe especificar todas las tablas replicadas o un conjunto de replicación. La suscripción funciona para un conjunto específico. Los cambios en las tablas replicadas se combinan en SYNC, un grupo de transacciones que se aplican juntas en los suscriptores.
Eventos
Los cambios se informan del editor como eventos. Cuando el demonio Slon procesa un evento en el host remoto, se genera un reconocimiento. Y los eventos notifican a los nodos los cambios de configuración, como agregar o eliminar nuevos nodos, nuevas suscripciones o cambios DDL.
Cada evento tiene su propio identificador único para el origen, número de serie, identificador de transacción para la instantánea en el nodo del evento, varios argumentos y una marca de tiempo con una zona horaria.
Los disparadores escritos en PL / pgSQL registran todos los cambios en las tablas replicadas. Desafortunadamente, no hay una forma confiable de manejar los cambios en blobs, DDL o cambios en usuarios y roles.
slonik
Esta es una utilidad de línea de comandos con un analizador e intérprete que acepta scripts slonik, un lenguaje declarativo simple. Está diseñado para superar las limitaciones de un lenguaje de procedimiento. Con la ayuda de los comandos de slonik, puede configurar o modificar la replicación en Slony, y pueden integrarse en scripts de shell. Acepta comandos de entrada estándar o de archivos. El siguiente ejemplo muestra cómo se pasa el script slonik a slonik y se incrusta en los scripts de shell.
El script que crea la configuración inicial para un esquema simple maestro-esclavo en nuestra base de datos pgbench se ve así:
#!/bin/sh slonik <<_EOF_ cluster name = percona_pg; node 1 admin conninfo = 'dbname=pg93 host=pg93_host user=percona_pg93_user'; node 2 admin conninfo = 'dbname=pg11 host=pg11_host user=percona_pg11_user'; #-- # Creates a _$(clustername), this example, _percona_pg schema #-- init cluster ( id=1, comment = 'Legacy PG Node'); #-- # Add a list of tables being replicated to a set. #-- create set (id=1, origin=1, comment='pgbench'); set add table (set id=1, origin=1, id=1, fully qualified name = 'public.pgbench_accounts', comment='accounts'); set add table (set id=1, origin=1, id=2, fully qualified name = 'public.pgbench_branches', comment='branches'); set add table (set id=1, origin=1, id=3, fully qualified name = 'public.pgbench_tellers', comment='tellers'); set add table (set id=1, origin=1, id=4, fully qualified name = 'public.pgbench_history', comment='history'); #-- # Create the second node (the slave) tell the 2 nodes how to connect to # each other and how they should listen for events. #-- store node (id=2, comment = 'Target node', event node=1); store path (server = 1, client = 2, conninfo='dbname=pg93 host=pg93_host user=percona_pg93_user'); store path (server = 2, client = 1, conninfo='dbname=pg11 host=pg11_host user=percona_pg11_user'); _EOF_
¿Por qué es conveniente Slony para las migraciones?
A pesar de las ventajas de la replicación lógica interna, para versiones anteriores a PostgreSQL 9.4, debe usar esta solución de terceros. El enfoque basado en desencadenantes depende de la API de la base de datos: ambas versiones deben ser compatibles para usar la sintaxis PL / pgSQL y SQL.
¿Cómo adaptar la base de datos para usar con Slony?
- Las tablas deben tener claves primarias. Agregue un campo en serie a todas las tablas sin una clave primaria.
- Los cambios en el blob OID no se replican. Si tiene columnas con valores cortos, conviértalas a BYTEA. Si los objetos son muy grandes, por ejemplo, imágenes, es mejor almacenar datos en almacenamiento externo (por ejemplo, S3 en la nube de Amazon). Si cambiar la aplicación es demasiado complicado, aplique los cambios de blob en el último paso de la migración.
- ALTER TABLE y otras operaciones DDL. Slony no detecta cambios en la estructura de la tabla. Use el comando slonik EXECUTE SCRIPT para aplicar un archivo SQL con cadenas SQL o DDL a todo el clúster de replicación.
Migración en línea de versiones anteriores de PostgreSQL
- Cree un usuario de replicación con privilegios de superusuario. Puede configurar los derechos en detalle, pero es mucho más complicado.
- Cree una base de datos en el destino con acceso TCP / IP.
- Copie las definiciones de tabla del maestro a los esclavos.
- Instala Slony-I. En servidores con una versión anterior del sistema operativo, será más fácil instalar Slony-I desde el código fuente.
- Defina el clúster, el conjunto de tablas y la información de conexión de nodos como una lista de comandos slonik.
- Ejecute el demonio slon en cada servidor PostgreSQL. Verifique la salida estándar o los archivos de registro para ver si hay errores de conexión.
- Ejecute los comandos de suscripción de slonik para iniciar la sincronización.
- Pruebe las solicitudes de solo lectura en la nueva versión de Postgres.
- Cuando todos los datos se replican y sincronizan, detenga las aplicaciones y diríjalas al nuevo servidor Postgres.
- Use el nodo de desinstalación en la nueva versión de PostgreSQL para eliminar todos los rastros de replicación de Slony.
Transición a versiones anteriores
Use el mismo procedimiento para actualizar a versiones anteriores. Con Slony, puede replicar desde cualquier versión y a cualquier versión de PosgreSQL que admita la versión de Slony. La versión mínima admitida es 8.4.
Resumen
Vimos en términos generales cómo puede actualizar a la nueva versión con un tiempo de inactividad mínimo utilizando Slony. Obtenga más información en nuestro seminario web .