Mysql-zrm backup de la base de datos

mysql-rzm es una serie de herramientas que nos facilitan el hacer backups y que es sencillo de actualizar. Creamos un directorio en /etc/mysql-zrm y creamos dentro un fichero que se llame “mysql-zrm.conf”.

host=”192.168.122.40″
database=”appDB”
password=”passb”
user=”dba-backup”
compress=1
destination=”/mnt/backup”

Ojo, no atacamos al proxy porque mysqlproxy no maneja uno de los protocolos que usa mysql-zrm.

Ahora solo nos queda usar mysql-zrm-schedule para ello, con la aplicación podemos indicar la frecuencia de los backups.

Resumen de los últimos días (II)

Como comente en el post anterior las maquinas MySQL tuvieron que ser reinstaladas, el motivo un problema con la paqueteria de openSolaris y los servicios, calculé que tardaba menos reinstalando y así hice, una vez instalado simplemente instalar SUNWmysql51 y ya tenemos mysql.

Balanceo con mysql-proxy

Primero es activar el demonio en debian, por defecto no viene activado para usarse pues hay que configurarlo previamente, vamos a /etc/default/mysql-proxy donde lo dejamos así:

ENABLED="true"
OPTIONS="--proxy-address=192.168.122.154:3306
--admin-address=:1337
--proxy-backend-addresses=192.168.122.40:3306
--proxy-backend-addresses=192.168.122.41:3306"

Básicamente le decimos que escuche una dirección(192.168.122.154:3306) y que balancee con los configurados con proxy-backend-addresses (usa round-robin). También dejamos abierto escuchando solo localhost el administrador por si necesitamos monitorizar el balanceador.

Con esto ya tenemos balanceados los dos clientes, ahora solo falta que estén sincronizados el uno con el otro y se repliquen los datos. Para ello he seleccionado replicación de solo la base de datos para la aplicación que se llamara appDB, que usará un usuario appUSER. Como hacer replicación master to master hay muchos manuales, pero si indicaré lo clave para esta configuración:

binlog-do-db=appDb
binlog-ignore-db=mysql

auto_increment_increment= 2
auto_increment_offset   = 1

Esa parte de la configuración (en my.cnf) esta en ambos nodos(en el segundo o master 2 es “auto_increment_offset   = 2″ en vez de 1), aquí decimos explícitamente que cuando replique los datos no replique la base d datos mysql y solo appDB. Las dos ultimas es la configuración del auto-incremento, cuando tenemos el auto-incremento en una tabla por cada fila inserta un id numérico secuencial, con esta configuración uno llevara los pares y otros los impares.  Se puede configurar de muchas maneras (que cuente de 10 en 10 y empiece en 5, teniendo la secuencia “5,10,15,…”) para evitar colisiones.

Resumen de maquinas

Con esto mysql ya lo tenemos balanceado y sincronizado, en mi estructura mysql-proxy se encuentra en la misma maquina virtual que el apache proxy, para que se tengo las siguientes:

• glassfish  -> openSolaris con glassfish
• glashfish2 -> OpenSolaris con glassfish
• mysql -> openSolaris con MySQL
• mysql2 -> openSolaris con MySQL
• nas -> Opensolaris con raidz con sistema de ficheros compartido
• proxy -> Debian lenny con mysql-proxy y Apache2

Básicamente esta casi acabado solo falta el firewall y backup, en la próxima entrada explicaré como hacerlo y como voy hacer el test de funcionamiento.

Resumen de los ultimos días

Llevo unos días sin escribir, el motivo principal ha sido las constantes caídas de las maquinas virtuales, mi equipo no es muy potente y tengo el procesador al 100 el 90% del tiempo, las maquinas solaris arrancan una vez si otra no, y el proxy debian murió sin más el sistema de archivos(con su consiguiente kernel panic), lo gracioso es que fui a rescatar las configuraciones en /etc y era exactamente el directorio muerto (enlace muerto). Así que volver empezar, así que en resumen estas son las instalaciones repetidas:

• Los dos opensolaris con mysql(llamados mysql1 y mysql2)
• El Proxy debian
• Re-configurar todo otra vez

Lo gracioso es que siempre se rompias cuando iba a configurar el backup de todas pues el servidor nas ya estaba.

La otra gran parte del tiempo he estado investigando de ipmp (IP MultiPath), la verdad que como tecnología es una cosa grandiosa que debería existir en otros S.O. pero en este caso no podía utilizarlo, para entenderlo voy a explicar en que consiste. IPMP nos permite balancear y tener a prueba de fallos dispositivos de red físicos( y a partir de ahora también virtuales), para ello creamos un grupo del cual tiene una IP que responderá por el grupo y enviando al los dispositivos activos, existen básicamente dos configuraciones uno es “activo-activo” y otro “activo-en espera”, el segundo es el caso que se activa un dispositivo cuando se cae el principal, el primero balancea entre todos los dispositivos.

Bueno ya explicado se podría configurar una maquina virtual (LDom por ejemplo) que escuchara un dispositivo y otra maquina otro, así podríamos disponer de un balanceador a nivel de red si tenemos el mismo servicio en ambas maquinas virtuales. Este esquema no me es posible al tener ya todo virtualizando, el virtualizado del virtualizado es muyyyy lento y si la cosa la tengo ajustada eso podría terminar de apretar más el cinturón.

Así que busque un esquema más clasico, un simple mysql-proxy, que me da más juego pues permite ejecución de scripts lua, también he mirado lo de iptables lo que no me acordaba es que el failover es manual por tanto no sirve(habría que hacer un daemon especial y el tiempo anda justo sorry). También estuve peleandome con el squid pero he optado por otra solución mejor, apache, es más robusto y configurable,  permitiéndome jugar con las direcciones ademas de darme una interfaz web al balanceador. Entonces los cambios son:

• Squid-> Apache
• IPMP->mysql-proxy

Apache tiene una configuración sencilla pero robusta, usa los módulos proxy, proxy_balancer, rewrite y proxy_http. Debido a un cambio en la ultima versión proxy se desgloso en varios módulos (http, ftp, etc…) y tiré horas para saber que tenia que habilitar este, pues los manuales era para versiones anteriores (etch). Así que más tiempo gastado por cambios de versión, pero al final quedo muy bien:

<VirtualHost *:80>
ServerName proxy.abstracctest.com
ServerAlias abtracctest.com

RewriteEngine On
ProxyRequests Off

<Proxy *>
Order deny,allow
Allow from all
</Proxy>

<Location /balancer-manager>
SetHandler balancer-manager
Order Deny,Allow
Deny from all
Allow from 192.168
</Location>

<Proxy balancer://mycluster>
BalancerMember http://192.168.122.50:8080 route=w1
BalancerMember http://192.168.122.51:8080 route=w2
</Proxy>

<Location /clusterjsp>
Order allow,deny
Allow from all
</Location>

ProxyPass /clusterjsp balancer://mycluster/clusterjsp/ stickysession=JSESSIONID

<Location />
Order allow,deny
Allow from all
</Location>
ProxyPass /balancer-manager !
ProxyPass / balancer://mycluster/
</VirtualHost>

Laresolución es sencilla, activamos el proxy (abrimos la puerta con allow all), despues activamos el balanceador y ponemos los miembros de balanceo(aquí hay muchas opciones por si el balancio no es igualitario por ello no hay más) importante el “route=wx” pues es lo que nos sirve para distinguir los servidores a la hora de enrutar (para ello en cada instancia de glassfish en el panel de administración hay que añadir al servidor la opcion  “-DjvmRoute=wx” a la JVM de cada instancia). Tambien destacar el stickysession=JSESSIONID que nos permite tener sticky sessión, en mi ejemplo para probarlo use el ear que viene de demostración cluster con glassfish, en caso de ser PHP y apache seria BLANCEID. Cuando se deploye la aplicación con quercus(php en java) se verá si funciona con una opción u otra.

Mañana a primera hora explico mysql-proxy que ha sido un bonito descubrimiento, ademas de la construcción de un master to master con mysql.