Está en la página 1de 12

SOLUCIÓN PARA LA ALTA DISPONIBILIDAD Y PROTECCIÓN DE LA INFORMACIÓN EN ENTORNOS PEQUEÑOS: REPLICACIÓN DE DATOS CON HOT STANDBY Y STREAMING REPLICATION

DE POSTGRESQL 9.1
Lisleydi Mier Pierre2, MsC. Yudisney Vazquez Ortíz2
1

Estudiante de la Facultad 4, Universidad de las Ciencias Informáticas, Carretera a San Antonio de los Baños Km. 2 ½, Boyeros, Ciudad de La Habana 2 Ing. en Ciencias Informáticas, Universidad de las Ciencias Informáticas 1 e-mail: yvazquezo@uci.cu 2 e-mail: lmier@estudiantes.uci.cu

RESUMEN En una sociedad donde la información ha alcanzado altas cotizaciones las bases de datos están sometidas a crecimiento, consulta y actualización constantes; lo que implica que puedan colapsar, incluso, los servidores de bases de datos más potentes derivando en fallas de los sistemas informáticos. Por tanto, lograr de la información la disponibilidad y protección, a pesar de su versatilidad, es una tarea de primer orden de las empresas y organismos cubanos. Las técnicas y soluciones existentes para lograr este propósito en el ámbito del código abierto son disímiles pero complejas, sobre todo si se tiene en cuenta que los especialistas del país no están aún preparados para lidiar con estas ya que generalmente requieren de complicados mecanismos de configuración y administración. Problema del que no escapa la solución de replicación con Hot Standby y Streaming Replication, características de PostgreSQL que permiten la implementación de un sistema de replicación asíncrono maestro-esclavo. El presente artículo propone, en aras de contrarrestar la situación existente, la creación de un script en bash que automatice el proceso de montaje de la solución de replicación con Hot Standby y Streaming Replication de PostgreSQL 9.1, como herramienta para garantizar la disponibilidad y protección de la información en entornos pequeños y con ella, potenciar el empleo de tecnologías de código abierto en el país para alcanzar la soberanía tecnológica. PALABRAS CLAVES: alta disponibilidad y protección de la información, Hot Standby y Streaming Replication, bash para montaje de solución de replicación.

SOLUTION FOR TO GUARANTEE THE INFORMATION HIGH AVAILABILITY AND PROTECTION IN SMALL ENVIRONMENTS: DATA REPLICATION WITH HOT STANDBY AND STREAMING REPLICATION OF POSTGRESQL 9.1
ABSTRACT In a society where information had reached high prices, the databases are undergoing to constants growth, consultation and updating; which implies that they can collapse, even the databases servers more powerful, drifting in computer systems failures. Therefore, to achieve information availability and protection, despite its versatility, is a task of first order of the Cubans enterprises and organisms. The techniques and existing solutions for this purpose in the field of open source are dissimilar but complex, especially if one considers that the country's specialists are not yet prepared to deal with these, as they usually require complicated mechanisms of configuration and administration. Problem that isn‟t solving with Hot Standby Replication and Replication Streaming, PostgreSQL features that enabling the implementation of an asynchronous master-slave replication system. This article proposes, in order to counter the situation, creating a bash script to automate the assembly process of the replication solution with Hot Standby and Streaming Replication of PostgreSQL 9.1, as a tool to ensure the information

1

por tanto. en estrecha combinación con el balanceo de carga y la alta disponibilidad. datos desactualizados. los sistemas informáticos no eran ni la mitad de indispensables que son hoy para el funcionamiento eficiente de una empresa. aunque las pérdidas de las empresas y organismos no reflejarán cifras tan exorbitantes. ha sido una de estas soluciones. (García. es tarea de primer orden de las empresas y organismos hoy día. las telefónicas (hasta 600 mil dólares) y los hipermercados (hasta 550 mil dólares). crearse cuellos de botellas y.availability and protection in small environments and with it.La imposibilidad de solicitar soporte y capacitación para el empleo de los gestores a las empresas propietarias de los sistemas. 2011) . Hot Standby and Streaming Replication. KEY WORDS: bash script to mount replication solution. La replicación de los datos a otros sitios. la Universidad de las Ciencias Informáticas o el Banco Central de Cuba. por ende. incluso los servidores de bases de datos más potentes pueden colapsar. 2 . la mayoría del tiempo. consulta y actualización constantes. donde como promedio 1 hora de tiempo perdido equivalía a 355 horas de trabajo productivo. sí puede afectarse la eficiencia y la calidad de los servicios brindados a la población. la productividad de las 450 empresas norteamericanas estudiadas. Inicialmente se duplicaban las bases de datos manualmente. lo que generaba que se consultaran. Razón por lo que se han creado soluciones para que estas primen por encima de los problemas derivados de su versatilidad. generó que la no disponibilidad de los sistemas ocasionaba en 4 horas un impacto negativo de 40 millones en la cuenta de resultados y que se afectaban por demás. Esta solución ha ido evolucionando a medida que han ido proporcionándose más y mejores formas de realizarla. (Akren. compatible con el gestor. (Corporación-Sybven. accesibles también desde allí. En Cuba hasta poco más del 2009. 2006) En Cuba. potent the use of open source technologies in the country to achieve technological sovereignty. posibilitando que estos sean duplicados en otra localización y. lo que acarreaba problemas como: (Vazquez. se hacía uso excesivo de gestores de bases de datos propietarios como soporte a las aplicaciones empleadas en sus empresas y organismos. derivar en fallas de los sistemas informáticos. así como la productividad de empresas recaudadoras de divisas como la Empresa de Telecomunicaciones de Cuba. por demás. la cual debe ser. 1. Sin dudas garantizar de la información su disponibilidad y protección. siendo las más afectadas las firmas de hidrocarburos que manejan grandes volúmenes de información vitales como el estado de los pozos (hasta 700 mil dólares). las bases de datos están sometidas a crecimiento. 2011) En la actualidad existen herramientas que automatizan el proceso y garantizan la consistencia de los datos en todos los sitios a los que son replicados. cuando aún la información no había alcanzado los niveles actuales de importancia y. Un estudio realizado hace más de 15 años. 2011) Estudios más recientes en Argentina señalan que una empresa puede perder miles de dólares por hora de caída de sus sistemas. Con los grandes volúmenes de información que se manipulan en las empresas. Por otro lado. high availability and data protection. las herramientas y técnicas de replicación deben tener en cuenta las características de los sistemas de gestión de bases de datos que se empleen en la empresa u organismo donde se implante la solución de replicación. INTRODUCCIÓN En una sociedad donde la información ha alcanzado altas cotizaciones. dificultándose la resolución de problemas surgidos del trabajo con ellos.

al ser de código abierto y altamente extensible. TECNOLOGÍAS A EMPLEAR EN ENTORNOS REPLICACIÓN DE DATOS EN POSTGRESQL PEQUEÑOS PARA LA 3 . . (Castillo. 2. basadas en tecnologías de código abierto. . aun cuando existen muchas guías para la correcta configuración de las soluciones persisten problemas sobre todo por el poco dominio de los especialistas del sistema operativo y el gestor de bases de datos. destinándose anualmente cientos de miles de dólares a tal propósito.Facilitaría el proceso de configuración de la solución de replicación con tecnologías de bases de datos de código abierto. .Garantizaría la alta disponibilidad de la información en pequeñas empresas. los fundamentales son: . varias compañías han creado en torno a él soluciones comerciales que ofrecen variadas opciones. multiusuario y de código abierto. 2010) Fue elegido dicho gestor por ser un sistema objeto-relacional. balanceo de carga y replicación con PostgreSQL. (PostgreSQL. que frena su empleo y proliferación en el país. que impiden el aprovechamiento al máximo de sus potencialidades y dificultan su empleo. facilitando la instauración de una solución de replicación que garantice la alta disponibilidad y protección de la información en entornos pequeños. potente y diseñado esencialmente para sistemas de información transaccional. e incluso. la Comunidad Técnica Cubana de PostgreSQL con el propósito de potenciar el empleo de PostgreSQL como sistema de gestión de bases de datos.Favorecería la protección de la información al tener un respaldo el servidor de bases de datos de las empresas. de contar con una amplia gama de soluciones en torno a él para lograr la alta disponibilidad de la información. El desarrollo de soluciones de software costosas con base en este tipo de gestores. en febrero de 2009. (PGDG. sin necesidad de invertir en recursos de hardware y software. balanceo de carga y replicación. . 2011) El proyecto PostgreSQL ha implementado varias soluciones para hacer frente a este problema de la alta disponibilidad de la información. que muchas veces requieren ordenadores potentes y comunicación constante entre ellos. los especialistas cubanos se enfrentan a algunos problemas a la hora de identificar una solución que garantice la disponibilidad de una información siempre consistente. 2011) No obstante las características que lo reafirman como el gestor de código abierto más potente del mercado y. Con la cual se: . La posibilidad real de que en las soluciones propietarias empleadas existieran puertas traseras.1. Ante esta situación. dejando al país vulnerable a ataques causantes de daños a la economía y seguridad nacional. de propósito general.Disminuirían las posibilidades de congestión de los servidores de bases de datos de las empresas al balancear la carga de las peticiones. Estos problemas influyen negativamente en la instauración de soluciones para la disponibilidad de la información y su protección en las empresas y organismos del país. surge la propuesta de desarrollar un ejecutable que automatice el proceso de configuración de servidores PostgreSQL 9.La dificultad para configurar estas soluciones en la mayoría de los casos.org.La inexperiencia en el trabajo con las tecnologías para el montaje de las soluciones de alta disponibilidad.La poca disponibilidad de recursos materiales para el diseño de soluciones de alta disponibilidad. A raíz de esta situación se creó en la Universidad de las Ciencias Informáticas. . disminuyéndose las utilidades de los proyectos de exportación de las empresas productoras de software.- - El pago de grandes sumas de dinero por su empleo en aquellas empresas donde se utilizaban en contratos con terceros.

donde cada servidor trabaja independientemente y periódicamente se comunica con los demás servidores para identificar los conflictos. métodos de indexado y lenguajes procedurales. permitiendo distribuir la carga de lectura. éste de forma asincrónica envía los datos modificados al esclavo. de propósito general. vistas. quien puede responder consultas de sólo lectura mientras el servidor maestro está corriendo. 2011) Warm Standby y Hot Standby usando PITR (Point-in-Time Recovery) Los servidores warm y hot pueden mantenerse actualizados mediante la lectura de los registros WAL. La principal limitante de este método es que si el arreglo de discos falla o se corrompe. 2011) Replicación síncrona multimaestro 4 . Bucardo implementa este mecanismo. No existe una solución única que elimine este problema de sincronización. Si el servidor principal falla. multiusuario y de código abierto liberado bajo la licencia BSD. Si el servidor principal falla el esclavo es habilitado. 2011) Replicación con una capa media basada en sentencias Con este tipo de replicación un programa intercepta cada consulta SQL y la envía a uno o más servidores. operadores. Un servidor esclavo PITR puede implementarse usando transporte de registros basados en archivos. funciones agregadas. 2011) Replicación basada en triggers de maestro a esclavo Una replicación maestro-esclavo envía las consultas de modificación de datos al servidor maestro. Su principal restricción es que la copia debe hacerse de forma que se asegure que el esclavo tenga una copia consistente del sistema copiado. Compartición de disco ante fallas Permite la sincronización teniendo una sola copia de la base de datos almacenada en un arreglo de discos compartido por múltiples servidores. donde todos los cambios al sistema de archivos son duplicados a un sistema de archivos residente en otra computadora. Pgpool-II y Sequoia implementan este mecanismo. current_timestamp() y similares. replicación de flujos o una combinación de ambas. 2011) Replicación del sistema de archivos Versión modificada de la funcionalidad de compartir hardware. por lo que para resolverlo se deben implementar otros mecanismos. uno de los esclavos pueden establecerse rápidamente como el nuevo servidor de bases de datos maestro. 2011) Técnicas implementadas por PostgreSQL para la alta disponibilidad. Este método asincrónico sólo puede realizarse para el servidor de bases de datos entero. (PGDG. aquellas de lectura-escritura se envían a todos los servidores y las de sólo lectura a uno de ellos. (PGDG. El principal problema de este tipo de replicación es que consultas como random(). (PGDG. pueden tener valores diferentes en los servidores. a los que en la mayoría de los casos les llegan peticiones tanto de lectura como de escritura. funciones ventanas y funciones recursivas. control de concurrencia multiversión y que puede ser extendido por el usuario añadiendo tipos de datos. disparadores. (PGDG. los servidores primario y esclavo no funcionan. (PGDG. 2011) Replicación asíncrona multimaestro Empleada para servidores que no están regularmente conectados. (PGDG. (PGDG. son difíciles de combinar para balancear la carga entre ellos. las existentes (descritas brevemente en los subepígrafes siguientes) tratan de resolverlo de distintas maneras minimizando su impacto para casos específicos. Slony-I implementa este mecanismo. integridad transaccional. que soporta gran parte del estándar SQL y ofrece modernas características como consultas complejas. debido a que los datos actualizados deben ser replicados al resto de los nodos del sistema de replicación para mantener la consistencia de los mismos. además el esclavo nunca podrá acceder al almacenamiento compartido mientras el servidor primario esté corriendo.PostgreSQL es un sistema de gestión de bases de datos objeto-relacional. el balanceo de carga y la replicación Los servidores de bases de datos.

El emplear solamente este método puede ocasionar que se pierdan las últimas transacciones registradas en el servidor maestro en caso de alguna caída del mismo. 2011) Determinación de qué técnica emplear para los entornos pequeños De todas las técnicas analizadas. está basado en la transferencia de registros WAL entre servidores. en el servidor esclavo existe un proceso receptor WAL que se conecta mediante TCP/IP al maestro. al cada servidor aceptar peticiones de escritura. (Martínez. Una gran actividad de escritura puede causar bloqueos excesivos afectando el rendimiento.org-1. . . cada servidor acepta peticiones de escritura y los datos modificados son transmitidos del servidor original a cada nodo antes de cada commit de la transacción. Registro WAL Archivos WAL Directorio pg_xlog Directorio pg_xlog Fig. permitiendo balancear la carga de peticiones entre éste y el servidor maestro.En esta solución. 5 . Streaming Replication permite transferir asincrónicamente registros WAL sobre la marcha entre los servidores. que puede ser implementada en 2 fases. de forma que no se sobrecargue el último. dando la posibilidad a pequeñas entidades y empresas la posibilidad de implementarla con el equipamiento de que disponen y sin invertir para ello en nuevo equipamiento. Hot Standby y Streaming Replication Este tipo de replicación incluido en el núcleo de PostgreSQL a partir de su versión 9. permitiendo que se realice la consulta de los datos sin necesidad de que ambos servidores del sistema de replicación estén disponibles.. lo que implica que el suplente se conecta al maestro copiando las cadenas del WAL como son generadas sin esperar a que sean archivadas.El servidor esclavo puede aceptar consultas de sólo lectura. donde el proceso remitente WAL envía los registros sobre la marcha al esclavo. (PostgreSQL.No se requiere hardware especial. Es mejor fundamentalmente para cargas de trabajo de sólo lectura.No se espera por múltiples servidores. la solución que está más acorde a las necesidades de los entornos pequeños del país es la asíncrona. 2010) Como muestra la figura 1. no existen problemas con funciones no determinísticas como random(). Registro WAL Remitente WAL Receptor WAL Servidor maestro Servidor esclavo Archivos WAL Registro WAL Registro WAL .0. Hot Standby permite transferir asincrónicamente los registros WAL cuando éstos están completos. 1: Funcionamiento de Streaming Replication Por su parte. El emplear solamente esta característica puede ocasionar que el maestro recicle los ficheros WAL antes de que sean transferidos al esclavo. reduciéndose el tiempo de desincronización entre los servidores. la que se realiza de registro a registro o de ficheros WAL completos.. en la que: .

6.(Martínez.Minimiza las posibilidades de pérdidas de información. (Martínez. .El tiempo de desincronización entre los servidores es el menor posible.El servidor esclavo puede configurarse como maestro en caso de caídas del principal. 6 . . 3. Estas dos funcionalidades combinadas implementan en el núcleo del gestor lo necesario para instalar un sistema de replicación asíncrono maestro-esclavo. para tener un sistema más robusto se suelen emplear los dos métodos conjuntamente.Garantiza la protección de la información.Permite el balanceo de carga entre ambos servidores. al archivar los WAL en ambos servidores. 2. 2010) 1. Configurar el maestro para que soporte la transferencia de archivos WAL al esclavo vía Streaming Replication. 5. Realizar copia de seguridad base del servidor maestro. 4. Configurar el servidor maestro para que soporte la replicación con Hot Standby y el archivado WAL. 2011) . ya que: . Iniciar el servidor maestro. Restaurar la copia de seguridad base del servidor maestro en el esclavo. 2010) Peticiones de Lectura/Escritura Peticiones de Lectura Remitente WAL Streaming Replication basada en registro a registro Receptor WAL Servidor maestro Servidor esclavo copy / rsync Archivos WAL WAL archivados Directorio pg_xlog Directorio de archivo Trasnferencia de archivos WAL completos Archivos WAL transferidos Archivos WAL Directorio pg_xlog Directorio de archivo Fig. . se debe contar con un procedimiento que explique los pasos necesarios para ello. 3. Crear los directorios necesarios para el sistema de replicación en ambos servidores (para el archivado de WAL en el maestro y en el esclavo y otro en el esclavo para los WAL transferidos desde el maestro). Procedimiento para la configuración de Hot Standby y Streaming Replication Para el montaje de una solución de replicación con Hot Standby y Streaming Replication se deben realizar los pasos siguientes para la correcta configuración de los servidores PostgreSQL: (Sotolongo. . al tener las bases de datos íntegras en dos localizaciones. .No requiere de invertir en nuevo equipamiento. MONTAJE DE UNA SOLUCIÓN DE REPLICACIÓN BASADA EN HOT STANDBY Y STREAMING REPLICATION PARA ENTORNOS PEQUEÑOS Para el montaje de la solución de replicación basada en Hot Standby y Streaming Replication para entornos pequeños en el país. 2: Replicación combinando Hot Standby y Streaming Replication La solución mostrada en la figura 2 es la más acertada para implementar en los entornos pequeños del país empleando tecnologías de bases de datos de código abierto.Por tales motivos.

Configurar el acceso mediante llaves SSH entre el maestro y el esclavo. La solución fue probada en PostgreSQL 9. A este script se le realizaron pequeñas modificaciones de localización de los directorios. 8. Estar disponibles y conectados a la red ambos servidores.pub ipservidoresclavo:/var/lib/pgsql/. 8.sh se deben cumplir los siguientes requerimientos: 1.10.ssh/authorized_keys. 9.ssh/authorized_keys. Requerimientos para la ejecución del script de configuración Hot Standby y Streaming Replication Para la correcta ejecución del script hs_sr.sh: programa que ejecuta todos los pasos definidos en el procedimiento culminando en el montaje exitoso de la solución de replicación con Hot Standby y Streaming Replication.hs_sr. Solución de automatización del montaje del sistema de replicación La propuesta está conformada por dos scripts que automatizarán. sobre todo para aquellos usuarios principiantes en las tecnologías de código abierto. (Martínez. puedan montar el sistema de replicación. aún la configuración de esta solución es un poco rebuscada. El grupo de desarrolladores de PostgreSQL se ha centrado en proveer la infraestructura necesaria para poder implementar y usar este tipo de replicación.1. Reiniciar los servidores maestro y esclavo. es que se propone el desarrollo de un script en Bash que facilite la automatización del procedimiento pretende que. Tener instalado el paquete ssh en ambos servidores. Editar en los script hs_sr.postgres /usr/local/pgsql.ssh/id_rsa. Copiar el script archivador_wal. en función de la instalación realizada para las pruebas. garantizando que puedan comunicarse.1: .sh los IP de los servidores maestro y esclavo y. Configurar el esclavo para que soporte la replicación con Hot Standby aceptando consultas de sólo lectura. Crear el fichero authorized_keys en el directorio home del usuario postgres en el servidor esclavo con el contenido de la llave pública del servidor maestro: logueados como root utilizar el comando scp /var/lib/pgsql/.1 en ambos servidores con los clústeres inicializados y los servicios detenidos. Antes de ejecutar el script hs_sr. cualquier otro parámetro que deba ser actualizado acorde a las características y configuraciones de los servidores en los que se montará la solución. para ello se debe: a.ssh/id_rsa. Activar el uso de ficheros WAL transferidos en el proceso de restauración del servidor. Crear el fichero authorized_keys en el directorio home del usuario postgres en el maestro con el contenido de la llave pública del servidor esclavo: logueados como root utilizar el comando scp /var/lib/pgsql/. garantizando la disponibilidad y protección de la información en entornos pequeños con el empleo de tecnologías de código abierto.1. 2010) . 7. 5. 2. 3. Como se evidencia en el procedimiento.sh establecer a postgres como el propietario del directorio de instalación del gestor y sus subdirectorios: logueados como root utilizar el comando chown -R postgres.7. el proceso de configuración de la solución de replicación que ofrece PostgreSQL 9. aún especialistas con pocos conocimientos de PostgreSQL y el sistema operativo. La solución fue probada en Ubuntu 10. Tener instalado PostgreSQL 9.sh: script creado por Rafael Martínez mediante el cual se copian los archivos WAL a archivar al directorio /usr/local/pgsql/wal_arch en el maestro y al directorio /usr/local/pgsql/wal_shipped en el esclavo. Tener instalado en ambos servidores (maestro y esclavo) el sistema Linux de forma idéntica.pub ipservidormaestro:/var/lib/pgsql/. 7 . Generar las claves públicas y privadas entre el servidor maestro y el esclavo: una vez logueados como postgres en ambos utilizar el comando ssh-keygen -t rsa.sh y archivador_wal. c.archivador_wal. mediante su ejecución. En correspondencia con esta necesidad. 6.sh en el directorio /usr/local/pgsql/bin/ del servidor maestro. a la que en fases posteriores se le deberán realizar programas/scripts para facilitar su administración y monitorización. 4. b.

tar que compacta el directorio DATA . mediante la adición de la entrada: .sh -P %p -F %f' .9. modificándose en el postgresql. creándose: .wal_keep_segments = 10 . para ello se debe modificar en el postgresql.hot_standby = on .conf los parámetros standby_mode = on.conf.Se realiza una copia del fichero recovery.pg_stop_backup() que detiene la creación del respaldo Función para restaurar el respaldo obtenido del servidor maestro en el esclavo. .sh. los que automáticamente abortan la ejecución del resto del script Función para la configuración del maestro de forma que soporte la replicación con Hot Standby.Se elimina el directorio DATA del esclavo .conf los parámetros: .conf del servidor esclavo el parámetro hot_stanby = on Función para activar el uso de los WAL transferidos desde el maestro al esclavo y en caso de fallas restaurar el último.max_standby_archive_delay = 120s .sh Función crear_directorios () Descripción Función para la creación de los directorios necesarios para el sistema de replicación y el otorgamiento de los permisos a postgres de los mismos. Ejecutar el script hs_sr.Se descompacta el respaldo base del maestro en el directorio pgsql del esclavo.pg_start_backup(„etiqueta‟) que inicia la creación del respaldo .Los comandos especificados en la cláusula ELSE de este y todos los comandos del script son en caso de errores. primary_conninfo = 'host=$SERVIDOR_MAESTRO port=5432 user=postgres'. soportar_replica cion() soportar_transfer encia_wal() iniciar_maestro( ) obtener_respald o_base() restaurar_respal do_base() soportar_rep_esc lavo() activar_uso_wal _transferidos() 8 .“Host replication all $SERVIDOR_ESCLAVO trust ” Especificando el IP del esclavo al pg_hba.Se edita en el nuevo recovery.Un directorio wal_arch para archivar los WAL del maestro.max_standby_streaming_delay = 120s Función para la configuración del maestro para que soporte la transferencia de archivos WAL al esclavo vía Streaming Replication.sh La tabla 1 muestra la descripción de las funciones definidas en el script con su respectiva explicación. Descripción de las funciones definidas en el script hs_sr.max_wal_senders = 1 .archive_command = '/usr/local/pgsql/bin/archivador_wal.wal_level = hot_standby .archive_mode = on .Se copia el respaldo base del maestro al esclavo . que hasta el momento no había sido iniciado Función para obtener el respaldo base del servidor maestro mediante: . para lo que: .Un directorio wal_shipped para transferir los WAL del maestro al esclavo.conf Función para iniciar el servicio postgresql en el servidor maestro mediante el pg_ctl. para ello: .sample ubicado en el directorio SHARE para el DATA . Tabla 1: Funciones definidas en el script hs_sr.sh con el usuario postgres: se puede emplear el comando source /directorio/ubicación/hs_sr. el cual sustituye al recién eliminado directorio DATA Función para activar en el esclavo el soporte a la replicación con Hot Standby aceptando consultas de sólo lectura.Un directorio wal_arch para archivar los WAL del esclavo. para un mayor entendimiento del mismo y que pueda ser adaptado al entorno de cada especialista. . .

1 con Hot Standby y Streaming Replication. 5: Listado de bases de datos existentes en el maestro sin haber realizado ninguna acción Fig.sh. Las figuras siguientes evidencian su correcta ejecución y con ella la configuración del sistema de replicación de PostgreSQL 9. 7: Bases de datos en el maestro Fig. 3: Ejecución de hs_sr.reiniciar_servido res() trigger_file = '/usr/local/pgsql/data/pg_failover_trigger' y restore_command = 'cp /usr/local/pgsql/wal_shipped/%f %p' .sh Fig. Fig.4: Culminada la ejecución de hs_sr.Se le otorgan a postgres los privilegios sobre el directorio PGSQL y DATA Función para reiniciar ambos servidores con pg_ctl en función de que los cambios realizados a los ficheros de configuración tengan efecto Ejecución y resultados del script hs_sr. 8: Bases de datos en el esclavo. se ejecutó el script hs_sr. 6: Esclavo sin acciones en el maestro Fig.sh Una vez satisfechos todos los requerimientos.sh en el maestro Fig. replicada la base de datos probando_replicacion 9 .

sh validaciones de los comandos sed que verifiquen las sustituciones exitosas o no de los mismos. .Añadir al script hs_sr.Continuar mejorando el script hs_sr. puede que consultándose el esclavo no se reflejen los cambios.Fig.sh el procedimiento para la activación automática del servidor esclavo como el maestro en caso de fallo del servidor maestro en uso.Agregar al script hs_sr. en todo momento los servidores están sincronizados. 4. ellas son: . se debe: .sh con vistas a ofrecer una solución más robusta que valide los posibles errores o fallos que se produzcan cuando el sistema esté en explotación y. El cual no debería generarse ya que la función soportar_replicacion() se encarga precisamente de cambiar el valor de wal_level a hot_standby. que realice un correcto tratamiento de estos errores.Añadir al script hs_sr. Proyecciones inmediatas Aún cuando se logre la sincronización entre ambos sitios y por ende.Una vez ejecutado correctamente el script y realizadas acciones en el servidor maestro. Volviendo a loguearse como postgres y ejecutando nuevamente el script culmina la configuración del sistema de replicación exitosamente. . 10: Propiedades de la tabla tb_persona en probando_replicacion replicada al servidor esclavo Como muestran las figuras anteriores.Añadir al script hs_sr.sh la compatibilidad con el método de encriptación md5.sh tareas de mantenimiento para limpiar los directorios donde se archivan los ficheros WAL en el servidor maestro y donde se transfieren los ficheros WAL en el servidor esclavo. . CONCLUSIONES 10 . teniendo la recién creada base de datos probando_replicacion y las mismas propiedades la recién creada tabla tb_persona en la base de datos probando_replicacion en ambos sitios. 9: Propiedades de la recién creada tabla tb_persona en probando_replicacion en el maestro Fig. . .Añadir al script hs_sr. .sh Durante las pruebas de ejecución del script se detectaron algunas deficiencias que no pudieron ser resueltas debido a que no fueron encontradas las causas que las ocasionaban. Posibles errores con la ejecución del script hs_sr. Reiniciando el servidor esclavo se reflejarán automáticamente.sh tareas de monitorización del estado de la replicación para saber el retraso del servidor esclavo en relación al maestro.Una vez ejecutado el script por primera vez puede generarse el error: ERROR WAL level not sufficient for making an online backup HINT: wal_level must be set to “archive” or “hot_standby” at server start. la protección de la información.

Impacto económico El empleo de esta solución en lugar de soluciones propietarias garantizaría el ahorro en el pago de licencias de uso y soporte. 3.Favorece la protección de la información al tener un respaldo el servidor de bases de datos de las empresas. replicación del sistema de archivos. puedan montar el sistema de replicación.] 2. en la que fundamentalmente no se requiere hardware especial.Las técnicas fundamentales que implementa PostgreSQL para garantizar la disponibilidad y protección de la información son: la compartición de disco ante fallas. 2010.La solución que está más acorde a las necesidades de los entornos pequeños del país es la asíncrona. La propuesta está conformada por dos scripts bash que automatizan el proceso de configuración de la solución de replicación que ofrece PostgreSQL 9.] http://www. 11 .html. Warm Standby y Hot Standby usando PITR. 2010. Gilberto. garantizándose el montaje de una solución con PostgreSQL 9. . [Citado el: 26 de julio de 2011. Capacitación de uso y administración de PostgreSQL. replicación basada en triggers de maestro a esclavo. [En línea] 2011. . AKREN. REFERENCIAS 1. su empleo constituye un paso de avance significativo en el proceso de migración al software de código abierto que lleva a cabo el país.Facilita el proceso de configuración de la solución de replicación con tecnologías de bases de datos de código abierto. . . Impacto social La utilización de esta solución en las empresas y organismos cubanos: .La solución de replicación con Hot Standby y Streaming Replication de PostgreSQL 9. 2011.Hot Standby y Streaming Replication son dos características de PostgreSQL. [En línea] 2011. 2011.sh. que combinadas implementan en el núcleo del gestor lo necesario para instalar un sistema de replicación asíncrono maestro-esclavo robusto. replicación con una capa media basada en sentencias. Software greenhouse. Como resultado del trabajo se arriban a las siguientes conclusiones: . Su configuración aún es un poco rebuscada. razón por la que la propuesta del presente trabajo fue el desarrollo de un script en Bash que facilite la automatización de dicho proceso para que.n.sh y (2) hs_sr. sin necesidad de invertir en recursos de hardware y software. Además.com/Productos/Vision/DefHighAval. [Citado el: 26 de julio de 2011.1 permite la instauración de un sistema de replicación asíncrono maestro-esclavo que garantiza la disponibilidad y protección de la información en entornos pequeños. Replicación de datos. Integración Tecnológica. CASTILLO MARTÍNEZ.Garantiza la alta disponibilidad de la información en pequeñas empresas. replicación asíncrona y replicación síncrona multimaestro.1 con Hot Standby y Streaming Replication: (1) archivador_wal. Conferencia impartida en el I Taller Temático del MIC: Formación para la migración a Estándares Abiertos. Ken. sobre todo para aquellos usuarios principiantes en las tecnologías de código abierto. aún especialistas con pocos conocimientos de PostgreSQL y el sistema operativo.1 para lograr la alta disponibilidad y protección de la información en entornos pequeños. .. en el que los nodos esclavos se pueden utilizar para realizar consultas de sólo lectura. La Habana : s. CORPORACIÓN-SYBVEN. Corporación Sybven. Alta disponibilidad de sistemas: una definición.swgreenhouse.Disminuye las posibilidades de congestión de los servidores de bases de datos de las empresas al balancear la carga de las peticiones.

. Disponible en http://www. 2011.0. Pérdidas millonarias por caídas de sistemas. PGDG.cu/node/46. Se desempeña como profesora en el Departamento de PostgreSQL del Centro. Anthony Rafael.] http://postgresql. Estrategia para la obtención de un gestor de bases de datos cubano.1: Comparison of different solutions. La Habana. PostgreSQL 9. 9. 7. 5. Yudisney. Tiene una categoría docente de Instructor y científica de Máster en Gestión de Proyectos Informáticos.corporacionsybven. Universidad de las Ciencias Informáticas. 2011.1 Documentation. California : s.uci. 2011. http://www. PostgreSQL 9. Rafael.] http://www. PostgreSQL-es. [Citado el: 26 de octubre de 2011. LaNación. [En línea] 2011.1. Es una de las fundadoras de la Comunidad Técnica Cubana de PostgreSQL. [En línea] 2011. en la que ha trabajado desde el 2009. en la Universidad de las Ciencias Informáticas. About. SOTOLONGO LEÓN. 8.com. 2011. SOBRE LOS AUTORES Yudisney Vazquez Ortíz trabaja en el Centro de Tecnologías de Gestión de datos de la Facultad 6. 10. VAZQUEZ ORTÍZ. Documentación.org/docs/. PostgreSQL. 2006. [Citado el: 18 de octubre de 2011.http://www.ar/848427-perdidas-millonarias-por-la-caida-de-sistemas.org/docs/9.es/node/483. 2011. [Citado el: 26 de julio de 2011. Hot standby y Streaming replication.lanacion.] http://www.ORG-1. 6. PostgreSQL. GARCÍA BARTELT.org.com.html. [Citado el: 12 de septiembre de 2011. Lisleydi Mier Pierre es estudiante de la facultad 4 de la Universidad de las Ciencias Informáticas. 80 páginas. Berkeley. 12 .postgresql. 2011.1/static/different-replication-solutions. Mercedes. 2011. [En línea] 2011. POSTGRESQL. [Citado el: 27 de julio de 2011. [En línea] 29 de junio de 2010. MARTÍNEZ.n.php?option=com_content&view=article&id=38 4:replicacion-de-datos&catid=124:conceptos-teoricos.com/portal/index. Comunidad Técnica Cubana de PostgreSQL. 4.org/about/.] http://www. 2010.ORG. [En línea] 11 de octubre de 2006.postgresql.4 Documentation.] Chapter 25. POSTGRESQL.postgresql.postgresql.