Categories
Bigdata General Guide In detail

Como configurar una replicación Master-Slave en MySQL Percona 5.5

image
En MySQL (no Percona) si queremos realizar un servidor de replicación (Slave) nos encontramos que antes de realizar el backup, debemos bloquear la escritura en las tablas, apuntar la posición del log binario, realizar el backup y habilitar nuevamente la escritura en las tablas. Esto se tiene que realizar así, porque si durante el proceso de backup se escribe algo en una tabla, la relación entre la posición del log binario que hemos apuntado y el contenido del backup no será correcto y si usáramos ese backup para realizar la replicación, la base de datos slave seria diferente a la base de datos master. El problema de lo que acabo de citar, es que si queremos hacer esto con una base de datos de una web en producción, deberemos poner la web en mantenimiento y según el tamaño de la base de datos pueden llegar a ser horas en las que la web no estará operativa y hay situaciones en las que no podemos permitirnos ese lujo (perdidas económicas). Para evitar pasar por este problema, si disponemos de un servidor de bases de datos con Percona MySQL 5.5, podemos realizar esta tarea de forma muy sencilla y sin necesidad de bloquear la escritura en las tablas en el proceso de backup, gracias a una herramienta de Percona llamada ‘innobackupex’, que lo que hace es que durante el proceso de backup cree un fichero independiente con todas las transacciones que se realizan durante el proceso, y una vez termina, integra en el backup esas transacciones y finalmente nos genera la posición del log binario correcta. Para realizar este proceso, simplemente deberemos seguir los siguiente pasos:
DATOS INICIALES QUE NECESITAMOS (IP O HOSTNAME DE AMBOS SERVIDORES)

MASTER_HOST='m.m.m.m'
SLAVE_HOST='s.s.s.s'

PASOS A REALIZAR EN EL SERVIDOR BD MASTER
1. Accedemos vía SSH y nos cercioramos de que la hora del servidor es la correcta
2. Instalamos el paquete ‘percona-xtrabackup’ (forma parte del mismo repositorio de donde hemos descargado Percona MySQL) que nos proporcionará la aplicación “innobackupex” que usaremos para realizar el proceso:

yum install percona-xtrabackup

3. Creamos el usuario en Percona MySQL, que realizará la réplica de la BD:

mysql -uroot -p******
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl_user_name@'s.s.s.s' IDENTIFIED BY 'pass_repl_user';
mysql> exit

4. Nos anotamos los valores que hemos usado en la creación del usuario:

MASTER_USER='repl_user_name'
MASTER_PASSWORD='pass_repl_user'

5. Editamos el fichero de configuración de Percona MySQL (my.cnf) con nuestro editor favorito (en este caso vim):

vim /etc/my.cnf

6. Añadimos los siguientes valores (o modificamos las variables si ya existen):

log-bin=mysql-bin
server_id=1

7. Reiniciamos el servicio de Percona MySQL, para aplicar los cambios que hemos realizado en el fichero de configuración.

/etc/init.d/mysql restart

PASOS A REALIZAR EN EL SERVIDOR BD SLAVE
1. Accedemos vía SSH y nos cercioramos de que la hora del servidor es la misma que la del servidor master
2. Instalamos el paquete ‘percona-xtrabackup’:

yum install percona-xtrabackup

3. Editamos el fichero de configuración de Percona MySQL (my.cnf) con nuestro editor favorito (en este caso vim):

vim /etc/my.cnf

4. Añadimos los siguientes valores (o modificamos las variables si ya existen):

server_id=2
relay_log=mysql-relay-bin
log_slave_updates=1
read_only=1

5. Reiniciamos el servicio de Percona MySQL, para aplicar los cambios que hemos realizado en el fichero de configuración:

/etc/init.d/mysql restart

PASOS A REALIZAR EN EL SERVIDOR BD MASTER
1. Realizamos backup de todas las bases de datos con la aplicación innobackupex al directorio “backup” que hemos creado previamente:

innobackupex --defaults-file=/etc/my.cnf --user=root --password=password_del_usuario_root --export /root/backup/

2. Al terminar el backup, veremos el siguinte texto, del que anotaremos los valores de MASTER_LOG_FILE y MASTER_LOG_POS:

'mysql-bin.000000', position 000
MASTER_LOG_FILE='mysql-bin.00000'
MASTER_LOG_POS=000

3. Comprimimos el directorio de backup que se ha creado (nombre del directorio con la fecha y hora) en formato tar.gz:

tar czvf 2014-xxxxxxx.tar.gz /root/backup/2014-xxxxxxx

4. Eliminamos el directorio que ya hemos comprimido (para liberar espacio):

rm -Rf /root/backup/2014-xxxxxxx/

5. Copiamos por SSH el backup comprimido al servidor BD Slave (a un directorio previamente creado):

scp 2014-xxx.tar.gz root@s.s.s.s:/root/backup/.

PASOS A REALIZAR EN EL SERVIDOR BD SLAVE
1. Accedemos al directorio donde hemos copiado el backup comprimido

cd /root/backups/

2. Descomprimimos el backup:

tar xzvf 2014-xxx.tar.gz

3. Realizamos el paso previo a la restauración del backup. Especificamos la memoria que destinaremos al proceso:

innobackupex --use-memory=1G --apply-log /root/backup/2014-xxx

4. Paramos el servicio de Percona MySQL:

/etc/init.d/mysql stop

5. Eliminamos todo el contenido del directorio de mysql:

rm -Rf /var/lib/mysql/*

6. Restauramos el backup:

innobackupex --copy-back /root/backup/2014-xxx

7. Restablecemos los permisos al directorio de Percona MySQL:

chown -R mysql:mysql /var/lib/mysql

8. Reiniciamos el servicio de Percona MySQL, para que cargue los datos restaurados con el backup

/etc/init.d/mysql start

9. Configuramos los datos del servidor master, con los datos previamente recogidos (el valor de MASTER_LOG_POS va sin comillas):

mysql -uroot -p******
mysql> CHANGE MASTER TO MASTER_HOST='m.m.m.m', MASTER_USER='repl_user_name', MASTER_PASSWORD='pass_repl_user', MASTER_LOG_FILE='mysql-bin.000', MASTER_LOG_POS=000;

10. Comenzamos la replicación:

mysql> START SLAVE;

11. Vemos el estado de la réplica, y nos fijamos en el valor de “Second Behind Master”. Cuando llegue este valor a cero, la replicación estará finalizada:

mysql> SHOW SLAVE STATUS\G;
Categories
General In detail

Cloud Simulators.. ¿Por qué y para qué?

cloud simulator

¿Desarrollo de aplicaciones sobre la nube o incluso optimización de esta sin un proceso de “testing” a la altura? La utilización de bancos de pruebas reales sin duda limita los experimentos y hace que la reproducción de resultados sea para este tipo de entornos un tanto difícil.

Una alternativa adecuada es usar herramientas de simulación, ya que abren la posibilidad de evaluar la hipótesis antes del desarrollo de software en un entorno donde se pueden reproducir tests sin impacto en el bolsillo. Como bien conocemos en la computación en la nube, el acceso a la infraestructura incurre en pagos a golpe de tarjeta, los enfoques basados ​​en la simulación ofrecen beneficios significativos, ya que permite a los clientes probar sus servicios/aplicaciones en un entorno repetible y controlable cerca de un coste que tiende a 0. Es decir, que si buscamos ajustar aspectos de rendimiento y evitar futuros cuellos de botella antes de implementarlos en nubes públicas reales nos pueden ser de mucha utilidad.

Por la parte del proveedor, los entornos de simulación permiten la evaluación de diferentes tipos de escenarios de “alquiler” de recursos con diversas configuraciones de cargas de trabajo y a partir de aquí llegar incluso a ajustar o establecer sus tarifas. En ausencia de este tipo de plataformas de simulación, los clientes y los proveedores cloud tienen que confiar en suposiciones teóricas, dónde los enfoques de prueba/error pueden conducir a la prestación de un servicio ineficiente y en consecuencia impacto sobre la propia generación de ingresos.

Resumiendo, tests de integración parecidos al entorno productivo permiten:

  1. Validar rápidamente suposiciones.
  2. Trabajar con volumenes de recursos que no podemos conseguir.
  3. Ahorrar tiempo.
  4. [alguna más que seguro estás pensando..]

Algunos ejemplos de “frameworks” disponibles:
cloudbuslogo-v5aCloudSim http://www.cloudbus.org/cloudsim/  – Univ. of Melbourne

  • Dedicado a entornos cloud (IaaS & PaaS)
  • Java
  • Se está situando como estándar en su campo



simgrid_logo_2011
SimGrid http://simgrid.gforge.inria.fr/ –  Inria / Univ. Lorraine

  • Establecido en al comunidad científica (muy versátil)
  • C y varios bindings (Java incluido)
  • Reorientado hacia cloud por la ANR via el proyecto Songs





greencloud
GreenCloud http://greencloud.gforge.uni.lu/ – Univ. Luxembourg

  • Orientado a la mejora de la eficiencia energética.
  • Simulación de entornos de virtualización y clouds privados.
  • Altamente enfocado a networking.

Y hasta aquí el repaso del ecosistema de herramientas de referencia, como es habitual cada opción con sus ventajas e inconvenientes dónde su aplicación vendrá determinada por cada caso.
A modo de conclusiones:

  • Los simuladores sin duda son de mucha utilidad frente a la validación y testeo de algoritmos de  optimización/automatización de procesos y del manejo del ciclo de vida de recursos en cloud. Un verdadero reto dónde las aplicaciones (lo de arriba) y la infraestructura (lo de abajo) aumentaran su eficiencia debido a alinearse con los primeros y en consecuencia hacer un mejor uso de los segundos.
  • El uso de simuladores permite a investigadores y desarrolladores de la industria concentrarse en cuestiones de diseño de sistemas específicos que quieren investigar, sin estar preocupados por los detalles relacionados con la infraestructura y servicios base que ofrece la nube.

Para finalizar y como recomendación no olvides que en ocasiones la simulación se puede alejar de la realidad si no se contemplan los tiempos,  (provisonar 50k MV’s via simulador (10 seg) sobre tu cloud provider favorito un poco más… 😉