El objetivo de la charla es compartir la experiencia de utilizar la tecnología de:

• Ruby: lenguaje de programación interpretado, reflexivo y orientado a objetos, creado por el japonés Yukihiro “Matz” Matsumoto. Combina una sintaxis inspirada en Python y Perl con características de programación orientada a objetos similares a Smalltalk.
• GTK+ o The GIMP Toolkit: conjunto de bibliotecas multiplataforma para desarrollar interfaces gráficas de usuario (GUI). GTK+ se diseñó para permitir programar con lenguajes como C, C++, C#, Java, Ruby, Perl, PHP o Python.
• MongoDB: sistema de base de datos multiplataforma orientado a documentos, de esquema libre. Se destaca su velocidad y su rico pero sencillo sistema de consulta de los contenidos de la base de datos.

Los esperamos en el edificio de la FACENA ubicado por calle 9 de Julio.

Las inscripciones se realizan del 14 al 18 de febrero en el laboratorio de informática de 14 a 21 hs, o bien por correo electrónico a cursosveranofacena@gmail.com

Para más información de los contenidos de cada curso: http://exa.unne.edu.ar/docs/Informatica-Cursosdeverano2011-contenidos.pdf

Si querés obtener más información sobre los cursos dictados por el staff de IPCorp, podés enviar un email a contacto@ipcorp.com.ar, detallándonos tus consultas.

Para ir preparándonos y estar al tanto de todas estas mejoras, habilitaron en la wiki de PostgreSQL una sección especial donde se explican estos cambios con sus correspondientes ejemplos.

Entre los cambios más importantes tenemos la incorporación de características como:

• Hot Standby: Esta característica nos permite crear una base de datos ‘Standby’. Esto es una segunda instancia de la base de datos: normalmente en un servidor separado a partir del log binario de la primera base de datos, permientiendo que el servidor standby esté disponible para consultas de sólo lectura.
• Streaming Replication: Es un complemento de Hot Standby. Si bien existen varias soluciones de replicación de terceros disponibles para PostgreSQL, ésta nueva versión trae una simple e integrada versión que probablemente será usada como default en la mayoría de las soluciones de High Availability de PostgreSQL.

Más info de las características nuevas y ejemplos en What’s new in PostgreSQL 9.0

Cuando se trabajan con grandes volúmenes de datos restaurar suele ser un trabajo que demanda muchas horas,para resolver esto Postgresql creo una manera sencilla de editar los dumps que lo veremos en este Post.

Como en todo proceso de backup lo primero que existe es el dump de la base, por ejemplo:

#pg_dump  -U postgres -Fc  -f archivo_dump.txt base

Donde  el archivo_dump.txt es el resultante del proceso.

Ahora bien si ese archivo (archivo_dump.txt) contiene tablas de unos miles de registros no hay problema,pero la cosa se complica cuando trabajamos con tablas de millones de registros y a su vez índices asociados a estas;es un hecho que demandara un tiempo importante de restauración. En mi caso en particular con tablas de miles de millones de registros el tiempo aproximado de restauración es de 18 a 24 horas.

Ahora bien como resuelvo que restaurar y que no del archivo: archivo_dump.txt, veamos el siguiente ejemplo. Primero creo un archivo legible para la raza humana de la siguiente manera:

#pg_restore -l archivo_dump.txt  > archivo.lista

El resultado del archivo.lista sera algo como lo siguiente:

; Archive created at Fri Jan 22 22:28:36 2010
; dbname: ipcorp
; TOC Entries: 74
; Compression: 0
; Dump Version: 1.4-0
; Format: CUSTOM
;
;
; Selected TOC Entries:
;
2; 145344 TABLE species postgres
3; 145344 ACL species
4; 145359 TABLE nt_header postgres
5; 145359 ACL nt_header
6; 145402 TABLE species_records postgres
7; 145402 ACL species_records
8; 145416 TABLE ss_old postgres

Las primeras lineas son una serie de referencias acerca del nombre de la base de datos, fecha del dump, mas abajo encontramos números de linea asociados a tablas, funciones e índices; esto ultimo puede ser comentado mediante “;” o también se puede eliminarlos directamente.

Entonces una vez que tenemos nuestro archivo de lista modificado con los elementos que realmente nos interesa, restauramos de la siguiente manera:

# pg_restore -Fc -d base -L archivo.lista < file_dump.txt

Este tipo de error requiere de nuestra intervención ya que tenemos que decidir en qué nodos vamos a descartar los cambios que se produjeron durante el split brain.

En el nodo primario más joven, donde queremos eliminar los cambios, hacemos:

server2~# drbdadm secondary all
server2~# drbdadm disconnect all
server2~# drbdadm -- --discard-my-data connect all

Luego, en el nodo primario con los datos correctos, hacemos:

server1~# drbdadm connect all

Hay que tener mucho cuidado a la hora de hacer esto y si tienen alguna duda les recomiendo hacer un backup. Esto va a evitar que hagan la resincronización en la dirección opuesta.

Tal como ellos dicen, esta no es una versión con nuevas características de relevancia, sino que es una versión que principalmente integra bug-fixes.

La nueva versión puede ser descargada desde el lugar habitual.

Vía javamexico.org

Como en IPCorp nos gusta dormir tranquilos toda la solución va a estar soportada por GNU/Linux y en este ejemplo utilizaremos Ubuntu Server 9.04.

Requisitos

Se necesitan dos servidores o máquinas de similares características. En ambas es necesario tener una partición sin montar y sin formatear para el DRBD.

La capacidad de almacenamiento reservado en estas particiones permitirá almacenar como máximo la capacidad de la partición más chica.

Para el propósito de este instructivo denominaremos a los servidores: server1 y server2. Ambos equipos necesitan ser capaces de resolver los hostnames entre ellos, así que se debemos tener configurado algún servidor de DNS o agregar los nombres de hosts y sus IPs directamente en /etc/hosts. Ambos servidores deberían tener direcciones IP estáticas.

Vamos a suponer que cada servidor tiene un disco de 320Gb de los cuales particionaremos sin LVM, dejando un espacio libre para el volúmen compartido a través de la red. Esto depende del cálculo del tamaño estimado de la base de datos que vamos a replicar.

Los clientes de la base de datos se comunicarán a la IP Virtual 10.0.0.1, además vamos a necesitar los siguientes paquetes instalados, necesarios para poder configurar correctamente el servidor:

sudo aptitude install hearbeat drbd8-utils build-essential libreadline5-dev zlib1g-dev

Configuración de DRBD

Primero vamos a guardar una copia del archivo de configuración original:

mv /etc/drbd.conf /etc/drbd_backup.conf

Editamos el archivo /etc/drbd.conf y reemplazamos su contenido por:

global {usage-count no;}
common { syncer {rate 100M;} }
resource pg {
        protocol C;
        startup {
                wfc-timeout 15;
                degr-wfc-timeout 60;
        }
        on server1 {
                device /dev/drbd0;
                disk /dev/sda3;
                address 10.0.0.2:7788;
                meta-disk internal;
        }
        on server2 {
                device /dev/drbd0;
                disk /dev/sda3;
                address 10.0.0.3:7788;
                meta-disk internal;
        }
}

Ahora copiamos este archivo en el servidor secundario e iniciamos el servicio en ambas máquinas. Posteriormente creamos el recurso compartido en ambas máquinas:

sudo /etc/init.d/drbd start
sudo drbdadm create-md pg

Dónde “pg” es el mismo nombre que le pusimos al tag “resource” en el archivo de configuración del “drbd”.

Ahora es necesario establecer el nodo primario del cluster. Para este ejemplo elegimos el server1 por lo que en ésta máquina ejecutamos el siguiente comando y luego damos formato a la partición compartida:

sudo drbdadm -- --overwrite-data-of-peer primary all
sudo mke2fs -j /dev/drbd0

Con el siguiente comando podemos ver el estado actual de la sincronización de los recursos del cluster:

cat /proc/drbd

Si todo salió bien, vamos a ver algo parecido a esto:

version: 8.3.0 (api:88/proto:86-89)
GIT-hash: 9ba8b93e24d842f0dd3fb1f9b90e8348ddb95829 build by ivoks@ubuntu, 2009-01-17 07:49:56
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r---
    ns:82020 nr:1188 dw:82916 dr:5438 al:27 bm:18 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

Instalación de la base de datos PostgreSQL

La instalación de PostgreSQL será a través de la compilación del código fuente porque debemos hacer algunas modificaciones al programa pg_ctl para que todo funcione correctamente.

Luego de bajar los fuentes del PostgreSQL descomprimimos, y modificamos el código de la aplicación pg_ctl, más precisamente buscamos la leyenda “no server runnig” dentro del código y reemplazamos la palabra “runnig” por cualquier otra.

Esto tiene una explicación y es que Heartbeat verifica si un servicio está corriendo o no buscando la cadena “running” u “ok” al pedir su status, entonces cuando heartbeat le pregunta a PostgreSQL si está ejecutándose correctamente él responde “no server running” y heartbeat supone que todo está bien aunque realmente no sea así.

El archivo fuente de esta aplicación esta en postgresql-8.X.XX/src/bin/pg_ctl/ y se llama pg_ctl.c.

Un vez hecho este pequeño parche sólo nos falta compilarlo e instalarlo:

cd postgresql-8.X.XX
./configure
make
make install

Siguiendo el procedimiento regular de instalación, el próximo paso necesario es crear el usuario postgres. Agregamos la ruta /usr/local/pgsql/bin al path del sistema, y debemos crear la carpeta donde se van a alojar los datos y darle los permisos de esa carpeta al usuario postgres:

adduser postgres

Todos los pasos anteriores debemos hacerlo en ambos nodos, los que siguen sólo en el nodo principal:

mkdir /opt/postgresql/data
chown postgres.postgres -R /opt/postgresql/data

La ruta “/opt/postgresql/data” es el lugar donde quiero alojar los datos y queda a criterio de cada uno. Para inicializar la base de datos es necesario estar logueado como el usuario postgres y hacer:

initdb -D /opt/postgresql/data

Configuración de Heartbeat

En el nodo primario copiamos los archivos de configuración de ejemplo o simplemente creamos archivos nuevos:

cp /usr/share/doc/heartbeat/authkeys /etc/ha.d/
cp /usr/share/doc/heartbeat/ha.cf.gz /etc/ha.d/
cp /usr/share/doc/heartbeat/haresources.gz /etc/ha.d/
gzip -d ha.cf.gz
gzip -d haresources.gz

Editamos el archivo authkeys y ponemos:

auth 2
2 sha1 mipasswordsecreta

“mipasswordsecreta” es la password para que los nodos se puedan comunicar con cierto nivel de seguridad. Ahora es necesario darle permisos sólo a root por cuestiones de seguridad:

chmod 600 /etc/ha.d/authkeys

y en el archivo ha.cf comentamos todo y agregamos:

logfile /var/log/ha-log
logfacility local0
keepalive 2 #cada cuanto segundos verifica que este vivo
deadtime 30 #cuantos segundos espera hasta que lo considera muerto
initdead 120 # este valor es para cuando no bootean los dos juntos, en ese caso espera 120 segundos para empezar el proceso
bcast eth0 # placa de red por la que verifica el estado de los otros nodos
udpport 694 # puerto UDP por el que se va a enviar el latido
auto_failback on
node server1 # nodo que participa
node server2 # nodo que participa

y por último debemos modificar el archivo haresources. Ahí declaramos los servicios que queremos monitorear y que deben estar siempre disponibles. El equipo server1 es el servidor principal y los otros van a verificar que no caiga. En cuanto caiga una máquina, la otra tomará el control levantando los servicios monitoreados y tomando la IP Virtual. Dentro de haresources ingresamos:

server1 IPaddr::10.0.0.1 drbddisk::pg Filesystem::/dev/drbd0::/opt/postgresql::ext3::defaults postgresql

Les voy a explicar que significa cada parte de este archivo. En primer lugar definimos cuál va a ser el nodo principal en este caso server1. IPaddr::10.0.0.1 es el script que asigna la IP virtual que tendrá el cluster y el cual será el punto de acceso, con drbddisk::pg le decimos que recurso DRBD queremos brindar, luego con Filesystem::/dev/drbd0::/opt/postgresql::ext3::defaults montamos el dispositivo virtual drbd0 en la carpeta /opt/postgresql y por último decimos que arranque postgresql.

En indispensable copiar el archivo de arranque de PostgreSQL a /etc/ha.d/resources.d y modificar la variable de entorno PGDATA para que apunte a la carpeta /opt/postgresql/data que es el lugar donde van a residir las bases de datos:

cp postgresql-8.x.xx/contrib/start-scripts/linux /etc/ha.d/resources.d/postgresql
chmod +x /etc/ha.d/resources.d/postgresql

Luego copiamos los archivos de configuración a todos los nodos:

scp -r /etc/ha.d/ root@server2:/etc/

Ahora es cuestión de levantar los servicios en todos los nodos:

sudo /etc/init.d/heartbeat start

Comprobación

Ya estamos en condiciones de levantar el motor de base de datos mediante la siguiente sentencia:

/etc/ha.d/resources.d/postgresql start

Y sólo resta crear la base de datos y restaurar desde un backup anterior o empezar a crear las tablas, índices, vistas, etc., desde cero.

Luego para probar que se estén replicando correctamente los datos, en el nodo secundario ejecutamos el comando “watch cat /proc/drbd” mientras que en el nodo principal bajamos el servicio de hearbeat. Antes de bajar el servicio en el nodo secundario deberíamos tener la siguiente salida:

version: 8.3.0 (api:88/proto:86-89)
GIT-hash: 9ba8b93e24d842f0dd3fb1f9b90e8348ddb95829 build by ivoks@ubuntu, 2009-01-17 07:49:56
0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r---
    ns:1188 nr:82020 dw:83208 dr:3313 al:15 bm:17 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

Luego bajamos a heartbeat:

/etc/init.d/hearbeat stop

Y deberíamos ver lo siguiente:

version: 8.3.0 (api:88/proto:86-89)
GIT-hash: 9ba8b93e24d842f0dd3fb1f9b90e8348ddb95829 build by ivoks@ubuntu, 2009-01-17 07:49:56
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r---
    ns:1328 nr:82280 dw:83608 dr:3542 al:15 bm:17 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

El agregado de nuevos nodos al cluster diría que es casi trivial.

Tomemos un ejemplo simplificado de la vida real, supongamos que tenemos una tabla de afiliados de una obra social. En esta tabla tenemos a los titulares y a los familiares de los titulares, los cuales acceden a los mismos servicios que los titulares. Si suponemos que cada titular tiene en promedio 2 o 3 familiares asociados y si nuestras búsquedas se realizan principalmente sobre los titulares, probablemente no necesitemos indexar a los familiares.

Asumimos que tenemos la siguiente tabla:

CREATE TABLE afiliados (
    id SERIAL PRIMARY KEY,
    nombre VARCHAR(60),
    tipo_afiliado VARCHAR(20),
    monto_cuota REAL,
    monto_deuda REAL,
    .....
);

Siguiendo con el ejemplo para crear un índice solo para los afiliados titulares, usamos la siguientes sentencia

CREATE INDEX idx_afiliados_titulares
ON afiliados(tipo_afiliado)
WHERE tipo_afiliado = 'Titular';

Una típica consulta que utilizará este índice es:

SELECT nombre FROM afiliados WHERE tipo_afiliado = 'Titular';

Ahora veamos otro ejemplo, si habitualmente consultamos aquellos afiliados que pagan una cuota superior a $50 para brindarle promociones o precios diferenciales podemos crear el siguiente índice parcial:

CREATE INDEX idx_afiliados_buenos_afiliados
ON afiliados(monto_couta)
WHERE monto_couta >= 50;

La siguiente es una consulta que utilizará el índice parcial:

SELECT nombre FROM afiliados WHERE monto_cuota = 55;

Para más información y ejemplos podemos ver la documentación oficial de PostgreSQL.

Hoy les voy a presentar un conjunto de herramientas y librerías que permiten la interacción con bases de datos MS Access desde Linux, estas herramientas están agrupadas dentro del proyecto MDB Tools.

Requisitos

Para este pequeño tutorial vamos a utilizar un base de datos de ejemplo: Music Collection Database disponible para descargarse en el sitio de Microsoft, este archivo viene en formato .cab así que vamos a instalar una aplicación para poder descomprimirlo.

sudo aptitude install cabextract
cabextract 01018629.cab

Luego instalamos el paquete mdbtools, el cual consta también con una herramienta gráfica lo suficientemente amigable como para que no necesite un post dedicado a la GUI, para este ejemplo nos vamos a centrar en las herramientas de líneas de comando, primero instalamos mdbtools:

sudo aptitude install mdbtools

Visualizar las tablas de una base de datos

Para listar todas las tablas de una base de datos utilizamos el comando mbd-tables:

mdb-tables 01018629.mdb
Music Categories Recording Artists Recordings Switchboard Items Tracks

Es una práctica común cuando se diseñan bases de datos en MS Access es la utilización de nombres de tablas con espacios intermedios, mdb-tables nos permite determinar un separador al listar las tablas para ver bien los nombres de las tablas:

>mdb-tables -d '|' 01018629.mdb
Music Categories|Recording Artists|Recordings|Switchboard Items|Tracks|

Obteniendo el DDL de la base de datos

Para obtener el DDL (Data Definition Language) de una tabla o de toda la base de datos podemos utilizar mdb-schema, esto será de suma utilidad si queremos migrar la base de datos a otro entorno como MySQL o PostgreSQL.

mdb-schema -T 'Recording Artists' 01018629.mdb
DROP TABLE Recording Artists;
CREATE TABLE Recording Artists
(
RecordingArtistID	 Long Integer,
RecordingArtistName	 Text (100),
Photograph	 OLE (255),
Birthdate	 DateTime (Short),
Birthplace	 Text (100),
DateofDeath	 DateTime (Short),
Notes	 Memo/Hyperlink (255)
);

Exportando los datos

mbd-export nos sirve para exportar a formato CSV los datos de una tabla:

mdb-export 01018629.mdb 'Recording Artists'
RecordingArtistID,RecordingArtistName,Photograph,Birthdate,Birthplace,DateofDeath,Notes
1,"Karen Archer",,"","Greenville, SC","",""
2,"Deborah Poe",,"","New Orleans, LA","",""
3,"George Jiang",,"","Traveler's Rest, SC","",""
4,"Stefan Delmarco",,"03/15/65 00:00:00","Ann Arbor, MI","",""

Si ejecutamos mbd-export sin parámetros podemos ver más opciones de exportación.

Seleccionando y manipulando datos de la base de datos

Si lo que necesitamos es filtrar datos de la base de datos con mdb-sql podremos realizar consultas en SQL a la base de datos de manera dinámica a través de una consola. La consulta luego de ingresar la sentencia GO

mdb-sql 01018629.mdb
1 => select RecordingArtistName from "Recording Artists" where Birthplace like 'New%'
2 => go
+----------------------------------+
|RecordingArtistName              |
+----------------------------------+
|Deborah Poe                       |
+----------------------------------+
1 Row retrieved
1 =>