Planeta PostgreSQL-es

25 junio 2014

Rafael Martinez

Ya está disponible PgBackMan v1.0.0

comunidad

@pgbackman Estoy orgulloso de anunciar la primera versión disponible para el público de PgBackMan - PostgreSQL backup manager.

La idea de este software surgio en la última conferencia europea de PostgreSQL en Dublin y después de varios meses de desarrollo aqui tenemos la primera versión.

leer más

por rafaelma el 25 junio 2014 10:50

30 mayo 2014

Rafael Martinez

Reunión de junio de PostgreSQL España

comunidad

@postgrespana, El martes 10 de junio de 2014, a las 19:00h, se celebra la reunión de junio del grupo de usuarios PostgreSQL España.

La reunión se celebrará en "Madrid International Lab".

Más información:
http://www.meetup.com/PostgreSQL-Espana/events/185898162/

PostgreSQL y Big Data, Big Data y PostgreSQL. PostgreSQL y almacenamiento por columnas (columnar store).

leer más

por rafaelma el 30 mayo 2014 06:33

11 abril 2014

Rafael Martinez

Reunión de mayo de PostgreSQL España

comunidad

@postgrespana, El jueves 08 de mayo de 2014, de 19:00 a 21:00h, se celebra la reunión de mayo del grupo de usuarios PostgreSQL España.

La reunión se celebrará en "Madrid International Lab".

Más información:
http://www.meetup.com/PostgreSQL-Espana/events/176419782/

En mayo, pasada la resaca del puente, nos vestimos de gala para recibir a Magnus Hagander, desarrollador, committer y miembro del Core Team de PostgreSQL, y Presidente de PostgreSQL Europa.

Así que apúntate a la charla sobre "PostgreSQL Backup Strategies" que nos va a dar el crack de Magnus:

leer más

por rafaelma el 11 abril 2014 08:57

02 abril 2014

Jaime Casanova

Indexando ando: Índices GIN

PostgreSQL tiene varios tipos de índices: B-tree, Hash, GiST, Gin y SP-GiST. Obviamente cada uno de ellos cubre una necesidad específica. Por ejemplo, la documentación de PostgreSQL dice sobre los índices GIN:

Los índices GIN son índices invertidos que pueden manejar valores que contienen más de una clave, arreglos, por ejemplo. Como GiST y SP-GiST, GIN puede soportar diferentes estrategias de indexación definidos por el usuario y los operadores particulares con la que un índice GIN se puede utilizar varía en función de la estrategia de indexación. A modo de ejemplo, la distribución estándar de PostgreSQL incluye clases de operador GIN para arreglos unidimensionales, que admiten consultas indexadas utilizando estos operadores:

<@
@>
=
&&

(Consulte la Sección 9.18 para el significado de estos operadores.) Muchas otras clases de operadores GIN están disponibles en la colección contrib o como proyectos separados. Para obtener más información, consulte el Capítulo 57.

Así que los índices GIN pueden usarse para indexar los elementos de un arreglo, de un hstore y así.

Pero en esta ocasión hablaremos de uno de esos módulos contrib que proveen mas clases de operadores que pueden usarse con los índices GIN: pg_trgm.

Este módulo crea trigramas de cadenas de texto de modo que puede usarse para encontrar similitudes. Eso permite que los índices tipo GIN que usen la clase de operador gin_trgm_ops puedan ser usados en busquedas con LIKE aun cuando el comodín ‘%’ se encuentre al inicio del patrón de busqueda (por ejemplo: nombre LIKE ‘%jaime%’).

Para crear un índice que pueda usarse así, el índice debe crearse de este modo:

CREATE INDEX idx_gin ON table USING GIN (campo_texto gin_trgm_ops);

Con un índice como este he visto consultas bajar de más de 10s a unos pocos milisegundos; sin embargo, antes que corran a crear estos índices consideremos los problemas que tiene.

Considere la siguiente consulta “select show_trgm(‘Jaime Casanova’);” esta nos muestra los trigramas de una cadena de texto, en este caso 15 trigramas. Así que no es difícil imaginar que este tipo de índices crece mucho, y mientras mas grandes las cadenas de texto más crece el índice (debido a que habrá mas trigramas). Otra conclusión obvia es que mantener este tipo de índices puede ser costoso, de hecho pueden afectar mucho el rendimiento de INSERT y UPDATE, especialmente si hay varios de estos índices en la misma tabla, para disminuir un poco este problema se invento una técnica llamada fastupdate que consiste en mantener una lista no ordenada de pendientes. Así que los INSERT y UPDATE en lugar de insertar en el índice principal lo hacen en esta estructura de adicional hasta que ocurra un VACUUM o hasta que la lista de pendientes se haga mas grande que work_mem. Los inconvenientes son: 1) al leer el índice también debe leerse esta estructura adicional, lo que puede afectar al rendimiento de las consultas; y 2) un INSERT o UPDATE puede causar que la lista de pendientes se crezca demasiado y por lo tanto empezará procesar la lista de pendientes lo que afectará a ese INSERT o UPDATE y a todas las demás operaciones que esten ocurriendo de forma concurrente sobre esa tabla.

En conclusión; un índice GIN junto con el módulo pg_trgm puede ayudar enormemente al rendimiento de algunas consultas, sin embargo no se debe abusar de ellos pues pueden resultar un arma de doble filo.

por Jaime Casanova el 02 abril 2014 05:34

24 marzo 2014

Rafael Martinez

Reunión de marzo de PostgreSQL España

comunidad

@postgrespana, El miercoles 26 de marzo de 2014, a las 18:30h, se celebra la reunión de marzo del grupo de usuarios PostgreSQL España.

La reunión se celebrará en "Madrid International Lab".

Más información:
http://www.meetup.com/PostgreSQL-Espana/events/169322142/

El plan es el siguiente:

- De 18:30 a 19:00: networking y... ¡pizzas!
- Presentación: Mecanismos de Replicación y Alta Disponibilidad en PostgreSQL

No faltes
--
Rafael Martinez Guerrero
PostgreSQL-es

por rafaelma el 24 marzo 2014 10:21

03 febrero 2014

Rafael Martinez

Reunión de febrero de PostgreSQL España

comunidad

@postgrespana, El 4 de febrero de 2014, a las 18:30h, se celebra la reunión de febrero del grupo de usuarios PostgreSQL España.

La reunión se celebrara en "Madrid International Lab".

Más información:
http://www.meetup.com/PostgreSQL-Espana/events/162142082/

El plan es el siguiente:

- De 18:30 a 19:00: networking y... ¡pizzas! FCFS, así que recomendamos no llegar tarde ;P

- De 19:00 a 21:00: las charlas más espectaculares de postgres :) Empezando por un resumen de los mejores trucos y presentaciones vistos en PgDay+FOSDEM 2014 (fosdem2014.pgconf.eu)

leer más

por rafaelma el 03 febrero 2014 12:47

17 diciembre 2013

Rafael Martinez

Reunión de Diciembre de PostgreSQL España

comunidad

@postgrespana El grupo de usuarios de PostgreSQL España se reune mañana miercoles 18 de diciembre en Madrid.

Este es el anuncio publicado en la página del evento:
http://www.meetup.com/PostgreSQL-Espana/events/155241452/

".... ¡No te pierdas la primera reunión con charlas del grupo de PostgreSQL España! Para preparar bien las Navidades :) Contaremos con dos charlas muy interesantes:

- PostGIS, datos geoespaciales en PostgreSQL (Javier de la Torre)
- CTEs y queries recursivas en PostgreSQL (Álvaro Hernández Tortosa)

leer más

por rafaelma el 17 diciembre 2013 08:43

31 octubre 2013

Rafael Martinez

4ta Jornada PostgreSQL Argentina 2013

comunidad

@pgsqlar La 4ta Jornada intensiva sobre bases de datos PostgreSQL en Argentina se celebrará el proximo 14 de noviembre en Buenos Aires.

La entrada es libre y gratuita, y tendrá lugar en Capital Federal,
edificio de la Secretaría de Gestión y Coordinación Administrativa sito en Av. Roque Sáenz Peña 511, en el marco
del Foro de la Agenda Digital Argentina.

Contará con la presencia de expertos internacionales, autoridades
nacionales y funcionarios públicos, docentes y profesionales, entre
otros.

Para facilitar la organización y agilizar el ingreso solicitamos

leer más

por rafaelma el 31 octubre 2013 08:07

28 octubre 2013

Rafael Martinez

PGconf Europa 2013 a punto de comenzar

comunidad

#pgconfeu La conferencia PGconf Europa 2013 está a punto de comenzar. Este año se celebrará en Dublin, la capital de Irlanda.

Del 29 de octubre al 1 de noviembre podremos asistir en el hotel "Conrad Dublin" a sesiones de entrenamiento y presentaciones sobre PostgreSQL y temas relacionados.

Nos vemos en Dublin.
http://2013.pgconf.eu/
--
Rafael Martinez Guerrero
PostgreSQL-es

por rafaelma el 28 octubre 2013 01:21

27 octubre 2013

Rafael Martinez

PostgreSQL-es se ha trasladado a otro servidor

anuncio

PostgreSQL-es y Planeta PostgreSQL-es se han trasladado a un nuevo servidor este fin de semana. El nuevo servidor esta totalmente actualizado con las últimas versiones de los programas necesarios para que PostgreSQL-es funcione.

Si encontrais algun problema de acceso os podeis poner en contacto con webmaster@postgresql.org.es

por rafaelma el 27 octubre 2013 10:47

17 octubre 2013

Rafael Martinez

Problema con el I/O cuando tenemos muchas bases de datos en un mismo servidor

cpu

#postgresql Hace unos dias instalamos un nuevo servidor PostgreSQL 9.2 que se va a utilizar por diferentes cursos de bases de datos que se imparten en la facultad de informática de la Universidad de Oslo.

La idea es que cada alumno registrado en alguno de estos cursos tenga acceso a su base de datos postgreSQL para realizar sus prácticas.

leer más

por rafaelma el 17 octubre 2013 11:58

04 octubre 2013

Rafael Martinez

Grupo de usuarios PostgreSQL España en meetup

comunidad

#postgresql Ayer se anuncio la creación del grupo de usuarios PostgreSQL España en meetup.

"... El objetivo es ponernos en contacto todos los usuarios, desarrolladores, profesionales y entusiastas de PostgreSQL en España. Y vernos las caras. Organizar charlas, ir a eventos, etc. ..."

Obviamente, el grupo no está cerrado ni a españoles ni a residentes en España, así que aunque los eventos se programen para España, cualquiera es más que bienvenido/a, comenta el organizador principal del grupo, Álvaro Hernández Tortosa.

leer más

por rafaelma el 04 octubre 2013 09:26

29 septiembre 2013

TuBaseDeDatosLibre.org

Instalar phpPgAdmin en Debian Wheezy

 Asumiendo que usted esta usando Debian Wheezy y tiene una instalación funcional del servicio postgreSQL, siguiendo los siguientes pasos podrá usar phpPgAdmin para ejecutar consultas y algunas opciones de administración.

 Instalar phpPgAdmin

#aptitude install phppgadmin
.
Luego para hacerlo disponible:
#vi /etc/apache2/conf.d/phppgadmin
.
Buscar en el archivo #allow from all y descomentar, quedando así: allow from all
Reiniciar apache
# /etc/init.d/apache2 restart
Ahora podrás acceder vía url a tu instalación de phpPgAdmin, en http://localhost/phppgadmin ó http://127.0.0.1/phppgadmin
phppgadmin-postgres-debian

phppgadmin-postgres-debian

Para acceder, hacer clic en el enlace PostgreSQL que se encuentra a la izquierda.
phpPgAdmin por defecto trae deshabilitado el acceso a las bases de datos, tal vez para procurar que quien lo instale se de cuenta de las opciones con las que cuenta y las implicaciones de seguridad relacionadas al uso de esta herramienta. dicho esto, cuando intentamos entrar con nuestro usuario y contraseña, arrojara el mensaje “Login disallowed for security reasons.
.
Para habilitar el acceso diríjase al archivo de configuración de phpPgAdmin ubicado en /usr/share/phppgadmin/conf/config.inc.php
Ubique la linea:
$conf['extra_login_security'] = true;
y habilite el acceso quedando asi:
$conf['extra_login_security'] = false;
.
En el archivo de configuración encontrara muchas opciones para ajustar su administrador web de postgres a sus necesidades.
.

por leninmhs el 29 septiembre 2013 01:20

09 septiembre 2013

Rafael Martinez

Lanzamiento de PostgreSQL 9.3

postgres-logo

El Grupo Global de Desarrollo de PostgreSQL ha anunciado PostgreSQL 9.3, la última versión del líder en bases de datos de código abierto.

Esta versión amplía la fiabilidad, disponibilidad y capacidad de integración de PostgreSQL con otras bases de datos. Los usuarios ya están descubriendo que al utilizar la versión 9.3 pueden crear aplicaciones que antes no habrían sido posibles.

Entra las características más importantes a destacar en esta versión, podemos citar:

  • Conectores de datos foráneos modificables
  • Sumas de verificación de páginas de datos
  • leer más

por rafaelma el 09 septiembre 2013 02:02

05 agosto 2013

Jaime Casanova

VACUUM FREEZE y el misterio de relfrozenxid

En noviembre del 2012 asistí al PgDay en Buenos Aires. Ahí presente la charla “Autovacuum, ¿bendición o maldición? Afrontando el reto”. En uno de los puntos de la charla explique, o al menos eso trate, que es necesario tratar de prevenir que el autovacuum ejecute VACUUM FREEZE.

El problema con VACUUM FREEZE ejecutado por el autovacuum es que leerá y escribirá toda la tabla y las probabilidades son que el autovacuum decida hacer esto en un momento de alta actividad. Durante la charla entonces explique que podemos tratar de adelantarnos al autovacuum chequeando el valor del campo relfrozenxid en la tabla de sistema pg_class, ahora agregare que la consulta es similar a: select relname, age(relfrozenxid) from pg_class where relkind = ‘r’ order by 2 desc;

En todo caso, como era de esperarse, surgió la pregunta: ¿qué contiene el campo relfrozenxid? A lo que yo respondi: “Básicamente, indica cual es el xid (id de transacción) mas bajo que podría encontrar en una tabla”. Claro, estaba simplificando un poco las cosas, y como no recordaba la definición exacta del campo no pensaba ahondar mas en ese tema. Además mi respuesta fue tan exacta como necesitaba serlo.

Excepto que luego de terminar la charla alguien me abordo y me dijo que aunque la charla había sido buena, me había equivocado sobre relfrozenxid pues supuestamente ese campo contenía el xid del último VACUUM FREEZE, y para probarlo el corrió un VACUUM FREEZE en una tabla y claro el campo fue actualizado al valor del xid que ejecuto ese VACUUM FREEZE. En ese momento ofrecí un artículo de blog aclarando el punto, pues yo sabía que yo tenía la razón aunque la prueba inmediata decía lo contrario. Y si se preguntan porque no lo aclare en ese momento: estaba en otro país, quería pasear.

Han pasado casi 8 meses y recién tengo tiempo y estoy de animo de escribir. Así que aquí está; mas vale tarde que nunca, ¿verdad?

Antes que nada me mantengo en mi afirmación: “Básicamente, indica cual es el xid (id de transacción) mas bajo que podría encontrar en una tabla” (simplificando).

Para probarlo crearemos una tabla t1(i int). Abriremos 3 sesiones y ejecutaremos “select txid_current();” en cada sesión para saber por cual id de transacción vamos, en mi caso las sesiones dieron los siguientes valores: 781, 782, 783. Luego abra 2 transacciones (en dos de las sesiones que abrimos previamente) y ejecute “select txid_current();” en cada una para asegurarse que la transacción consuma un id de transacción (784 y 785, en este caso). Entonces en la transaccion que se abrio último (785) ejecute: “insert into t1 select generate_series(1, 5);” y “commit;”, eso insertará 5 registros en la tabla t1 y cerrará una de las transacciones que abrimos y la otra quedará abierta (se cerró la transacción 785 y permanece abierta la 784).

Finalmente, en la tercera sesión que habíamos abierto, ejecute “select txid_current();” (que dará como resultado 786) seguido por “VACUUM FREEZE t1;” (que debería haber sido ejecutado en una nueva transacción por lo que debería tener 787 según la premisa de quien dijo que me había equivocado) y podemos consultar entonces “select relname, relfrozenxid from pg_class where relname = ‘t1′;” y encontraremos que en realidad el campo tiene: 784 (recuerden que el resultado que les dará es distinto pero que en esencia tendrán un valor menor al que se supone le corresponde al id de transacción del VACUUM FREEZE.

¿Por qué paso esto? simple, la transacción que dejamos abierta (la 784) necesita saber si los registros que la transacción 785 grabó son visibles para el o no y para esto necesita saber que transacción grabó esos registros y si esa transacción termino exitosamente. Debido a esto el VACUUM FREEZE no afecta los registros que podrían no ser visibles por alguna transacción, y el valor que se guarda en relfrozenxid corresponde al de la transacción mas antigua que este corriendo o al xmin de la tupla más vieja que podría no ser visible por dicha transacción. En todo caso, en la tabla no encontraré ninguna tupla con xmin inferior a relfrozenxid (expecto 2 y esto es la simplificación de la que hable antes).

Así que mi afirmación se mantiene, relfrozenxid “indica cual es el xid (id de transacción) mas bajo que podría encontrar en una tabla”.

A estas alturas quizá ya se estén preguntando que es exactamente lo que hace VACUUM FREEZE, pero no les recomiendo que esperen otro artículo hablando del tema… podrían pasar otros 8 meses hasta que me anime a escribirlo ;)

por Jaime Casanova el 05 agosto 2013 07:10

22 julio 2013

TuBaseDeDatosLibre.org

Bucardo, sincronización asíncrona

Bucardo es una herramienta de replicación de datos para el SGBD PostgreSQL. Este sistema es asíncrono, se puede realizar sincronización de tipo maestro-esclavo y maestro-maestro. Esta desarrollado con el lenguaje de programación Perl y su secreto para ser asíncrono es PL/Perl, creando en la base de datos unos script fabulosos. Es Software Libre y esta liberado con la licencia BSD.

¿Por qué Bucardo?

1.- Para PostgreSQL.
2.- Facilidad de usar.
3.- Estabilidad.
4.- Mantenimiento activo por su comunidad.
5.- Software Libre.
6.- Permite sincronización de maestro-maesto.
7.- No es necesario la replicación de toda la base de dato (se puede especificar los esquemas y las tablas.).
8.- Sincronización de tipo asíncrona.

Problema solucionado con Bucardo.

En la organización se necesitaba realizar una aplicación de tipo distribuida donde si no existía conexión a internet continuara la operación, pero cuando existiera conexión, se sincronizaran las bases de datos (esquema o tabla) de todos los nodos involucrados (se necesitaba que todos los nodos conservaran la misma información).

Leyendo en la web nos conseguimos las siguientes definiciones importantes para entender en el proceso:

Replicación: Es el proceso de intercambiar datos de transacciones para asegurar la consistencia entre nodos de bases de datos redundantes. Es el proceso de copiar y mantener los elementos de una base de datos en múltiples bases de datos que forman un sistema de bases de datos distribuido.
Alta disponibilidad (high availability): Se puede incrementar la disponibilidad de una base de datos mediante la replicación en un sistema distribuido. Si una de las máquinas del sistema falla, las otras podrán satisfacer las necesidades del cliente.
Balance de carga (load balancing): La replicación se puede utilizar para hacer un balance de carga. Ésta es una técnica usada para compartir el trabajo a realizar entre varias computadoras.
Soporte para aplicaciones de alto consumo: Se puede satisfacer las necesidades de ciertos clientes que requieren un alto consumo en consultas, que sería muy costo en rendimiento, o hasta imposible, en una base de datos sin replicación.
Confiabilidad: Debido a que existen varias copias de los datos disponibles en el sistema, se cuenta con un mecanismo confiable de recuperación de datos ante fallos en algún nodo.
Replicación síncrona: Una transacción de modificación de datos no es considerara hasta que todos los servidores confirmaron la transacción. Esto garantiza que ante un eventual error en la transacción no se perderán datos y que todos los servidores de carga balanceada devolverán resultados consistentes sin importar cual de los servidores haya sido consultado.
Replicación asíncrona: Permiten un retraso entre el momento en que se realiza una consulta y el tiempo de propagación a los otros servidores. Aquí existe la posibilidad de que algunas transacciones se pierdan cuando se cambia a un servidor de respaldo y que los servidores de carga balanceada devuelvan resultados ligeramente antiguos. La comunicación asíncrona es utilizada cuando la comunicación sincrónica sería muy lenta.
Asynchronous Multimaster Replication: Para los servidores que no están conectados regularmente, mantener los datos consistentes a través de estos es un gran desafío. Usando este tipo de replicación, cada servidor trabaja de manera independiente y periódicamente se comunica con los otros servidores para identificar las transacciones conflictivas. Estos conflictos pueden ser resueltos por el usuario o por reglas de resolución de conflictos.
Synchronous Multimaster Replication: En este tipo de replicación, cada servidor puede aceptar solicitudes de escritura y los datos modificados son transmitidos desde el servidor original al resto de los servidores antes de que cada transacción sea confirmada. Una fuerte actividad de escritura puede causar un bloqueo excesivo, causando un bajo rendimiento. Las solicitudes de lectura pueden ser enviadas a cualquier servidor.
Transaction Log Shipping: Los servidores warm standby y hot standby pueden mantenerse actualizados leyendo un flujo de registros de WAL (write-ahead log). Si el servidor principal falla, el servidor standby contiene casi todos los datos del servidor pincipal, y puede ser rápidamente convertido en el nuevo servidor master. Este modelo puede ser sincrónico o asincrónico, y sólo puede ser implementado para el servidor de base de datos completo.
Trigger-Based Master-Standby Replication: Este tipo de replicación envía todas las consultas de modificación de datos al servidor master. El servidor master envía asincrónicamente las modificaciones de los datos al servidor standby. Éste último puede responder consultas de sólo lectura mientras el servidor master esta corriendo.

 

Instalación de Bucardo en ambiente Debian GNU/Linux Squeeze con PostgreSQL 8.4.

Se supone que tenemos PostgreSQL 8.4 instalado y corriendo, bajo Debian GNU/Linux Squeeze u otras maquinas que se tenga acceso a la base de datos. Bucardo no corre bajo ambiente de sistema operativo Windows por ahora según su sitio oficial, pero eso no quiere decir, que no se pueda sincronizar bases de datos PostgreSQL bajo ambiente Windows. En realidad en la practica la institución no tiene sus máquinas bajo GNU/Linux, solo unos cuantos servidores.

Se requiere ejecutar el comando como root: “aptitude install bucardo libdbix-safe-perl libdbd-pg-perl postgresql-plperl-8.4

Luego se edita el archivo instalado en /usr/bin/bucardo_ctl en la linea donde se ubica “my $default_bucardo_password” cambiando el valor asignada a la variable por una clave que luego se va a colocar en el usuario Bucardo en base de dato.

Procedemos a instalar los lenguaje plpgsql y plperlu por medio del Shell de PostgreSQL, por Pgadmin3 o phppgadmin (el que maneje mejor o mas cómodo te parezca), en las bases de datos, con las siguientes lineas:
“CREATE LANGUAGE plpgsql;
CREATE LANGUAGE plperlu;”

Se crea el usuario “bucardo” con todas la permisologias en las bases de datos donde se vallan a realizar la sincronización, con la misma clave colocada en el script de bucardo en el segundo paso de la instalación.

Para realizar la sincronización Bucardo necesita su propia base de datos con todas las configuraciones necesarias. Esta base de datos se creara en el nodo donde se realizaran las consultas y sincronización principal con el siguiente comando en shell: “psql -h localhost -U postgres < /usr/share/bucardo/bucardo.schema

 

Configurando las sincronizaciones en Bucardo.

Lo primero es saber  que no se va a realizar balanceo de carga ni alta disponibilidad (para eso se necesita otras herramientas, como por ejemplo, Pgpool-II y Heartbeat). En este caso se necesita 4 base de datos que se encuentren en linea, distribuida y con los datos actualizados en todas, todas tienen que ser de tipo master ya que en cada una se van a realizar operaciones CRUD (Create, Read, Update, Delete).

Buscamos (por medio de shell, Pgadmin3 o phppgadmin) la base de datos “bucardo” en el servidor principal, en el esquema “bucardo” se encuentran varias tablas que vamos a manipular. La primera tabla es “db”, esta tabla contiene la información de los host y base de datos a sincronizar, realizamos unos INSERT en la tabla para darle la información de los nombres, nombre de la base de datos (no necesariamente tiene que ser el mismo nombre en todos los host), dirección IP, usuario para realizar la verificación y las operaciones CRUD (en este caso seria “bucardo” previamente creado) y contraseña de este usuario.

INSERT INTO bucardo.db (name, dbname, dbhost, dbuser, dbpass) VALUES (‘localhost’, ‘repli’, ’127.0.0.1′, ‘bucardo’, ‘bucardo’);
INSERT INTO bucardo.db (name, dbname, dbhost, dbuser, dbpass) VALUES (‘remoto001′, ‘repli’, ’192.168.1.3′, ‘bucardo’, ‘bucardo’);
INSERT INTO bucardo.db (name, dbname, dbhost, dbuser, dbpass) VALUES (‘remoto002′, ‘repli’, ’192.168.1.4′, ‘bucardo’, ‘bucardo’);
INSERT INTO bucardo.db (name, dbname, dbhost, dbuser, dbpass) VALUES (‘remoto003′, ‘repli’, ’192.168.1.5′, ‘bucardo’, ‘bucardo’);

Realizamos INSERT en la tabla “goat” para indicarle a Bucardo que esquema, cual tabla se va a sincronizar y que tipo de resolución de conflicto se va a realizar (existen diferentes tipos,  el ejemplo se va a realizar con el tipo “latest” que es aplica la lógica en cual información esta reciente  cambiada. También se puede realizar y personalizar esta opción según la página oficial de Bucardo para mejorar y personalizar la lógica del negocio).

INSERT INTO bucardo.goat (db, schemaname, tablename, standard_conflict) VALUES (‘localhost’, ‘public’, ‘tabla’, ‘latest’);
INSERT INTO bucardo.goat (db, schemaname, tablename, standard_conflict) VALUES (‘remoto001′, ‘public’, ‘tabla’, ‘latest’);
INSERT INTO bucardo.goat (db, schemaname, tablename, standard_conflict) VALUES (‘remoto002′, ‘public’, ‘tabla’, ‘latest’);

Se inserta en la tabla “herd” la siguiente información:

INSERT INTO bucardo.herd(name) VALUES (‘HERD_LOCALHOST’);
INSERT INTO bucardo.herd(name) VALUES (‘HERD_REMOTO001′);
INSERT INTO bucardo.herd(name) VALUES (‘HERD_REMOTO002′);

Necesitamos asociar la tabla “herd” con la “goat”, esto es necesario ya que podemos tener multiples tablas para las sincronizaciones (en este ejemplo solo tenemos una pero se puede dar el caso donde se necesite sincronizar diferentes tablas y diferentes esquemas). Esta asociación se realiza en la tabla “herdmap” con el siguiente comando SQL:

INSERT INTO bucardo.herdmap(herd,goat) SELECT ‘HERD_LOCALHOST’, id FROM bucardo.goat WHERE db = ‘localhost’;
INSERT INTO bucardo.herdmap(herd,goat) SELECT ‘HERD_REMOTO001′, id FROM bucardo.goat WHERE db = ‘remoto001′;
INSERT INTO bucardo.herdmap(herd,goat) SELECT ‘HERD_REMOTO002′, id FROM bucardo.goat WHERE db = ‘remoto002′;

Vamos a realizar las sincronizaciones propiamente dichas en la tabla “sync”, colocando el nombre de la sincronización, el herd que vamos a colocar como información para las tablas, el nombre del host que va a recibir o enviar la información y el tipo de sincronización (en este caso vamos a realizar con el tipo “swap”, ya que este tipo nos permite sincronizar dos maestros, haciendo que sea bidireccional los datos. Existen otros 2 tipos de sincronización pero es para ser tipo maestro-esclavo y para ser ese tipo de sincronización yo utilizaria Pgpool2 ya que se puede balancear las cargas y otros servicios que no nos proporciona bucardo.)

INSERT INTO bucardo.sync(name, source, targetdb, synctype) VALUES (‘localhostremoto001′, ‘HERD_LOCALHOST’, ‘remoto001′, ‘swap’);
INSERT INTO bucardo.sync(name, source, targetdb, synctype) VALUES (‘localhostremoto002′, ‘HERD_LOCALHOST’, ‘remoto002′, ‘swap’);
INSERT INTO bucardo.sync(name, source, targetdb, synctype) VALUES (‘localhostremoto003′, ‘HERD_LOCALHOST’, ‘remoto003′, ‘swap’);
INSERT INTO bucardo.sync(name, source, targetdb, synctype) VALUES (‘remoto001remoto002′, ‘HERD_REMOTO001′, ‘remoto002′, ‘swap’);
INSERT INTO bucardo.sync(name, source, targetdb, synctype) VALUES (‘remoto001remoto003′, ‘HERD_REMOTO001′, ‘remoto003′, ‘swap’);
INSERT INTO bucardo.sync(name, source, targetdb, synctype) VALUES (‘remoto002remoto003′, ‘HERD_REMOTO002′, ‘remoto003′, ‘swap’);

Activamos las sincronizaciones con los siguientes comandos SQL:

UPDATE bucardo.sync SET STATUS=’active’ WHERE name =’localhostremoto001′;
UPDATE bucardo.sync SET STATUS=’active’ WHERE name =’localhostremoto002′;
UPDATE bucardo.sync SET STATUS=’active’ WHERE name =’localhostremoto003′;
UPDATE bucardo.sync SET STATUS=’active’ WHERE name =’remoto001remoto002′;
UPDATE bucardo.sync SET STATUS=’active’ WHERE name =’remoto001remoto003′;
UPDATE bucardo.sync SET STATUS=’active’ WHERE name =’remoto002remoto003′;

.

Activando Bucardo.

Si es por primera vez que se activa Bucardo se necesita crear una carpeta “mkdir /var/run/bucardo/“. Luego se ejecuta el comando “bucardo_ctl -dbuser=’bucardo’ -dbhost=’localhost’ -dbpass=’bucardo’ start –debugfile=1“.

bucardoctl-postgres

Para verificar que todo se encuentre bien se ejecuta “bucardo_ctl -dbuser=’bucardo’ -dbhost=’localhost’ -dbpass=’bucardo’ status“.

bucardoctl-status-postgres

Detengamos por un momento el demonio de bucardo con “bucardo_ctl -dbuser=’bucardo’ -dbhost=’localhost’ -dbpass=’bucardo’ stop” y ejecutemos “bucardo_ctl -dbuser=’bucardo’ -dbhost=’localhost’ -dbpass=’bucardo’ status“, si aparece la linea en rojo que se muestra en la siguiente imagen es que Bucardo no se encuentra en servicio.

bucardo-not-running

Ahora probemos la sincronización con un nodo “down” o sin PostgreSQL en servicio (en este ejemplo colocaremos en “down” al remoto002).

bucardo-remoto

bucardo-wait

Observemos que las bases de datos no se sincronizan bien (verifiquen en la imagen anterior la linea roja). Este problema se soluciono con check_postgres y un script bash que se realizo para la verificación de los nodos que estaban “up” o “down“.

Primero tenemos que instalar check_postgres. Bajamos check_postgres de la página oficial de Bucardo, se descomprime la carpeta, se logea como root en un termina, entramos en la carpeta que descomprimimos, ejecutamos los siguientes comando en consola “perl Makefile.PL“->”make“-> “make install“. Ya en este punto tenemos instalado check_postgres y para probarlo ejecutamos el siguiente comando

check_postgres.pl –action=connection –db=repli -u bucardo –dbpass=bucardo –host=localhost

bucardo-postgres-ok

La comprobación se realizo en la maquina “localhost” con la base de datos “repli”, como resultado se mostro “POSTGRES_CONNECTION OK”.

 Ahora vamos a generar un script bash llamado “script_bucardo.sh”:

#!/bin/bash
# Script generado por Arturo J. Delgado S.
# ajdelgados@gmail.com
patron="POSTGRES_CONNECTION OK";

for i in `seq 1 3`
do
host="remoto00$i"
VERIFICAR=$(check_postgres.pl --action=connection --db=repli -u bucardo --dbpass=bucardo --host=$host)
case $VERIFICAR in *"$patron"*)
ACTIVOS[$i]=$i;
echo "Host $host encontrado.";;
*)
INACTIVOS[$i]=$i;
echo "Host $host NO encontrado" ;;
esac
done

export PGPASSWORD=1
for i in ${ACTIVOS[*]}
do
psql -h localhost -U postgres -d bucardo -c "UPDATE bucardo.sync SET STATUS='active' WHERE name like'%00$i%';"
done

for i in ${INACTIVOS[*]}
do
psql -h localhost -U postgres -d bucardo -c "UPDATE bucardo.sync SET STATUS='inactive' WHERE name like'%00$i%';"
done
unset PGPASSWORD

bucardo_ctl -dbuser='bucardo' -dbhost='localhost' -dbpass='bucardo' restart --debugfile=1

OJO: Los host de las base de datos deben estar en /etc/hosts o en el DNS de la organización, ya que check_postgres no busca por IP sino por nombre.

Se corre el script con “./script_bucardo.sh” o “bash script_bucardo.sh” y se debería verificar la sincronización de las bases de datos:

scrip-bucardo-arturo-delgado

scrip-bucardo-ajdelgado

Con la verificación del estatus de Bucardo, comprobamos que, todos las sincronizaciones que contengan nombre “remoto002” están en off y que las demás bases de datos se encuentran sincronizandose y en línea, ya que, tienen sus PID activos y trabajando.

Ahora colocaremos en “up” al host remoto002 y corremos de nuevo el script “script_bucardo.sh”:

script-bucardo-postgres

Vemos que las bases de datos se sincronizarón exitosamente luego de correr el script, señalando las conexiones que tuvieron problemas y hace cuanto tiempo ocurrió el problema. De igual forma están los PID en todas la sincronizaciones.

Por último se tiene que colocar en el crontab el script para que cada cierto tiempo se realicé la comprobación de las bases de datos. El archivo a modificar es “/etc/crontab” y al final se coloca una línea como en la imagen indica:

bucardo-crontab-postgres

.

Arturo J. Delgado S.

Python – wxPython – PostgreSQL

@ajdelgados

ajdelgados@gmail.com

Referencias:
http://www.pcrednet.com/blog/item/7-replicacion-base-de-datos-postgresql-84-con-bucardo
http://www.scribd.com/doc/124248224/Replicacion-PostgreSQL
http://es.wikipedia.org/wiki/PostgreSQL
http://bucardo.org/
http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling

por leninmhs el 22 julio 2013 04:00