Para bajarla, hay acceder a edelivery.oracle.com (hay que registrarse en Oracle) y elegir el pack “MySQL Database”, luego sale ya todo el listado de descargas.

Una vez descargado, es tan simple como:

# tar -xzvf mcm-1.1.2_32-cluster-7.1.15a_64-solaris10-x86.tar.gz
# mv  mcm-1.1.2_32-cluster-7.1.15a_64-solaris10-x86 mcm
# cd mcm
# ./bin/mcmd --bootstrap
MySQL Cluster Manager 1.1.2 started
Connect to MySQL Cluster Manager by running "/home/alex/V27753-01/mcm/bin/mcm" -a localhost:1862
Configuring default cluster 'mycluster'...
...
...

A partir de ese momento ya tendremos un cluster MySQL formado por dos nodos de datos (ndbd), dos servidores MySQL (mysqld) y un nodo de gestión (ndb_mgmd). Si quisieramos personalizar el cluster deberíamos acceder a la consola mcmd y gestionarlo desde ahí:

#./bin/mcmd
mcm>create site -h khepri14 mysite;
mcm>add package -b /home/mcm/cluster mypackage;
mcm>create cluster -P mypackage -R ndb_mgmd@khepri14,ndbd@khepri14,ndbd@khepri14,mysqld@khepri14,mysqld@khepri14 m
ycluster;
mcm>set port:mysqld:4=3306,port:mysqld:5=3307 mycluster;
mcm>start cluster mycluster;

También te puede interesar:

• MySQL Cluster (I): Instalación de nodos de datos/SQL y gestión (MGM)
• Red Hat Cluster: “generic error” al crear un IP Resource
• Replicación MySQL: SQL_SLAVE_SKIP_COUNTER
• Replicacion MySQL maestro-esclavo

Vamos a forzar un fallo en la replicación creando una base de datos en el servidor esclavo y posteriormente crearla en el maestro. La forma natural de que el esclavo tuviera esa base de datos sería heredandola del maestro, no creándose de forma manual. Esto provocará el fallo de la replicación:

mysql-esclavo> CREATE DATABASE prueba;

mysql-master> CREATE DATABASE prueba;

Una vez realizado esto, el master replicará la creación de esa base de datos en el esclavo, pero como la hemos creado a mano provocará el fallo y que se pare la replicación, lo podemos ver al hacer un SHOW SLAVE STATUS en el esclavo:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: 192.168.1.129
                Master_User: replicacion
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysqld-bin.000004
        Read_Master_Log_Pos: 179
             Relay_Log_File: mysqld-relay-bin.000008
              Relay_Log_Pos: 236
      Relay_Master_Log_File: mysqld-bin.000004
           Slave_IO_Running: Yes
          Slave_SQL_Running: No
            Replicate_Do_DB:
        Replicate_Ignore_DB:
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                 Last_Errno: 1007
                 Last_Error: Error 'Can't create database 'prueba'; database exists' on query. Default database: 'prueba'. Query: 'create database prueba'
               Skip_Counter: 0
        Exec_Master_Log_Pos: 98
            Relay_Log_Space: 317
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: NULL
1 row in set (0.00 sec)

Sabemos que el error se encuentra en la consulta SQL de creación de la base de datos “prueba”. Gracias a la opción SET GLOBAL SQL_SLAVE_SKIP_COUNTER podemos decirle al servidor esclavo que se salte X posiciones del log binario para así evitar las consultas problemáticas:

mysql-esclavo>SET GLOBAL SQL_SLAVE_SKIP_COUNTER =1;

Con el comando anterior hemos saltado la consulta de creación de la base de datos “prueba”, ahora podemos reiniciar la replicación en el esclavo y verificar si ya no tenemos errores y vuelve a la normalidad:

mysql-esclavo> START SLAVE;
Query OK, 0 rows affected (0.01 sec)

mysql-esclavo> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: 192.168.1.129
                Master_User: replicacion
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysqld-bin.000004
        Read_Master_Log_Pos: 179
             Relay_Log_File: mysqld-relay-bin.000008
              Relay_Log_Pos: 317
      Relay_Master_Log_File: mysqld-bin.000004
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB:
        Replicate_Ignore_DB:
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                 Last_Errno: 0
                 Last_Error:
               Skip_Counter: 0
        Exec_Master_Log_Pos: 179
            Relay_Log_Space: 317
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: 0
1 row in set (0.00 sec)

Efectivamente, todo ha vuelto a la normalidad. Si siguiera pasando habría que revisar la opción de seguir saltando consultas del log. Lo importante cuando hacemos esto es mantener los mismos datos en el maestro y el esclavo, ya que en este caso sabemos que simplemente era por la prueba de crear la base de datos, pero en cuestión de consultas INSERT, DROP, etc la cosa puede no ser tan sencilla.

También te puede interesar:

• Replicacion MySQL maestro-esclavo
• Red Hat Cluster: “generic error” al crear un IP Resource
• Crear un cluster MySQL con un único comando
• Cloud computing o servidores dedicados: ¿qué elegir?

Partimos de la base que tenemos instalado MySQL en ambos servidores, sino toca instalarlo como si de una instalación estándar se tratara (por yum, compilando, por paquetes precompilados, etc). También utilizaremos la base de datos world para hacer pruebas, disponible en:

http://downloads.mysql.com/docs/world.sql.zip

# yum install mysql-server

Vamos a utilizar la siguiente nomenclatura para los hosts:

mysql-master
mysql-slave

Lo primero que debemos saber a la hora de configurar los dos nodos es que:

1. El servidor Master debe tener activado el log binario (log-bin).
2. Ambos deben tener un identificador único (server-id).
3. El servidor maestro deberá tener un usuario con privilegio REPLICATION SLAVE.

Puesta en marcha del Master (mysql-master)

Para activar el log binario, accedemos al fichero de configuración /etc/my.cnf y añadimos log-bin dentro de la sección [mysqld].

[mysqld]
log-bin

En la misma sección [mysqld] debemos asignar un número único a modo de identificador tanto al Master como al Slave, en este caso asignamos 1 al Master:

Master my.cnf:

[mysqld]
log-bin
server-id=1

Reiniciamos el servidor maestro y verificamos que los logs binarios se han creado en el directorio de datos:

mysql-master# /etc/init.d/mysqld restart && ls -l /var/lib/mysql/*bin*
-rw-rw---- 1 mysql mysql 98 Jul 30 23:28 /var/lib/mysql/mysqld-bin.000001
-rw-rw---- 1 mysql mysql 20 Jul 30 23:28 /var/lib/mysql/mysqld-bin.index

Accedemos por shell a la consola MySQL y creamos el usuario con el privilegio REPLICATION SLAVE, 192.168.1.129 es la IP del servidor esclavo:

mysql-master> GRANT REPLICATION SLAVE ON *.* TO 'replicacion'@'192.168.1.129' IDENTIFIED BY 'password';
Query OK, 0 rows affected (0.01 sec)

mysql-master> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

Aprovechamos para volcar la base de datos world sobre la que haremos algunas pruebas:

mysql-master> create database world;
mysql-master> use world
mysql-master> SOURCE world.sql

Puesta en marcha del Slave (mysql-slave)

En la sección [mysqld] del fichero de configuración /etc/my.cnf debemos asignar  el id 2 al Slave:

[mysqld]
server-id=2

Reiniciamos el servidor MySQL esclavo:

mysql-master# /etc/init.d/mysqld restart

Copia inicial de la base de datos (directorio data)

Antes de activar la replicación ambos servidores deben tener la misma información (bases de datos) y en el mismo punto de restauración. Lo primero que haremos antes de hacer la copia es hacer un flush de las tablas y bloquear las escrituras, de este modo podemos hacer el ‘snapshot’ sin tener que apagar el servidor MySQL. Todo esto lo hacemos en el Master:

mysql-master> FLUSH TABLES WITH READ LOCK;

Ahora podemos hacer la copia de muchas formas, con mysqldump, rsync de los datos, comprimiendo el directorio de datos donde se alojan las bases de datos con .tar.gz, etc

mysql-master# cd /var/lib && tar czvf /tmp/data-mysql.tar.gz mysql
mysql-master# scp /tmp/data-mysql.tar.gz root@mysql-slave:/tmp
data-mysql.tar.gz                                                                100%  417KB 416.9KB/s   00:00

Una vez realizado podemos volver a desbloquear las tablas, no sin antes abrir una nueva shell de mysql y apuntar por un lado el fichero de log binario que se está usando y la posición en la que se ha quedado pues será la que se usará posteriormente para comenzar la replicación en el esclavo:

mysql-master> SHOW MASTER STATUS;
+-------------------+----------+--------------+------------------+
| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+----------+--------------+------------------+
| mysqld-bin.000002 |   724514 |              |                  |
+-------------------+----------+--------------+------------------+
1 row in set (0.01 sec)

Ahora sí que podemos desbloquearlas:

mysql-master> UNLOCK TABLES;

Llega el momento de movernos al esclavo, lo primero que debemos hacer es asegurarnos de parar la replicación en caso de que estuviera activa:

mysql-slave> slave stop;
Query OK, 0 rows affected, 1 warning (0.00 sec)

En este momento los datos del master que hemos comprimido tendríamos que restaurarlos en la carpeta de datos del esclavo, simplemente los descomprimimos sobre la ruta /var/lib/mysql o la que tenga vuestra instalación.

Ahora llega el momento clave, tenemos que indicarle al esclavo quien es el servidor maestro y establacer la comunicación. Especificaremos el hostname del master, el usuario creado anteriormente para la replicación, su clave, el fichero de log binario a utilizar y su posición. Recordad que esto último lo hemos apuntado al hacer un SHOW MASTER STATUS;

mysql-slave> CHANGE MASTER TO
    ->     MASTER_HOST='192.168.1.130',
    ->     MASTER_USER='replicacion',
    ->     MASTER_PASSWORD='password',
    ->     MASTER_LOG_FILE='mysqld-bin.000002',
    ->     MASTER_LOG_POS=724514;
Query OK, 0 rows affected (0.04 sec)

Llego el momento de arrancar la replicación, para ello reactivamos el esclavo:

mysql-slave> START SLAVE;
Query OK, 0 rows affected (0.01 sec)

Revisar el estado de la replicación

Una vez puesta en marcha la replicación, deberían existir unos procesos concretos tanto en el master como el slave. En el master debería aparecer una conexión del servidor esclavo con el usuario usado en la replicación esperando a recibir actualizaciones a través del bin-log:

mysql-master> show processlist;
+----+-------------+-----------------+------+-------------+------+----------------------------------------------------------------+------------------+
| Id | User        | Host            | db   | Command     | Time | State                                                          | Info             |
+----+-------------+-----------------+------+-------------+------+----------------------------------------------------------------+------------------+
|  2 | replicacion | mysql-slave:59928 | NULL | Binlog Dump |    7 | Has sent all binlog to slave; waiting for binlog to be updated | NULL             |
|  3 | root        | localhost       | NULL | Query       |    0 | NULL                                                           | show processlist |
+----+-------------+-----------------+------+-------------+------+----------------------------------------------------------------+------------------+
2 rows in set (0.00 sec)

Y el slave debería tener dos conexiones relacionadas con la replicación, un thread SQL y otro de I/O relacionado con las lecturas de relay log:

mysql-slave> show processlist;
+----+-------------+-----------+------+---------+------+-----------------------------------------------------------------------+------------------+
| Id | User        | Host      | db   | Command | Time | State                                                                 | Info             |
+----+-------------+-----------+------+---------+------+-----------------------------------------------------------------------+------------------+
|  1 | system user |           | NULL | Connect |   11 | Waiting for master to send event                                      | NULL             |
|  2 | system user |           | NULL | Connect |   11 | Has read all relay log; waiting for the slave I/O thread to update it | NULL             |
|  4 | root        | localhost | NULL | Query   |    0 | NULL                                                                  | show processlist |
+----+-------------+-----------+------+---------+------+-----------------------------------------------------------------------+------------------+

Monitorización de la replicación

Ahora que ya tenemos la replicación funcionando tenemos que conocer la forma de monitorizar su funcionamiento, el comando más importante lo podemos ejecutar en el esclavo (SHOW SLAVE STATUS), nos indicará el estado detallado de la replicación:

mysql-slave> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: 192.168.1.130
                Master_User: replicacion
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysqld-bin.000002
        Read_Master_Log_Pos: 724601
             Relay_Log_File: mysqld-relay-bin.000002
              Relay_Log_Pos: 323
      Relay_Master_Log_File: mysqld-bin.000002
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB:
        Replicate_Ignore_DB:
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                 Last_Errno: 0
                 Last_Error:
               Skip_Counter: 0
        Exec_Master_Log_Pos: 724601
            Relay_Log_Space: 323
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: 0
1 row in set (0.00 sec)

Los puntos más importantes:

• Slave_IO_State: Monitoriza el estado del servidor esclavo respecto al master, en este caso está esperando a recibir eventos (actualizaciones del log binario por parte del master.
• Master_log_File: Especifica el log binario en el servidor maestro que se está utilizando en la replicación.
• Read_Master_Log_Pos: Indica la posición hasta la cual se ha leído del log binario del master, debería coincidir con la que nos da el SHOW MASTER STATUS en el servidor maestro y con el valor del parámetro Exec_Master_Log_Pos
• Relay_Master_log_File: Especifica el log binario en el servidor esclavo que se está utilizando en la replicación.
• Slave_IO_Running y Slave_SQL_Running: Monitorizan si los dos procesos mencionados antes están corriendo, los threads IO_THREAD y SQL_THREAD. Es crítico que ambos estén siempre corriendo.
• Seconds_Behind_Master: Este parámetro puede ser un indicativo claro de problemas de carga, conectividad de red, etc. Indica el número de segundos de retardo respecto al servidor maestro. Lo ideal, 0.

Probando la replicación

A partir de aquí podemos verificar de una forma muy sencilla el funcionamiento de la replicación. Si añadimos, modificamos o borramos registros en una tabla de una base de datos del master automáticamente se replicará en la slave. Si creamos una base de datos en el master automáticamente se creará en el slave, etc:

mysql-master:

mysql-master> create database test01;
Query OK, 1 row affected (0.00 sec)

mysql-master> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| test               |
| test01             |
| world              |
+--------------------+
5 rows in set (0.00 sec)

Inmediatamente en el mysql-slave:

mysql-slave> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| test |
| test01 |
| world |
+--------------------+
5 rows in set (0.01 sec)

Bueno, de momento esto podría ser suficiente para una primera aproximación a la replicación maestro-esclavo de MySQL. En futuros artículos si os resulta interesante podemos indagar y detalladar algunas de las cosas tratadas en el artículo y/o revisar otros tipos de replicación, como la circular, la de doble sentido, etc.

También te puede interesar:

• Replicación MySQL: SQL_SLAVE_SKIP_COUNTER
• Red Hat Cluster: “generic error” al crear un IP Resource
• Crear un cluster MySQL con un único comando
• Cloud computing o servidores dedicados: ¿qué elegir?

mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table XXXX

Para solucionarlo, podemos aumentar temporalmente el tamaño máximo del buffer de comunicación de mysql a través de la variable max_allowed_packet. El valor se puede establecer en K, M ó G para indicar er kilobytes, megabytes, o gigabytes. Probad a aumentar el límite y verificar si el error queda solucionado, sino, es posible que tengáis que aumentarlo más:

$ mysqldump --opt --max_allowed_packet=128M base_de_datos > bd.sql

También te puede interesar:

• Backup de todas las bases de datos MySQL con una sola línea de comandos
• Mysqldump: excluir una tabla en el backup
• Backups MySQL con mysqldump
• mysqldump: Errcode: 24 when using LOCK TABLES

Activar el Slow Query Log

Activar el log de consultas lentas en MySQL supondrá que en el momento que una consulta SQL supere el tiempo de ejecución establecido con la variable long_query_time quedará registrada en el log establecido. Para activarlo añadimos las siguientes directivas en el fichero de configuración my.cnf:

log-slow-queries=/var/log/mysql-slow-queries.log
long_query_time = 5

Este tema ya lo traté en un artículo anterior, para profundizar en ello acceded a la entrada a través del siguiente enlace: Slow Queries en MySQL.

Usar SHOW PROCESSLIST

Tanto desde la propia shell desde MySQL como usando mysqladmin podemos visualizar a tiempo real las consultas SQL que se están ejecutando en el servidor:

mysql> show processlist;
+----+------+-----------+------+---------+------+-------+------------------+
| Id | User | Host      | db   | Command | Time | State | Info             |
+----+------+-----------+------+---------+------+-------+------------------+
| 35 | root | localhost | NULL | Query   |    0 | NULL  | show processlist |
+----+------+-----------+------+---------+------+-------+------------------+
1 row in set (0.00 sec)

Como podéis observar, nos muestra el estado de la consulta (State), la base de datos, el comando que está ejecutando, el usuario, el host y el tiempo de ejecución, siendo este último de los puntos más importantes. Recordad que podéis formatear la salida con \G:

mysql> show processlist \G
*************************** 1. row ***************************
     Id: 35
   User: root
   Host: localhost
     db: NULL
Command: Query
   Time: 0
  State: NULL
   Info: show processlist
1 row in set (0.00 sec)

Y con mysqladmin desde la shell bash:

$ mysqladmin processlist -u root --pXXXX
+----+------+-----------+----+---------+------+-------+------------------+
| Id | User | Host      | db | Command | Time | State | Info             |
+----+------+-----------+----+---------+------+-------+------------------+
| 42 | root | localhost |    | Query   | 0    |       | show processlist |
+----+------+-----------+----+---------+------+-------+------------------+

Si queréis ver el contenido completo de la consulta SQL que se está ejecutando probablemente necesitéis utilizar SHOW FULL PROCESSLIST; en lugar de SHOW PROCESSLIST:

mysql> SHOW FULL PROCESSLIST;
+----+------+-----------+------+---------+------+-------+-----------------------+
| Id | User | Host      | db   | Command | Time | State | Info                  |
+----+------+-----------+------+---------+------+-------+-----------------------+
| 35 | root | localhost | NULL | Query   |    0 | NULL  | SHOW FULL PROCESSLIST |
+----+------+-----------+------+---------+------+-------+-----------------------+
1 row in set (0.00 sec)

Optimizar las consultas SQL con EXPLAIN

Gracias a EXPLAIN podemos obtener toda la información sobre el modo en el que una consulta SQL se ejecutaría en el servidor. Es extremadamente útil para conocer la configuración de índices en las tablas, los índices que podrían ser configurados para mejorar su rendimiento, el número de filas que se revisan, el tipo de query, etc.

Aquí tenéis un ejemplo de EXPLAIN contra la tabla City de la base de datos de muestra de MySQL (world). Para profundizar en el funcionamiento de EXPLAIN os recomiendo revisar la documentación oficial de MySQL.

mysql> EXPLAIN select * from City;
+----+-------------+-------+------+---------------+------+---------+------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+------+------+-------+
|  1 | SIMPLE      | City  | ALL  | NULL          | NULL | NULL    | NULL | 4079 |       |
+----+-------------+-------+------+---------------+------+---------+------+------+-------+
1 row in set (0.00 sec)

mysql> EXPLAIN select * from City \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: City
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 4079
        Extra:
1 row in set (0.00 sec)

Activar el log general

Una medida quizás un poco agresiva y que no debería ser ejecutada en servidores de producción. Este log (General Query Log) registrará todas las consultas SQL que se ejecuten en el servidor. Para activarlo debemos especificar la ruta del log mediante –general_log_file= (MySQL 5.1.29+). También podemos activarlo y desactivarlo a tiempo real desde la shell MySQL del siguiente modo:

mysql> SET GLOBAL general_log = 'OFF';
mysql> SET GLOBAL general_log = 'ON';

MySQL Query Analyzer

Si pese a las opciones anteriores seguís sin poder detectar las consultas SQL problemáticas y optimizarlas, quizás MySQL Query Analyzer sea una opción factible. Es un software de pago perteneciente a la versión Enterprise que de forma gráfica monitoriza las consultas SQL del servidor y detecta el origen de los problemas. A mi entender, las otras opciones deberían ser suficiente (junto con buenos conocimientos de DBA todo sea dicho) para detectar y solucionar cualquier problema que se presente.

Como habréis podido observar, la combinación de estas opciones en distintos ordenes nos permitirá arreglar muchos problemas con consultas SQL, primero detectamos los problemas con los logs de slow_queries o SHOW PROCESSLIST y después optimizamos con EXPLAIN las consultas detectadas en los pasos anteriores.

También te puede interesar:

• MySQL tools: benchmarking con mysqlslap
• Backup de todas las bases de datos MySQL con una sola línea de comandos
• MySQL Query Cache: configuración y optimización
• Disponible MySQLTuner 1.0.0

MySQL

Si queremos comenzar haciendo tests básicos podemos dejar que sea la propia utilidad la que genere de forma aleatoria las consultas SQL, únicamente tenemos que especificar el usuario MySQL con el cual se van a realizar:

$ mysqlslap -u foo -pxxxx --auto-generate-sql
Benchmark
	Average number of seconds to run all queries: 0.007 seconds
	Minimum number of seconds to run all queries: 0.007 seconds
	Maximum number of seconds to run all queries: 0.007 seconds
	Number of clients running queries: 1
	Average number of queries per client: 0

En este test se ha realizado la conexión de un único usuario (foo) que ha realizado pruebas aleatorias entre las que se incluye la creación de una tabla, la inserción y consulta de datos en ella y la eliminación de la tabla. Si queréis ver con detalle cada una de las consultas que se realizan en el test podéis añadir la cantidad de verbose con el parámetro -v (a más v más verbose):

$ mysqlslap -vvv -u foo -pxxxx --auto-generate-sql

Estos test realmente no sirven de mucho, así que conviene saber como personalizarlos, añadir más usuarios concurrentes en las pruebas y consultas SQL personalizadas. El número de usuarios concurrentes se especifica con el parámetro

, vamos a realizar la misma prueba pero con 50 usuarios concurrentes:

$ mysqlslap -u foo -pxxxx --concurrency=50 --auto-generate-sql
Benchmark
	Average number of seconds to run all queries: 0.389 seconds
	Minimum number of seconds to run all queries: 0.389 seconds
	Maximum number of seconds to run all queries: 0.389 seconds
	Number of clients running queries: 50
	Average number of queries per client: 0

Otro parámetro interesante es

, mediante el cual podemos especificar el número de veces que se repetirá el test. Vamos a ejecutarlo 4 veces:

$ mysqlslap -u foo -pxxxx --concurrency=50 >--iterations=4 --auto-generate-sql
Benchmark
	Average number of seconds to run all queries: 0.389 seconds
	Minimum number of seconds to run all queries: 0.389 seconds
	Maximum number of seconds to run all queries: 0.389 seconds
	Number of clients running queries: 50
	Average number of queries per client: 0

También podemos modificar el número de consultas a realizar en el test con el parámetro

, serán repartidas entre el número de usuarios que ejecutan el test:

$ mysqlslap -u foo -pxxxx --concurrency=50 >--iterations=4 --number-of-queries=300 --auto-generate-sql
Benchmark
	Average number of seconds to run all queries: 0.233 seconds
	Minimum number of seconds to run all queries: 0.217 seconds
	Maximum number of seconds to run all queries: 0.242 seconds
	Number of clients running queries: 50
	Average number of queries per client: 6

Otro parámetro de extrema utilidad es

, que nos permite especificar el tipo de motor a utilizar para la creación de la tabla (MyISAM, Innodb…) y así poder realizar varios tests y verificar cual es el más adecuado.

$ mysqlslap -u foo -pxxxx --concurrency=50 --iterations=4 --number-of-queries=300 --engine=innodb --auto-generate-sql
Benchmark
	Running for engine innodb
	Average number of seconds to run all queries: 1.873 seconds
	Minimum number of seconds to run all queries: 1.724 seconds
	Maximum number of seconds to run all queries: 2.197 seconds
	Number of clients running queries: 50
	Average number of queries per client: 6

Para poder personalizar al máximo el test de benchmarking conviene poder especificar la creación de tablas y consultas a realizar. Con

especificamos la creación de la tabla y con

la consulta a realizar. Este es el ejemplo disponible en la documentación de MySQL y el resultado de la prueba:

$ mysqlslap --delimiter=";" \
  --create="CREATE TABLE a (b int);INSERT INTO a VALUES (23)" \
  --query="SELECT * FROM a" --concurrency=50 --iterations=200
Benchmark
	Average number of seconds to run all queries: 0.038 seconds
	Minimum number of seconds to run all queries: 0.011 seconds
	Maximum number of seconds to run all queries: 0.061 seconds
	Number of clients running queries: 50
	Average number of queries per client: 1

Si no queremos introducir nuestras propias consultas SQL pero sí que queremos personalizar la creación de la tabla, podemos especificar parámetros como el número de columnas VARCHAR con

, el número de columnas INT con

, etc.

Esta es una pequeña muestra de las posibilidades que nos brinda esta utilidad de MySQL y su gran utilidad para las pruebas de rendimiento de bases de datos en entornos de desarrollo y pre-producción. Si queréis profundizar más en las posibilidades de mysqlslap os recomiendo revisar la documentación de MySQL.

También te puede interesar:

• 5 formas de encontrar y optimizar consultas MySQL problemáticas
• MySQL Query Cache: configuración y optimización
• Disponible MySQLTuner 1.0.0
• Crear un cluster MySQL con un único comando

| 64 | unauthenticated user | 10.0.3.17:37723 |               | Connect |      | login |                  |
| 65 | unauthenticated user | 10.0.3.6:45973  |               | Connect |      | login |                  |
| 66 | unauthenticated user | 10.0.3.6:45974  |               | Connect |      | login |                  |
| 67 | unauthenticated user | 10.0.3.6:45975  |               | Connect |      | login |                  |
| 68 | unauthenticated user | 10.0.3.6:45976  |               | Connect |      | login |                  |
| 69 | unauthenticated user | 10.0.3.6:45977  |               | Connect |      | login |                  |
| 70 | unauthenticated user | 10.0.3.6:45978  |               | Connect |      | login |                  |
| 71 | unauthenticated user | 10.0.3.6:45979  |               | Connect |      | login |                  |
| 72 | unauthenticated user | 10.0.3.6:45980  |               | Connect |      | login |                  |
| 73 | unauthenticated user | 10.0.3.6:45981  |               | Connect |      | login |                  |

En el momento que he verificado que el problema surgía únicamente con las conexiones remotas he comenzado a revisar las distintas posibilidades, entre las que se encontraba por ejemplo revisar que los usuarios MySQL estuvieran correctamente configurados, que no hubiera problemas en las bases de datos, etc. Pero realmente el problema surgía mucho antes, en el momento en el que se establecía la conexión, antes de siquiera pedir credenciales.

En este caso el problema radicaba en que los servidores DNS configurados para la máquina (en /etc/resolv.conf) no funcionaban correctamente e impedían a MySQL resolver los hosts remotos que intentaban conectar. MySQL siempre que recibe una conexión remota vía IP intenta revisar a que nombre resuelve para posteriormente hacer el paso contrario y verificar/comparar que el host también resuelve a dicha IP original. El servidor no pasaba de aquí y generaba el cuello de botella.

Si queremos evitar que esto suceda una de dos, o nos aseguramos que los servidores DNS resuelven rápida y correctamente o deshabilitamos la resolución de nombres con –skip-name-resolve, en este caso únicamente podremos usar IPs y no hosts en la tabla de privilegios.

También te puede interesar:

• ¿Por qué ‘dig +trace’ resuelve y ‘dig’ a secas no?
• Crear un cluster MySQL con un único comando
• Telefónica bloquea el acceso a sus DNS desde redes externas
• Windows Server 2003: no funciona la resolución DNS

for DB in `mysql -e "show databases" -u USUARIO -pPASSWORD | grep -v Database`; do mysqldump -u USUARIO -pPASSWORD $DB > "$DB.sql"; done

Como podéis ver es bastante sencillo, hacemos un bucle con la salida del comando “show databases” que vuelca por pantalla todas las bases de datos del servidor, eliminamos la única línea que no nos interesa (la que contiene Database) y vamos haciendo una a una la copia de seguridad de cada una de las bases de datos con mysqldump. Únicamente tendréis que modificar el usuario y clave con el que conectar al servicio.

También te puede interesar:

• Backups MySQL con mysqldump
• mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table
• 5 formas de encontrar y optimizar consultas MySQL problemáticas
• Clonar una tabla MySQL de forma rápida y sencilla

Según esta explicación, lo primero que viene a la mente es que la Query Cache será efectiva en bases de datos en las que las tablas no tienen demasiados cambios y predominan los SELECT frente a los INSERT. Vamos a explicar de forma sencilla como activar la caché y revisar sus resultados. Recomiendo leer la documentación de MySQL para quien quiera profundizar en el tema.

Lo primero que debemos hacer para activar la caché de consultas es indicarlo en el fichero de configuración my.cnf, a través de la directiva

, que acepta tres valores:

Query Caché desactivada:

query_cache_type = 0

Query Caché activada:

query_cache_type = 1

Query Caché activada según demanda (especificandolo en la consulta (SELECT /* SQL_CACHE */):

query_cache_type = 2

En nuestro caso la activamos con el parámetro “1″, podemos ver el estado actual desde la shell MySQL:

mysql> select @@query_cache_type;
+--------------------+
| @@query_cache_type |
+--------------------+
| ON                 |
+--------------------+
1 row in set (0.00 sec)

Una vez activada, tenemos que asignar un tamaño de memoria disponible para el almacenamiento de estas consultas. En la mayoría de los casos con un valor menor de 100M debería ser suficiente. En el fichero my.cnf tenemos:

query_cache_size=28M

Bien, con estos dos parámetros configurados ya empezaría a utilizarse la Query Cache en nuestro servidor MySQL. Pasado un tiempo debería llegar el momento de comprobar los resultados y verificar si está siendo efectiva. Para ello, revisamos el estado de Query Cache directamente desde la shell MySQL:

mysql> show status like 'Qcache%';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| Qcache_free_blocks      | 2319      |
| Qcache_free_memory      | 7119040   |
| Qcache_hits             | 143073915 |
| Qcache_inserts          | 67474731  |
| Qcache_lowmem_prunes    | 9384509   |
| Qcache_not_cached       | 71545921  |
| Qcache_queries_in_cache | 7528      |
| Qcache_total_blocks     | 17974     |
+-------------------------+-----------+
8 rows in set (0.00 sec)

La explicación de cada variable es la siguiente:

• Qcache_free_blocks: El número de bloques de memoria disponibles en la query cache.
• Qcache_free_memory: La cantidad de memoria libre en la query cache.
• Qcache_hits: El número de aciertos de la query caché (consultas servidas desde la cache).
• Qcache_inserts: El número de consultas insertadas a la cache.
• Qcache_lowmem_prunes: El número de consultas eliminadas de la cache por falta de memoria disponible.
• Qcache_not_cached: Número de consultas que no se han podido cachear.
• Qcache_queries_in_cache: Número de consultas registradas en la cache.
• Qcache_total_blocks: Número de bloques en la cache.

De estos puntos, conviene tener en cuenta que si el valor de Qcache_free_blocks es muy alto significa que hay fragmentación en la cache y conviene ejecutar FLUSH QUERY CACHE para desfragmentar (esto no elimina la cache). La eficiencia de la cache se mide mediante esta fórmula: Qcache_hits/(Com_select+Qcache_hits), evidentemente un número alto de hits y un buen ratio respecto a los Com_select (número total de consultas SELECT ejecutadas) es lo óptimo. Podéis ver el número de selects globales del siguiente modo:

mysql> show global status like 'Com_select%';
+---------------+----------+
| Variable_name | Value    |
+---------------+----------+
| Com_select    | 71742078 |
+---------------+----------+
1 row in set (0.00 sec)

Para comenzar a trastear con la Query Cache de MySQL esto puede ser suficiente, para el que quiera profundizar puede hacerlo revisando toda la documentación disponible de MySQL del enlace anterior.

También te puede interesar:

• 5 formas de encontrar y optimizar consultas MySQL problemáticas
• MySQL tools: benchmarking con mysqlslap
• Disponible MySQLTuner 1.0.0
• Crear un cluster MySQL con un único comando

Hay varias formas de instalar cada uno de los nodos, ya sea con gestores de paquetes de las distribuciones (apt, yum, .deb, rpm), compilando desde el código fuente o con los paquetes binarios. En este caso vamos a utilizar los paquetes binarios por su sencillez de instalación, cada cual puede escoger la forma que estime oportuna y según sus necesidades.

No voy a detenerme a explicar como funciona un cluster MySQL en profundidad, podéis ver toda la documentación del sitio web de MySQL donde está todo perféctamente explicado (esta guía está basada en esa documentación). Simplemente explicaré las partes (nodos) que van a componer este cluster.

• Nodos de datos: Son los nodos encargados de almacenar los datos del cluster. Cada nodo será una máquina física independiente. Tal y como indica la documentación de MySQL hay tantos nodos de datos como réplicas, multiplicado por el número de fragmentos. Por ejemplo, con dos réplicas, cada uno teniendo dos fragmentos, necesita cuatro nodos de datos. Es recomendable revisar bien la documentación oficial de MySQL para entender el concepto y las diferentes configuraciones posibles.
• Nodos SQL: Son los nodos que serán usados para acceder a los datos que almacenan los nodos de datos, básicamente es un servidor MySQL estandar pero que utiliza el motor de almacenamiento NDBCLUSTER.
• Nodo de gestión: También llamado nodo MGM, es el encargado de gestionar todos los nodos del cluster, entre sus funciones encontramos las de arrancar y parar nodos, aplicar configuraciones, efectuar copias de seguridad, etc.

Instalación de nodos de datos y SQL

La instalación de un nodo de datos y un nodo SQL es igual, lo único que cambia es a posteriori la configuración y modo de arranque de cada uno de ellos (lo explicaré en el siguiente artículo) .Podéis descargar el paquete binario al igual que los demás a través de este enlace:

http://dev.mysql.com/downloads/cluster/

En este caso “Generic Linux (glibc 2.3) (x86, 32-bit), Compressed TAR Archive”:

# wget http://dev.mysql.com/get/Downloads/MySQL-Cluster-7.1/mysql-cluster-gpl-7.1.3-linux-i686-glibc23.tar.gz/from/http://gd.tuwien.ac.at/db/mysql/

Procedemos a crear el usuario y grupo de sistema para ejecutar MySQL:

# groupadd mysql
# useradd -g mysql mysql

Descomprimimos el paquete y posteriormente lo renombramos a “mysql”, ubicandolo en /usr/local/:

# tar -C /usr/local -xzvf mysql-cluster-gpl-7.0.15-linux-i686-glibc23.tar.gz
# mv /usr/local/mysql-cluster-gpl-7.0.15-linux-i686-glibc23.tar.gz /usr/local/mysql

Nos dirigimos a la ruta correspondiente y ejecutamos el script preparado para crear las bases de datos de sistema:

# cd /usr/local/mysql
# scripts/mysql_install_db --user=mysql --basedir=/usr/local/mysql

Aplicamos los permisos correspondientes a las carpetas MySQL:

# cd /usr/local/mysql
# chown -R root .
# chown -R mysql data
# chgrp -R mysql .

Nota: /usr/local/mysql/data es la ruta que utilizaremos en todos los nodos para guardar los datos

Finalmente copiamos el script de arranque de MySQL a init.d, le permitimos ejecución y lo añadimos al runlevel correspondiente:

# cp support-files/mysql.server /etc/rc.d/init.d/
# chmod +x /etc/init.d/mysql.server
# chkconfig --add mysql.server

Nota: chkconfig solo funcionará en sistemas Red-Hat y derivados.

Bien, ya tenemos el nodo primer nodo de datos ó SQL instalado. Habría que repetir esta tarea en todas las máquinas que quisieramos utilizar como nodo de datos o nodo SQL.

MANAGEMENT ndb_mgm

La instalación del nodo de gestión es extremadamente sencilla. Tenemos que descargar el mismo paquete que para los nodos de datos y SQL, descomprimirlo en una ruta temporal y copiar los ejecutables correspondientes:

# cd mysql-5.1.44-ndb-7.0.15-linux-i686-glibc23
# cp bin/ndb_mgm* /usr/local/bin
# cd /usr/local/bin
# chmod +x ndb_mgm*

En el próximo artículo comenzaremos a tocar las configuraciones de los nodos de datos, gestión y mysqld. Entonces podremos arrancar el cluster y empezar a hacer las pruebas correspondientes.

También te puede interesar:

• Crear un cluster MySQL con un único comando
• Red Hat Cluster: “generic error” al crear un IP Resource
• Replicación MySQL: SQL_SLAVE_SKIP_COUNTER
• Replicacion MySQL maestro-esclavo