Una guía de expertos para la replicación de Slony para PostgreSQL

¿Qué es Slony?

Slony-I (referido simplemente como 'Slony' de ahora en adelante) es un sistema de replicación de terceros para PostgreSQL que se remonta a antes de la versión 8.0, lo que lo convierte en una de las opciones más antiguas disponibles para la replicación. Funciona como un método de replicación basado en disparadores que es una solución de "maestro a múltiples esclavos".

Slony funciona mediante la instalación de activadores en cada tabla que se va a replicar, tanto en el maestro como en los esclavos, y cada vez que la tabla recibe una INSERCIÓN, ACTUALIZACIÓN o ELIMINACIÓN, registra qué registro se modifica y cuál es el cambio. Los procesos externos, llamados "slon daemons", se conectan a las bases de datos como cualquier otro cliente y obtienen los cambios del maestro, luego los reproducen en todos los nodos esclavos suscritos al maestro. En una configuración de replicación con buen rendimiento, este asincrónico se puede esperar que la replicación tenga entre 1 y 20 segundos de retraso con respecto al maestro.

Al momento de escribir este artículo, la última versión de Slony es la versión 2.2.6 y es compatible con PostgreSQL 8.3 y superior. El soporte continúa hasta el día de hoy con actualizaciones menores; sin embargo, si una versión futura de PostgreSQL cambia la funcionalidad fundamental de las transacciones, funciones, disparadores u otras características principales, el proyecto Slony puede decidir interrumpir las actualizaciones grandes para admitir nuevos enfoques tan drásticos.

La mascota de PostgreSQL es un elefante conocido como "Slonik", que en ruso significa "pequeño elefante". Dado que este proyecto de replicación se trata de muchas bases de datos PostgreSQL que se replican entre sí, se usa la palabra rusa para elefantes (plural):Slony.

Conceptos

• Cluster:una instancia de replicación de Slony.
• Nodo:una base de datos PostgreSQL específica como nodo de replicación Slony, que funciona como maestro o esclavo para un conjunto de replicación.
• Conjunto de replicación:Un grupo de tablas y/o secuencias a replicar.
• Suscriptores:un suscriptor es un nodo que está suscrito a un conjunto de replicación y recibe eventos de replicación para todas las tablas y secuencias dentro de ese conjunto desde el nodo principal.
• Slony Daemons:los principales trabajadores que ejecutan la replicación, se inicia un Slony daemon para cada nodo en el conjunto de replicación y establece varias conexiones con el nodo que administra, así como con el nodo maestro.

Cómo se usa

Slony se instala ya sea por fuente o a través de los repositorios PGDG (Grupo de desarrollo global de PostgreSQL) que están disponibles para las distribuciones de Linux basadas en Red Hat y Debian. Estos archivos binarios deben instalarse en todos los hosts que contendrán un nodo maestro o esclavo en el sistema de replicación.

Después de la instalación, se configura un clúster de replicación Slony emitiendo algunos comandos usando el binario 'slonik'. 'slonik' es un comando con una sintaxis propia simple pero única para inicializar y mantener un clúster slony. Es la interfaz principal para emitir comandos al clúster Slony en ejecución que está a cargo de la replicación.

La interfaz con Slony se puede realizar escribiendo comandos personalizados de slonik o compilando slony con el indicador --with-perltools, que proporciona los scripts 'altperl' que ayudan a generar estos scripts slonik necesarios.

Creación de un clúster de replicación de Slony

Un 'Cluster de replicación' es una colección de bases de datos que forman parte de la replicación. Al crear un clúster de replicación, se debe escribir un script de inicio que defina lo siguiente:

• El nombre del clúster Slony deseado
• La información de conexión para cada nodo que forma parte de la replicación, cada uno con un número de nodo inmutable.
• Enumerar todas las tablas y secuencias que se replicarán como parte de un "conjunto de replicación".

Puede encontrar un script de ejemplo en la documentación oficial de Slony.

Cuando se ejecuta, slonik se conectará a todos los nodos definidos y creará el esquema Slony en cada uno. Cuando se inician los demonios Slony, borrarán todos los datos de las tablas replicadas en el esclavo (si las hay) y copiarán todos los datos del maestro al esclavo(s). A partir de ese momento, los demonios replicarán continuamente los cambios registrados en el maestro a todos los esclavos suscritos.

Configuraciones inteligentes

Si bien Slony es inicialmente un sistema de replicación de Maestro a Múltiple Esclavo, y se ha utilizado principalmente de esa manera, existen otras características y usos inteligentes que hacen que Slony sea más útil que una simple solución de replicación. La naturaleza altamente personalizable de Slony lo mantiene relevante para una variedad de situaciones para administradores que pueden pensar fuera de la caja.

Replicación en cascada

Los nodos Slony se pueden configurar para replicar en cascada a lo largo de una cadena de nodos diferentes. Si se sabe que el nodo maestro soporta una carga extremadamente pesada, cada esclavo adicional aumentará esa carga ligeramente. Con la replicación en cascada, un solo nodo esclavo conectado al maestro se puede configurar como un "nodo de reenvío", que luego será responsable de enviar eventos de replicación a más esclavos, manteniendo la carga en el nodo maestro al mínimo.

Procesamiento de datos en un nodo esclavo

A diferencia de la replicación integrada de PostgreSQL, los nodos esclavos en realidad no son de "solo lectura", solo las tablas que se replican están bloqueadas como "solo lectura". Esto significa que en un nodo esclavo, el procesamiento de datos puede tener lugar mediante la creación de nuevas tablas que no forman parte de la replicación para albergar los datos procesados. Las tablas que forman parte de la replicación también pueden tener índices personalizados creados según los patrones de acceso que pueden diferir del esclavo y el maestro.

Las tablas de solo lectura en los esclavos aún pueden tener funciones personalizadas basadas en disparadores ejecutadas en cambios de datos, lo que permite una mayor personalización con los datos.

Actualizaciones mínimas de tiempo de inactividad

Actualizar las versiones principales de PostgreSQL puede llevar mucho tiempo. Según el tamaño de los datos y el número de tablas, una actualización que incluya la actualización posterior del proceso de "análisis" podría demorar varios días. Dado que Slony puede replicar datos entre clústeres de PostgreSQL de diferentes versiones, se puede usar para configurar la replicación entre una versión anterior como maestro y una versión más nueva como esclavo. Cuando vaya a realizarse la actualización, simplemente realice un "cambio", convirtiendo al esclavo en el nuevo maestro, y el antiguo maestro se convierte en el esclavo. Cuando la actualización se marque como un éxito, retire el clúster de replicación de Slony y cierre la base de datos anterior.

Alta disponibilidad con mantenimiento frecuente del servidor

Al igual que el tiempo de inactividad mínimo para las actualizaciones, el mantenimiento del servidor se puede realizar fácilmente sin tiempo de inactividad al realizar un "cambio" entre dos o más nodos, lo que permite reiniciar un esclavo con actualizaciones u otro mantenimiento. Cuando el esclavo vuelva a estar en línea, se volverá a conectar al clúster de replicación y se pondrá al día con todos los datos replicados. Los usuarios finales que se conectan a la base de datos pueden tener transacciones prolongadas interrumpidas, pero el tiempo de inactividad en sí sería de segundos a medida que ocurre el cambio, en lugar del tiempo que lleva reiniciar/actualizar el host.

Envío de registros

Aunque no es probable que sea una solución popular, un esclavo Slony se puede configurar como un nodo de "envío de registros", donde todos los datos que recibe a través de la replicación se pueden escribir en archivos SQL y enviar. Esto se puede usar por una variedad de razones, como escribir en un disco externo y transportarlo a una base de datos esclava manualmente, y no a través de una red, comprimido y archivado para futuras copias de seguridad, o incluso hacer que un programa externo analice los archivos SQL y modificar los contenidos.

Compartir datos de múltiples bases de datos

Dado que se puede replicar cualquier cantidad de tablas a voluntad, los conjuntos de replicación de Slony se pueden configurar para compartir tablas específicas entre bases de datos. Si bien se puede lograr un acceso similar a través de contenedores de datos externos (que han mejorado en versiones recientes de PostgreSQL), puede ser una mejor solución usar Slony según el uso. Si se necesita obtener una gran cantidad de datos de un host a otro, hacer que Slony replique esos datos significa que los datos necesarios ya existirán en el nodo solicitante, lo que elimina el largo tiempo de transferencia.

Replicación retrasada

Por lo general, se desea que la replicación sea lo más rápida posible, pero puede haber algunos escenarios en los que se desee un retraso. El demonio slon para un nodo esclavo se puede configurar con un lag_interval, lo que significa que no recibirá ningún dato de replicación hasta que los datos tengan la antigüedad especificada. Esto puede ser útil para acceder rápidamente a los datos perdidos si algo sale mal, por ejemplo, si se elimina una fila, existirá en el esclavo durante 1 hora para una recuperación rápida.

Cosas que debe saber:

• Cualquier cambio DDL a las tablas que son parte de la replicación debe ejecutarse usando el comando de ejecución slonik.
• Cualquier tabla que se replique debe tener una clave principal o un índice ÚNICO sin columnas anulables.
• Los datos que se replican desde el nodo maestro se replican después de que los datos se hayan generado funcionalmente. Lo que significa que si los datos se generaron usando algo como 'random()', el número resultante se almacena y replica en los esclavos, en lugar de que 'random()' se ejecute nuevamente en el esclavo y devuelva un resultado diferente.
• Agregar la replicación de Slony aumentará ligeramente la carga del servidor. Si bien está escrita de manera eficiente, cada tabla tendrá un disparador que registra cada INSERCIÓN, ACTUALIZACIÓN y ELIMINACIÓN en una tabla Slony; se espera un aumento de la carga del servidor de entre un 2 y un 10 %, según el tamaño de la base de datos y la carga de trabajo.

Consejos y trucos:

• Los demonios Slony pueden ejecutarse en cualquier host que tenga acceso a todos los demás hosts; sin embargo, la configuración de mayor rendimiento es que los demonios se ejecuten en los nodos que administran. Por ejemplo, el demonio maestro ejecutándose en el nodo maestro, el demonio esclavo ejecutándose en el nodo esclavo.
• Si configura un clúster de replicación con una gran cantidad de datos, la copia inicial puede demorar bastante tiempo, lo que significa que todos los cambios que ocurren desde el inicio hasta que se completa la copia podrían requerir aún más tiempo para ponerse al día y estar sincronizados. . Esto se puede resolver agregando algunas tablas a la vez a la replicación (lo que consume mucho tiempo), o creando una copia del directorio de datos de la base de datos maestra en la esclava, luego haciendo un 'conjunto de suscripción' con la opción OMITIR COPIAR establecida en verdadero. Con esta opción, Slony asumirá que la tabla esclava es 100 % idéntica a la maestra, y no la borrará ni copiará los datos.
• El mejor escenario para esto es crear un Hot Standby usando las herramientas integradas para PostgreSQL, y durante una ventana de mantenimiento sin conexiones modificando datos, ponga el standby en línea como maestro, valide las coincidencias de datos entre los dos, inicie el clúster de replicación slony con OMIT COPY =true, y finalmente vuelva a habilitar las conexiones de cliente. La configuración de Hot Standby puede llevar tiempo, pero el proceso no causará un gran impacto negativo en los clientes.

Comunidad y Documentación

La comunidad de Slony se puede encontrar en las listas de correo, ubicadas en http://lists.slony.info/mailman/listinfo/slony1-general, que también incluye archivos.

La documentación está disponible en el sitio web oficial, http://slony.info/documentation/, y brinda ayuda con el análisis de registros y la especificación de sintaxis para interactuar con slony.