Bucardo, sincronización asíncrona en PostgreSQL

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«

(más…)

Continuar leyendoBucardo, sincronización asíncrona en PostgreSQL

🐘👩🏼‍💻 PostgreSQL & DBlink, conexión de dos base de datos

Aprende a realizar una conexión local o remota entre dos bases de datos de PostgreSQL usando el modulo DBlink, con ejemplo practico y rápido.

En algún momento trabajando con bases de datos, nos vamos a encontrar con la necesidad de cruzar información contenida en una o más tablas que están en diferentes bases de datos, las cuales pueden estar instaladas localmente o en otro servidor.

 

¿Que hacemos en este caso?

Para no tener que copiar , restaurar o duplicar esta(s) tabla(s) en otra base de datos, POSTGRESQL ofrece un objeto llamado Dblink, el cual es un conjunto de funciones que permite realizar conexiones entre bases de datos que estén instaladas en un servidor local o remoto.

 

¿Como hago para instalar Dblink?

Primeramente debemos tener instalado PostgreSQL, y suponiendo que trabajamos en linux, procedemos a instalar el paquete contrib de la versión de Postgres que estemos utilizando (en mi caso utilizo la versión 9.0), mediante el siguiente comando:

(más…)

Continuar leyendo🐘👩🏼‍💻 PostgreSQL & DBlink, conexión de dos base de datos
trigger y función PL/PGSQL para Insert en PostgreSQL
trigger y función PL/PGSQL para Insert en PostgreSQL

Crear trigger y función PL/PGSQL que genere código compuesto al realizar Insert en PostgreSQL

En esta entrada aprenderemos a crear un trigger y función PL/PGSQL para los Insert que se ejecuten en PostgreSQL,

Haremos un trigger que en cada operación de inserción en una tabla especifica de nuestra base de datos PostgreSQL ejecute una función hecha en PL/PGSQL, la cual generara é insertara en un campo de nuestra tabla seleccionada un código compuesto por el año actual, el valor de un campo (siglas de un estado) en una tabla relacionada y un incremental que debe ser único para los parámetros previos.

Es decir el código debe ser como 2015AM0006 2015SU0001 2015AM0007 y se debe comportar de tal manera que cada año se inicialice el valor incremental y dicho valor se incrementa en base al año y siglas de estado.

(más…)

Continuar leyendoCrear trigger y función PL/PGSQL que genere código compuesto al realizar Insert en PostgreSQL
The main user interface, showing the properties of a function.
The main user interface, showing the properties of a function.

pgAdmin 4 – El elefante se acerca a la línea de meta

Esta entrada es una traducción libre autorizada de la entrada pgAdmin 4 – The elephant nears the finish line publicada originalmente en el blog Dave’s Postgres Blog  – Postgres related musings and ramblings de Dave Page

Como saben, muchos de nosotros en el equipo de pgAdmin hemos estado trabajando duro en pgAdmin 4 desde hace algún tiempo. pgAdmin 4 es la reescritura completa de pgAdmin (la cuarta, como pueden suponer), la versión anterior ha llegado al final de su vida de mantenimiento después de 14 años de desarrollo.

El trabajo en el proyecto inició lentamente, al menos hace dos años, sin embargo el equipo de EnterpriseDB ha incrementado el ritmo de desarrollo en los últimos meses. Justo ahora, nos estamos acercando a la versión alfa que esperamos este lista al rededor de unas semanas.

 

Arquitectura

Esta nueva aplicación está diseñada para funcionar tanto en el escritorio como en un servidor web. Esta escrito en Python usando el Framework Flask para el backend, y Javascript / jQuery / Backbone para el FrontEnd, que puede fácilmente ser implementada como una aplicación WSGI para múltiples usuarios en prácticamente cualquier entorno de red. Una pequeña aplicación  permite que se ejecute como una aplicación de escritorio – este es un ejecutable de Qt que incorpora un intérprete de Python y un navegador web, junto con la aplicación principal en un solo paquete que puede ser instalado en un ordenador junto a versiones anteriores de pgAdmin.

(más…)

Continuar leyendopgAdmin 4 – El elefante se acerca a la línea de meta
Importar archivo CSV en MariaDB / MySQL
load data local infile mysql mariadb

Importar archivo CSV en MariaDB / MySQL usando LOAD DATA INFILE

En esta entrada veremos como importar archivo CSV en MariaDB / MySQL desde un  archivo .CSV usando LOAD DATA INFILE el cual es el mecanismo que provee para esta tarea el manejador de bases de datos.

Use MariaDB v10.0.20 sobre Debian Jesse, sin embargo funciona exactamente igual en MySQL. En líneas generales la necesidad era cargar noticias que vienen de otro manejador de bases de datos (PostgreSQL) hacia MariaDB donde esta un modelo de datos usado por wordpress, lo que necesitamos es llenar la tabla de notas de wordpress (wp_posts) con el contenido del archivo CSV. (más…)

Continuar leyendoImportar archivo CSV en MariaDB / MySQL usando LOAD DATA INFILE

Breve reseña de Bases de Datos en Debian Jessie

PostgreSQL

Como agradable sorpresa encontramos como única opción disponible en los repositorios la versión 9.4 la cual es la ultima y mas reciente versión disponible de PostgreSQL.

Comunicado de Prensa para PostgreSQL 9.4: http://www.postgresql.org/about/press/presskit94/es/

pgAdmin el cliente gráfico mas usado de PostgreSQL también lo encontramos en la ultima versión disponible para el proyecto (1.20).

phpPgAdmin también lo tenemos disponible con la ultima versión estable del proyecto

(más…)

Continuar leyendoBreve reseña de Bases de Datos en Debian Jessie