Replicacion Slony - Informe - Bitácora

Año 2017

Replicación de Bases de Datos Slony-I

ABAD, Martín – GERÓN, Enzo – MORALES, Juan 218904

-

218217

-

217689

REPLICACIÓN DE BASES DE DATOS

Tabla de contenidos ........................................................................................................................................... ................................................................................................................................ ....................................................................................................................................................... ¿Qué es Slony? ................................................................................................................................... 4 ¿Por qué utilizar Slony? ................................................................................................................. 4 .................................................................................................................................................... Configuración de máquinas virtuales ...................................................................................... 6 Instalación de PostgreSQL y PGAdmin .................................................................................... 6 Instalación de Stack Builders y Slony-I ................................................................................... 7 Configuración de las máquinas ................................................................................................ 10 Comando Slonik ............................................................................................................................. 10 Comando Slon ................................................................................................................................. 10 Replicación en marcha................................................................................................................. 13 .................................................................................................... Ventajas ........................................................................................................ ..................................... 14 Desventajas ............................................................................................................ .......................... 14 ........................................................................................................................................ ...........................................................................................................................................

1


En el presente informe se describe conceptos y herramientas necesarias para ejecutar una correcta replicación en una base de datos. Para ello, se proporciona la definición de una terminología básica referente al tema, en primer lugar, y luego se describe los complementos a utilizar. Se utiliza como motor de bases de datos PostgreSQL y PGAdmin III como IDE. Se determinó, por cuestiones de practicidad, realizar la replicación utilizando una computadora con SO Windows 10 como servidor esclavo, y dos máquinas virtuales con distribuciones de Windows y Linux correspondientes a los nodos stand-by. La herramienta a utilizar para la resolución del problema planteado es Slony-I, la cual posee distintas versiones y es de código abierto. Los objetivos planteados son los siguientes: Implementar una replicación utilizando como motor de bases de datos PostgreSQL. Investigar sobre el software Slony-I y su utilidad para la replicación. Poner en funcionamiento de manera correcta un cluster en el que un servidor lea y escriba, mientras que los dos restantes sólo lean. Es decir, un nodo maestro y dos esclavos. La metodología a implementar será la siguiente: Se definirán los conceptos claves, de manera breve, para un mejor entendimiento. Se describirán las herramientas a utilizar, acompañadas por capturas de pantalla. Se añadirá una bitácora en la que se pueda observar el trabajo realizado y la secuencia de pasos a seguir. Se evaluarán los resultados obtenidos, detallando los problemas que  surgieron y las posibles soluciones encontradas y aplicadas. 

 







2


Es el conjunto de instancias de bases de datos PostgreSQL que están implicadas en la replicación. Es cada una de las bases de datos que intervienen en la replicación. Se tiene, en este caso particular, un nodo origen (maestro) y dos nodos suscriptores (esclavos o Stand-By). Es el proceso mediante el cual se desea mantener y copiar los datos de una base de datos a otras, para poder transportarlos y almacenarlos, reduciendo cargas al servidor maestro. Es el conjunto de tablas y/o secuencias a ser replicadas. En un mismo cluster puede haber varios sets. Es el nodo principal, denominado maestro. Es el único en el que se puede modificar valores de las tablas. Son todos los demás nodos en el clúster (esclavos), son los que reciben los datos en la réplica. Sólo permiten la lectura de datos. También denominados disparadores, son objetos asociados a las tablas que se almacenan en la base de datos. Se ejecutan cuando ocurre algún evento sobre las tablas a las que está relacionado. Su funcionamiento acciona una función previamente definida.

3


Slony-I es un sistema de replicación "maestro a múltiples esclavos" para PostgreSQL que admite la conmutación por error y la conexión en cascada, es decir, que un nodo alimente a otros nodos. Es un sistema de replicación maestro-esclavo que incluye todas las características y capacidades necesarias para replicar grandes bases de datos a un número razonablemente limitado de sistemas esclavos. Slony-I es un sistema diseñado para su uso en centros de datos y sitios de respaldo, donde el modo normal de operación es que todos los nodos están disponibles.

PostgreSQL 9.0 incluye la replicación de transmisión que, para una serie de casos de uso, es probable que sea más simple y más conveniente que Slony-I. Sin embargo, hay tres tipos de casos característicos en los que necesitará algo como Slony-I, donde la replicación basada en WAL no funcionará: 





Necesita interactuar entre las versiones de PostgreSQL. Slony puede hacer frente a tener nodos ejecutando diferentes versiones de PostgreSQL. La replicación basada en WAL requiere que todas las bases de datos usen versiones idénticas de PostgreSQL, ejecutándose en arquitecturas idénticas. Solo pretende replicar partes de los cambios que están ocurriendo. La replicación basada en WAL duplica absolutamente todo. Es necesario que haya comportamientos adicionales en los suscriptores, por ejemplo, rellenando la información de gestión del caché. La replicación basada en WAL duplica absolutamente todo, y nada adicional que cambie los datos se puede ejecutar en una réplica basada en WAL.

Como se observó al principio, la replicación de transmisión incorporada en PostgreSQL, que ha progresado desde sus inicios en la versión 8.1, puede satisfacer los requisitos de replicación de algunos usuarios. Para aquellos con requisitos que no son compatibles con sus restricciones, los sistemas de replicación como Slony-I seguirán siendo útiles.

4


PostgreSQL 9.4 introdujo la Replicación lógica, que utiliza la decodificación lógica de los datos WAL como alternativa a la captura de datos basada en triggers. A largo plazo, es probable que esta estrategia sea más eficiente que Slony y eventualmente obsoleto para muchos casos de uso que no involucran actualizaciones entre las versiones de PostgreSQL. Sin embargo, Logical Replication / Logical Decoding solo admitirá versiones recientes de PostgreSQL (y la compatibilidad con la versión inter-PostgreSQL puede ser más ambiciosa que real), por lo que si tiene una base de datos ejecutada en 9.3 o anterior, es probable que se produzca una interrupción breve. Las actualizaciones requerirán algo así como Slony que se ejecuta contra un conjunto diverso de versiones de PostgreSQL.

5


Como la estrategia elegida es operar con dos máquinas virtuales, el primer paso está ligado directamente a las mismas. Se deberá: 





Instalar VM VirtualBox de Oracle o alguna herramienta que proporcione los mismos servicios. Configurar cada una de las máquinas virtuales, asignando memoria RAM y tamaño de disco. Instalar el correspondiente Sistema Operativo. En nuestro caso, el servidor maestro tiene Windows 10, un nodo esclavo Windows 7 y el restante posee una distribución de Linux (Debian).

A continuación, se debe instalar Postgres en cada maquina y alguna versión de PgAdmin(por cuestiones de rapidez, recomendamos la versión PgAdmin III). Es una instalación típica y muy simple. En el proceso de instalación, se debe instalar una herramienta recomendada por Postgres: Stack Builders.

6


El motivo de la instalación de esa aplicación es el siguiente: Este tipo de replicación soporta distintas versiones de Postgres, pero en distribuciones idénticas de Slony. Para asegurarnos que la versión sea la misma, instalamos Stack Builders, que es un proveedor de complementos, y dentro de esa aplicación seleccionamos la misma versión de Slony. Se probó instalar slony mediante la terminal en la computadora de distribución Linux, pero las versiones detectadas mediante el comando search eran anteriores. Luego, con todo lo explicado anteriormente, se selecciona una misma versión de Slony en cada computador y se procede a instalarla, teniendo en cuenta si el sistema operativo es de 32 o 64 bits.

Se verifica el directorio donde se guardará la descarga.

7


Se aguarda a que se realice la descarga.

Se procede a instalar lo descargado.

8


Se espera a que concluya la instalación.

9


En este paso se debe ser muy cauteloso, ya que en nuestra experiencia tuvimos muchos inconvenientes, principalmente de comunicación entre las máquinas. Cada paso es absolutamente necesario, y su omisión provocará que las máquinas no puedan conectarse, o bien, que alguno de los nodos no pueda inicializarse y por lo tanto replicar. Se procede a configurar los archivos pg_hba.conf en cada ordenador. El archivo está alojado en la carpeta PostgreSQL/9.*/data. La configuración a realizar es la siguiente:

En la carpeta PostgreSQL/9.*/bin del directorio del servidor maestro crear un archivo de extensión .txt que corresponde a la descripción del nodo maestro y al cluster. Se detallan los campos que intervienen:

10


A continuación, en la carpeta PostgreSQL/9.*/bin del servidor de cada uno de los esclavos, se requiere crear un archivo de texto en el que se realizan las siguientes configuraciones, modificando el valor de cada nodo el número de IP y las claves, según corresponda: Esclavo Windows:

Esclavo Linux:

11


El siguiente paso es compilar Slony-I de la siguiente manera: En la máquina del servidor maestro, en nuestro caso de Windows 10, se debe abrir una consola terminal e ir al directorio donde se encuentra la carpeta bin de PostgreSQL. Luego, ejecutar la siguiente instrucción:

Mismo procedimiento para los servidores esclavos, aunque cambiando el nombre del archivo .txt por su correspondiente.

Una vez compilado los archivos con la aplicación slonik, las computadoras aguardan por una instrucción de conexión definitiva. Esta comunicación se lleva a cabo mediante el comando slon, y debe realizarse en cada una de las máquinas, iniciando por el nodo maestro y luego, en orden, por cada uno de los esclavos. Nuevamente, en una terminal de sistema, se debe ejecutar la siguiente instrucción, habiendo accedido previamente a la carpeta bin de PostgreSQL: Slon.exe slony_ultimo “dbname=librería user=postgres password=postgres”.

Al finalizar este paso, veremos que en cada terminal se imprimen constantes mensajes indicando estadísticas de funcionamiento. Las consolas no deben ser cerradas mientras se busca una replicación, ya que al cerrarlas, el comando slon no está en marcha y los servidores no están conectados.

12


Al concluir con esta serie de pasos, iniciando PgAdmin en cada ordenador, se observa que dentro de la base de datos elegida, ya se encuentra instanciado el clúster previamente definido. Además, se tiene una subcarpeta llamada Slony Replication, correspondiente a la replicación detallada. Otro punto a destacar es que dentro de la raíz esquemas, en cada una de las tablas replicadas, se añade un ícono que indica replicación.

13


Por último, sólo queda probar que efectivamente el servidor maestro replica su información y los esclavos la reciben. También es bueno destacar que, a pesar de intentarlo, en los servidores esclavos no se puede modificar ningún campo. Eso se debe a que existe una relación esclavo maestro, y no una relación bidireccional (Slony-I no lo permite). Cualquier modificación que se produzca en el servidor maestro mientras algún esclavo se encuentre “dormido” (a excepción de los mencionados cambios de

estructuras) se replicará cuando ejecute el comando slon y dé inicio la replicación correspondiente. Con esto, nos aseguramos que el proceso de replicación concluyó con éxito y que, además, podemos confiar en que la información será integra y coherente.

14


Tras lo estudiado, se notaron ciertas falencias y virtudes de la herramienta Slony, las cuales se deben remarcar. Entre las grandes ventajas de Slony, se encuentra lo siguiente: 







 

Es multi-hardware, es decir, tiene un amplio soporte en cuanto a componentes de hardware de las pc involucradas. Es multi-Sistema Operativo, lo cual es muy beneficioso porque amplía el alcance de la herramienta y no limita al usuario. Soporte amplio de versiones de Postgres. No importa la versión de PostgreSQL instalada en cada ordenador, lo que es beneficioso por no requerir un traslado de información. Soporta replicación en cascada, es decir que un servidor maestro puede transferir su información a diversos nodos esclavos. Optimiza el uso del ancho de banda. Optimiza la carga del nodo maestro. Al trabajar con servidores Stand-By, las tareas de lectura pueden ser ejecutadas por ellos, lo que reduce de manera significativa el trabajo del servidor maestro.

Entre sus desventajas, se destaca que:  



  

Requiere una misma versión de Slony No detecta fallas de nodos del clúster, con lo cual, al fallar alguno de ellos no podríamos operar de manera correcta y mucho menos aplicar políticas de resguardo instantáneas. En algunos casos, requiere software adicional. Por ejemplo, en el caso de una falla del servidor maestro, no se puede indicar directamente que un servidor esclavo asuma el rol de maestro. Para ello, es necesario instalar herramientas adicionales que lo resuelvan. No permite cambios de esquemas. No permite cambios de tablas. Su configuración, a pesar de no ser compleja, es demasiado quisquillosa. Cualquier error u omisión provoca que no puedan comunicarse las máquinas y la detección de estos no es tan simple.

15


En primer lugar, nos pareció sumamente correcto destacar que pudimos llevar a cabo las tareas realizadas gracias al material de soporte facilitado por la cátedra. También fue clave la ayuda del profesor para detectar algunas fallas y decidirnos por la virtualización. Del trabajo en grupo, podemos concluir que fue eficiente y muy bien organizado. La distribución de tareas y los roles asumidos por los integrantes fueron correctos y nos sirvieron para trabajar en tiempo y forma. Todos los problemas que surgieron fueron resueltos de manera cooperativa y sin distinciones. Pudimos cumplir con los objetivos previamente asumidos en conjunto, sin habernos visto presionados en cuanto a los tiempos. De la herramienta Slony-I queremos destacar que notamos una potencia considerable y al mismo tiempo muy limitada. Sus restricciones limitan el uso y la aplicación en diversos contextos prácticos. A pesar de esto, su simpleza es fantástica y permite configurar la replicación sin muchas especificaciones técnicas, resolviendo de manera correcta la cuestión y basándose en el uso de disparadores (concepto calve aprendido previamente en el cursado de la materia). Probablemente, con el tiempo, la herramienta sea mucho más abarcadora e incluso pueda fusionarse desde algún punto de vista con herramientas propias de PostgreSQL.

16


1. http://www.slony.info/ 2. Apuntes proporcionados por la cátedra: a. Triggers. b. Bases de datos distribuidas c. Replicación Streaming y WAL Shipping. 3. http://www.grch.com.ar/docs/bdd/apuntes/unidad.iv/Replicacion%20Slo nik.pdf 4. https://wiki.postgresql.org/images/b/b3/Slony_I.pdf 5. https://pornohardware.com/2014/06/24/replicacion-de-bases-de-datospostgresql-con-slony-en-centos/ 6. https://senaintro.blackboard.com/bbcswebdav/institution/semillas/2172 19_1_VIRTUAL/OAAPs/OAAP4/aa7/lab_replicacionbd/manuales/lab7postgre.pdf 7. https://prezi.com/zz4233_hbbns/replicacion-postgresql-con-slony/ 8. https://www.enterprisedb.com/resources/tutorials/how-setup-slony-ireplication-postgres-plus 9. https://www.youtube.com/watch?v=n2V_7Ydhiho 10. https://www.youtube.com/watch?v=Ir3rW0aCqHI 11. https://www.youtube.com/watch?v=2TOjA_Dw1kw

17

Replicacion Slony - Informe - Bitácora

Recommend Documents