El próximo sábado 8 de noviembre a las 19:30 estaré hablando sobre MySQL Fabric en la PyConES 2014 (la versión española de la PyCon), la reunión anual de programadores y entusiastas de Python en España.
Aunque no me auto-denomino como programador, una gran parte de mi tiempo cono consultor de MySQL require implementar procedimientos automáticos (backups, comprobaciones de salud, gestión de AWS, …) y para ello utilizo principalmente una combinación de Python y Bash.

En mi charla, que he titulado “MySQL Fabric, a High Availability solution for Connector/Python” explicaré cómo montar y configurar un conjunto de servidores MySQL y …

El funcionamiento de un ALTER TABLE es sencillo:

1- MySQL bloquea la tabla que se desea modificar.
2- Crea una nueva tabla vacia con la nueva estructura.
3- Copia los datos de la antigua a la nueva.
4- Borra la antigua.
5- Renombra la nueva tabla con el nombre original.

Esto en tablas pequeñas puede ser un proceso de segundos o minutos. En tablas muy grandes, podemos estar hablando de horas. Horas en las cuales las consultas a dicha tabla estarán bloqueadas y las conexiones y peticiones se encolarán. Por lo tanto, hacer un ALTER TABLE en producción puede tener consecuencias bastante desastrosas.

Si tenemos replicación master-slave, podemos hacer el ALTER TABLE por fases. Primero lo hacemos en el esclavo. Cuando termine, promocionamos el esclavo a maestro y el maestro a esclavo. Y vuelta a lanzar el ALTER TABLE en el antiguo maestro (ahora esclavo).

¿Y si no tenemos …

Muchas veces se montan replicaciones Master-Master con el fin de "balancear y escalar escrituras". En MySQL el concepto de escalabilidad existe, pero únicamente en lecturas. En cambio, con las escrituras esto no es posible a no ser que usemos engines especiales como SpiderSQL o modificaciones de replicación como Galera. Las razones por las que no se recomienda usar Master-Master para balanceo de carga son las siguientes:

• El balanceo de carga es falso, por el simple hecho de tener una replicación master-master. Si lanzas una Update al HostA que tarda 5 minutos en terminar, cuando la query se replique al HostB este tardará también 5 minutos. Aquí no hay balanceo de carga, da igual a que host lances el INSERT o el UPDATE, todos tendrán que ejecutarlo y dedicar recursos. Por lo …

MySQL Cluster es una base de datos que como su nombre indica funciona en un Cluster de servidores. Mucha gente confunde terminos y define un conjunto de servidores con replicación como un MySQL Cluster, pero hay que tener en cuenta que son dos conceptos totalmente distintos. MySQL Cluster nos ofrece:

• Alta disponibilidad
• Escalabilidad
• Failover automático
• Redundancia
• Alto throughput

La versión actual es la 7.1 y puede descargarse de http://www.mysql.com/products/database/cluster/

Componentes

Un Cluster MySQL está compuesto por los siguientes componentes:

Manager (ndb_mgmd): es un servicio encargado de poner en marcha el cluster, conectar nuevos servidores y ejecutar distintos comandos de administración mediante el CLI ndb_mgm. Una vez que …

Aquí os pongo unas nuevas transparencias de un curso que he dado recientemente. Abarca gran cantidad de temas relacionados con la administración de nuestra base de datos favorita :)

• Instalación
• Engines
• Optimización de consultas
• Optimización de tablas
• Optimización del servicio
• Usuarios y permisos
• Replicación
• Alta disponibilidad
• Backup
• etc. :)

Espero que os guste y os sea de utilidad. Cualquier sugerencia o crítica es bienvenida. Si hay algún fallo comentádmelo para solucionarlo lo antes posible.

¡Gracias a todos!

Mysql AdministracionView more presentations from …

Os presento las transparencias del curso de Replicación de MySQL que acabo de terminar y subir a Slideshare.

Contenido:

Maestro/Esclavo Maestro/Maestro Circular MMM MySQL Proxy

Replicación MysqlView more documents from Miguel Angel Nieto Salazar.

Montar un sistema de replicación es sencillo y rápido. Nos ofrece muchas ventajas, siempre y cuando funcione correctamente y no fallen los equipos. Ahora imagina con las siguientes características:

• Dos equipos en maestro-maestro.
• 50 equipos esclavos, 25 colgando del maestro 1 y otros 25 del maestro 2.

Ahora imagina que el maestro 1 se cae. Bien, recuerda que todo esto está en tu imaginación, no te intentes suicidar, aunque he de admitir que sería la solución mas razonable. Con la caida de ese Master, 25 equipos esclavos se han quedado desincronizados. Tenemos usuarios que ni pueden escribir y lo que leen está posiblemente anticuado. Cuando pones de nuevo el servidor en marcha compruebas que no se replican correctamente ya que alguna transacción quedó a medías. Tienes 26 ordenadores desincronizados y tienes que entrar uno a uno parando el proceso Slave, ejecutando el change_master, arranco de …