Configurando rplicas Maestro-Esclavo con Postgres

jue 10 noviembre 2011 By Israel Fermn Montilla In Blog. tags: Bases de DatosinformticaPostgresSoftware Libre Muchas veces, por alguna razn, hacemos desde la capa de aplicacin cientos de validaciones y procesos que, si sabemos cmo, podramos delegar en el manejador de base de datos. Las validaciones de reglas de negocio son un ejemplo muy frecuente de ello, tendemos, por ejemplo, a implementar validaciones redundantes (en el caso de entornos web) del lado del cliente, utilizando AJAX, y del lado del servidor, utilizando el lenguaje de programacin que ms nos agrade. Esto, aade un nivel de complejidad a nuestro sistema, cuando, muy tranquilamente, podramos delegar esa validacin en nuestro manejador de base de datos a travs de un Trigger, con la ventaja de que si algn da, otro sistema necesita conectarse a la base de datos, las reglas de negocio estn implementadas directamente en el manejador y, como ya estamos acostumbrados, todo corre ms rpido en el nivel ms bajo. Ahora bien, por qu empiezo diciendo todo eso?, simplemente por hacer referencia a un ejemplo bastante comn, en el que nosotros, programadores, desarrolladores, ingenieros, o como quieran llamarnos, hacemos uso (o quizs sub-uso) de un software muy sofisticado, como lo es un Manejador de Base de Datos y, tendemos a pensar, que es slo un pote para guardar datos que, adems, habla un lenguaje extrao llamado SQL. Otra de las cosas que, algunas veces, hacemos y nos hacen parecer novatos es actualizar dos servidores de base de datos distintos disparando sentencias hacia los dos, o tres, o cuantos sean. Esto aade un nivel de complejidad innecesario a nuestra aplicacin, adems de estar fuertemente acoplado con la arquitectura fsica (hardware) del sistema implementado, si el nmero de servidores a sincronizar cambia, ser necesario tambin realizar modificaciones a nivel de cdigo o de configuracin del programa y, adems, desaprovechamos la potencia que nos ofrece un manejador de base de datos. PostgresSQL nos ofrece la posibilidad de sincronizar dos servidores de base de datos mediante Replicacin. Existen distintos tipos de replicacin de servidores, en este caso, configuraremos un esquema Maestro-Esclavo, en el que mi servidor Maestro, recibe y ejecuta todas las transacciones y, adems, actualiza a mi servidor Esclavo, que, nicamente, realiza consultas. Empezamos por instalar la ltima versin disponible de Postgres, utilizando el gestor de paquetes de nuestra distribucin de Linux favorita, para este ejemplo, utilic Debian Wheezy (Testing) y Postgres 9.1.

Configurando el Maestro

El maestro, es el nodo que ejecuta todas las transacciones de base de datos, digamos que puede realizar todas las operaciones CRUD. Empecemos por establecer ciertos valores de configuracin para el manejador en el archivo /etc/postgresql/9.1/main/postgresql.conf. Debemos configurar los siguientes valores: `` listen_addresses = '*' wal_level = hot_standby wal_sync_method = fsync max_wal_senders = 2 wal_keep_segments = 8`` El parmetro listen_addresses establece las direcciones IP de donde mi servidor va a aceptar peticiones, este parmetro acepta valores separados por coma o el caracter asterisco, como en este caso, para especificar que va a aceptar peticiones de cualquier host, de no ser as, slo las IP listadas podran sincronizar la base de datos. El valor dewal_level, donde "wal" quiere decir "Write Ahead Log" y es una estrategia que implementan los manejadores para cumplir con las propiedades de Atomicidad y Durabilidad de las transacciones (recuerdan la regla ACID?) y consiste en escribir en un archivo de bitcora todas las modificaciones realizadas a la base de datos. En Postgres existen tres:minimal, que omite algunas operaciones de escritura para hacer las operacionas ms rpido, pero no guarda informacin suficiente para reconstruir la base de datos a partir de un archivo inicial y logs de este tipo, hot_standby yarchive, almacenan toda la informacin necesaria para hacer la reconstruccin completa de los datos, pero nicamentehot_standby permite implementar replicacin de base de datos hacia servidores remotos. La opcin wal_sync_methodes el mtodo que utilizar el manejador para forzar las actualizaciones utilizando WAL. En este caso, utilizamos fsyncque se asegura de que los cambios sean escritos fsicamente en la base de datos copia, ms informacin sobre los mtodos de sincronizacin disponibles puede conseguirse en [1]. El parmetro max_wal_senders establece el nmero de sincronizaciones concurrentes que puede ejecutar el servidor. Finalmente, wal_keep_segments, establece el nmero de WAL LOGS que el servidor guardar en el directorio pg_xlog, estos logs son utilizados para realizar el las actualizaciones va streaming. Una vez hecho lo anterior, tenemos la configuracin bsica de Postgres para hacer replicacin Maestro-Esclavo va streaming. Ahora, debemos agregar una regla ms de acceso al pg_hba.conf, para permitir a los esclavos conectarse al servidor maestro: `` host replication all 10.1.1.8/32 trust`` Con esa lnea, estamos configurando el servidor para que permita conexiones a todos los usuarios con permiso de replicacin desde la sub-red 10.1.1.8/32. Ahora, generamos los WAL, para ello, ejecutamos lo siguiente: `` postgres# SELECT pg_start_backup('1')`` Mientras eso est ocurriendo, en otro terminal, hacemos lo siguiente: `` # cd /var/lib/postgresql/9.1 # tar czvf backup.tgz main`` Con esto, estamos comprimiendo el directorio de datos de Postgres. Una vez hecho esto, detenemos la generacin de WAL: `` postgres# SELECT pg_stop_backup()`` El asunto general se resume con la siguiente ecuacin: backup inconsistente + WAL = restauracin a estado consistente. Estos WAL, se generan en el directorio pg_xlog, y debemos tomar el ltimo que fue escrito.

Configurando el Esclavo

Lo primero que debemos hacer es sustituir el directorio de datos de esta instancia de Postgres por el directorio de datos del Maestro. Luego, creamos un directorio recovery, donde copiaremos el ltimo WAL del directorio pg_xlog. Adicionalmente, debemos modificar el postgresql.conf con las siguientes variables: `` hot_standby = on wal_level = hot_standby`` Ahora, creamos un archivo de configuracin en la raz del directorio de datos establecer las siguientes opciones: `` standby_mode = 'on' primary_conninfo = 'host=[host_ip] port=5432 user=root password=[some_password]' restore_command = 'cp /var/lib/postgresql/9.1/main/recovery/%f %p'`` Con esto le decimos al servidor que va a esperar rplicas de primary_conninfo, adems, el restore_command indica dnde se encuentra el respaldo inicial inconsistente. Finalmente, nos aseguramos de que los roles tengan permiso de replicacin: `` postgres# SELECT * FROM pg_roles`` y, de no tener permisos de replicacin, alteramos los roles necesarios para ello: `` postgres# ALTER ROLE nombre WITH REPLICATION`` Una vez hecho todo esto, ya hemos configurado un sistema de replicacin MaestroEsclavo utilizando Postgres como sistema manejador de base de datos, y no hizo falta una toalla para eso. Fcil no?. [1] http://developer.postgresql.org/pgdocs/postgres/runtime-config-wal.html [2]`http://developer.postgresql.org/pgdocs/postgres/runtime-configreplication.html#GUC-HOT-STANDBY`_

Comments !