Éste post me parece muy importante para poder entender como funcionan y hacer grandes sistemas pensados para escalar, sea por tráfico, por multi-sitio, multi-país, y más… todos estos sistemas distribuidos presentan la misma particularidad, y en el año 2000 un señor llamado Eric Brewer, pudo definir tres importantes propiedades y desarrollo un teorema. El se dio cuenta que mientras más aplicaciones basadas en la WEB existan, menos debemos preocuparnos por la consistencia de los datos, si queremos alta disponibilidad de nuestras aplicaciones entonces no podemos garantizar la consistencia de los datos.

El teorema CAP, también llamado formalmente Teorema de Brewer, dice que un sistema de datos distribuido pude asegurar dos de estas tres propiedades: Consistencia, Disponibilidad y Tolerancia al particionado. Bien, que significa cada una:

Hace un tiempo escribí un post similar, la diferencia con éste es que los datos a actualizar vienen de un archivo de texto. Hay muchas formas de hacerlo, para variar quise buscar una alternativa rápida y eficaz para evitar escribir un nuevo script, y se me ocurrió usar los comandos de linux, la verdad que resulto muy bien, aquí les dejo un ejemplo:

cat tokens.csv \
| \
awk -F ',' '{ print "UPDATE users SET token = \"" $2 "\" WHERE token IS NULL AND email = \"" $1 "\";"; system("sleep 0.1");}' \
| \
mysql --login-path=foo \
--safe-updates \
--batch \
--silent \
--database=foo

Explico un poco, básicamente se lee el archivo con cat, luego se crea la sentencia UPDATE usando el awk, por cada update hacemos una pausa de 100 milisegundo para no saturar, y se lo …

La replicación de datos con slaves es algo muy fácil de configurar y aporta muchos beneficios, pero aveces trae sus grandes problemas si no tenemos en cuenta algunos aspectos de configuración, hardware y red entre otras cosas, vamos a comentar un buen grupo de ellos y ayudarte a saber donde puede estar el problema, se que es muy largo el POST, hay mucho que cubrir, pero tratare de dar la idea.

Ventajas de usar Slaves

• Divide las escrituras en un master y lecturas en los slaves para distribuir las cargas de trabajo. Esto no lo hace MySQL de forma transparente, la aplicación debe saber que sentencias van al master y al slave.
• Los Slaves que son los servidores de lectura, se pueden optimizar para hacer minería de datos o procesos de reportes.
• Se puede usar un slave para remplazar el master en caso de algún desastre como una medida de prevención.
• Como respaldo usando el retraso en la …

Los registros huérfanos son aquellos que se almacenan en un modelo relacional padre-hijo, los registros padres hacen referencia a filas primarias, y los registros hijos hacen referencia a filas secundarías, esto puede pasar por varias razones en una DDBB, básicamente sino existe claves foráneas definidas, o alguien desactivo de forma momentánea el check foreign_key_checks, y para mantener la integridad de los datos debemos de vez en cuando identificar estos registros huérfanos, podríamos eliminarlos o asignarlos a un padre de forma provisional. Yo opto más por lo segundo, conservar los datos es nuestra prioridad.

Los registros huérfanos pueden tener un Foreign Key igual a NULL o tener un ID de un registro primario que no exista, pero debemos tener bastante cuidado con el NULL, ya que puede …

El bloqueo es la esencia de cualquier manejador de bases de datos relacional (RDBMS), para el caso de MySQL es importante destacar que el engine InnoDB lo gestiona de forma óptima, hasta la fecha no hay otro que lo haga mejor.

No podemos confundir bloqueos con niveles de aislamiento, ya que el bloqueo se hace a nivel de registros usando una instrucción específica, mientras el nivel de aislamiento es el comportamiento por defecto para cualquier otra instrucción normal que manipule los registros.

Los bloqueos existen para poder garantizar el ACID, su correcta implementación permite que halla concurrencia, de lo contrario se puede presentar la contención y es fatal.

Los bloqueos los podemos dividir en dos grandes …

Dedique varias semanas en investigar como implementar CloudFormation de Amazon para montar un entorno de pruebas de Percona XtraDB Cluster con cuatro nodos, dos HAProxy, un servidor con Nagios, y una VIP, adicionalmente usando Puppet, la idea que me atrajo de usar CloudFormation fue la practicidad de definir toda una infraestructura de maquinas virtuales usando un JSON como template, el tener un formulario para definir variables, y luego tener la ventaja de poder crear y destruir cualquier cantidad de veces el cluster de forma automatizada.

Al final me di cuenta que no es seguro usar CloudFormation por varios motivos:

• CloudFormation se asegura de mantener toda la infraestructura al 100% como está definida en el JSON. Si no hay algo que no encaja, crea una nueva maquina y destruye la anterior, al tener una Base de Datos con datos de producción los podemos perder muy fácilmente. Esto me paso al cambiar la versión de la AMI, …

En la versión 5.6.6 se incluyo una nueva herramienta llamada mysql_config_editor, la cual permite almacenar las credenciales de autenticación de una forma segura y otros datos básicos en un archivo llamado ‘.mylogin.cnf’ en el directorio home del usuario, luego estas credenciales pueden ser recuperadas para conectarse al servidor de MySQL deseado.

A simple vista no parece, pero es muy importante que considere que el archivo ‘.mylogin.cnf’ no está cifrado, y no es completamente seguro, pero añade una capa más de seguridad ocultando los datos sensibles por la línea de comandos. Por ejemplo, ocultamos la contraseña en el; historial, alias, logs, scripts, etc… donde puede ser visible de muchas formas.

En el siguiente ejemplo se muestra la forma tradicional de conectarse a una base de datos usando todos los …

Suele pasar mucho que nos confundimos con estos tres términos; procesos, hilos y conexiones (Processes, Threads & Connections), les quiero explicar un poco de que va cada uno y como están relacionados:

• MySQL Server es un proceso de aplicación.
• MySQL Server es multi hilo (multithreaded).
• MySQL Server acepta multiples conexiones por TCP/IP.
• MySQL Server dedica por cada conexión un hilo (thread).
• Un hilo se puede llamar de vez en cuando proceso, y un proceso puede hacer referencia a una conexión.

La última parte suena confuso, y me explico; MySQL Server (mysqld) es solo un proceso que se está ejecutando en el Sistema Operativo, el cual éste proceso permite tener muchos hilos de ejecución, un hilo por cada conexión realizada con el servidor, cuando se cierra la conexión se destruye el hilo.

Crear y eliminar conexiones es una tarea costosa, porque se …

Puede pasar que la ejecución de un procedimiento almacenado tarde más tiempo de lo previsto, y como hay un evento que lo ejecuta cada X tiempo, estos empiezan a verse amontonados en la lista de procesos, como podemos imaginar es muy malo. Afortunadamente MySQL tiene unas funciones que nos permite hacer un bloqueo exclusivo, así garantizamos que se ejecute solo uno a la vez.

En el siguiente ejemplo, tenemos un evento que se ejecuta cada 1 segundo y llama a un procedimiento almacenado que tarda 5 segundos en ejecutarse. Lo ideal de este caso, es que podremos observar en la lista de procesos 5 eventos ejecutando al mismo tiempo.

DELIMITER |
CREATE PROCEDURE sp_wait()
BEGIN
    SELECT SLEEP(5);
END|
DELIMITER ;

DROP EVENT IF EXISTS ev_wait;
DELIMITER |
CREATE EVENT ev_wait ON SCHEDULE EVERY 1 SECOND DO
BEGIN
  CALL sp_wait();
END|
DELIMITER ;

Una vez creado el procedimiento almacenado y el evento, ya podremos observar como se …

De vez en cuando nos toca hacer un gran UPDATE sobre una tabla grande que nos puede llevar 10 min. para completar su ejecución, el problema es que si lo hacemos directamente bloqueamos la tabla hasta que termine, eso puede ocasionar varios problemas muy graves a nivel de aplicación, hoy presento una alternativa usando Procedimientos Almacenados.

Básicamente consiste en tener una sentencia que hace UPDATE a cada 1000 rows, se ejecuta dicha query N veces hasta llegar a 0 rows actualizados, en cada interacción hacemos una pequeña pausa de 2 segundos para dejar que pasen las transacciones que están esperando usar dicho recurso.

DROP PROCEDURE IF EXISTS sp_users_update;

DELIMITER |
CREATE PROCEDURE sp_users_update()
  BEGIN
    SET @row_count = 0;

    REPEAT
      -- Query to update:
      UPDATE LOW_PRIORITY users SET username = CONCAT('DELETED_', username)
      WHERE deleted_at IS NOT NULL
      AND username NOT LIKE 'DELETED_%' …