David Fernandez

Tenemos dos servidores MySQL sobre Linux (Red Hat 5) en replicación maestro-esclavo. Ambos servidores tienen activo el iptables local.  Al reiniciar el iptables (service iptables restart) en el esclavo, se observa que la replicación se ha detenido. Sin embargo al ejecutar el show slave status no se observa nada extraño:

mysql> show slave status\G
*************************** 1. row ***************************
 Slave_IO_State: Waiting for master to send event
 Master_Host: miservidormysql
 Master_User: usuarioreplicacion
 Master_Port: 3306
 Connect_Retry: 60
 Master_Log_File: binary.000031
 Read_Master_Log_Pos: 32774937
 Relay_Log_File: mysqld-relay-bin.000083
 Relay_Log_Pos: 747963
 Relay_Master_Log_File: binary.000031
 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: 32774937
 Relay_Log_Space: 747963
 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)

Tanto el Slave_IO_Running como el Slave_SQL_Running están a Yes y el parámetro Seconds_Behind_Master es 0. Sin embargo, los datos no se están replicando.

Por algún motivo que desconozco, la conexión usada en la replicación ha dejado de funcionar, pero el esclavo no lo detecta. Pasados 3600 segundos la conexión se restablece y la replicación vuelve a funcionar. Si necesitamos recuperar la replicación de forma instantánea podemos parar y arrancar el esclavo:

mysql> stop slave;
mysql> start slave;

También podemos modificar la variable MySQL slave_net_timeout a un valor inferior a 3600 segundos para esperar menos tiempo a la recuperación automática.

DAVID FERNANDEZ ACIN Linux, MySQL iptables, replicación MySQL

Innotop es una herramienta para la monitorización de MySQL. Está escrita en Perl. Está inspirada en el clásico mytop, pero proporcionando más funcionalidad.

Para instalarla en Red Hat 5 solo necesitamos Perl y los siguientes paquetes:

-       perl-TermReadKey-2.30-3.el5.rf.x86_64.rpm (http://dag.wieers.com/rpm/packages/perl-TermReadKey/)

-       innotop-1.6.0-1.el5.noarch.rpm (http://www.rpmfind.net/linux/RPM/epel/5/ppc/innotop-1.6.0-1.el5.noarch.html)

Instalamos estos paquetes con rpm –Uvh y ya podemos ejecutar el comando innotop.

DAVID FERNANDEZ ACIN MySQL Base de Datos, Monitorización MySQL, MySQL, Utilidades

La versión 5 de MySQL incorpora una funcionalidad que parece muy interesante para detectar problemas de rendimiento en el servidor. Es el Query Profiler. Mediante esta funcionalidad podremos desglosar en que partes de cada query se distribuye el tiempo de ejecución de la misma. Un ejemplo de un uso básico de esta funcionalidad es el siguiente:

mysql> set profiling=1;
Query OK, 0 rows affected (0.00 sec)

mysql> select count(*) from db;
+----------+
| count(*) |
+----------+
|        7 |
+----------+
1 row in set (0.00 sec)

mysql> show profiles;
+----------+------------+-------------------------+
| Query_ID | Duration   | Query                   |
+----------+------------+-------------------------+
|        1 | 0.00028800 | select count(*) from db |
+----------+------------+-------------------------+
1 row in set (0.00 sec)

mysql> show profile for query 1;
+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000080 |
| checking query cache for query | 0.000105 |
| Opening tables                 | 0.000026 |
| System lock                    | 0.000005 |
| Table lock                     | 0.000007 |
| init                           | 0.000019 |
| optimizing                     | 0.000011 |
| executing                      | 0.000017 |
| end                            | 0.000003 |
| end                            | 0.000002 |
| query end                      | 0.000002 |
| freeing items                  | 0.000004 |
| closing tables                 | 0.000004 |
| logging slow query             | 0.000002 |
| cleaning up                    | 0.000001 |
+--------------------------------+----------+
15 rows in set (0.00 sec)

mysql> set profiling=0;
Query OK, 0 rows affected (0.00 sec)

Más información:

• http://dev.mysql.com/tech-resources/articles/using-new-query-profiler.html
• http://dev.mysql.com/doc/refman/5.0/en/show-profiles.html

DAVID FERNANDEZ ACIN MySQL MySQL

El IO scheduler de un sistema operativo es la parte del mismo encargada de organizar las operaciones de entrada y salida contra el disco.

En los kernels actuales de Linux (2.6.x) tenemos disponibles varios de estos schedulers (planificadores). Por ejemplo en la distribución Red Hat Linux 5 disponemos de los siguientes:

• noop
• anticipatory
• deadline
• cfq

Cada uno de estos planificadores tiene ventajas e inconvenientes según el tipo de uso que se le vaya a dar al disco del servidor. Por defecto, en Red Hat viene configurado como planificador cfq. El planificador se puede configurar para cada disco del servidor. Podemos ver el planificador con el siguiente comando:

# cat /sys/block/<<disco>>/queue/scheduler

En el caso de MySQL parece que el planificador cfq no es el que proporciona el rendimiento optimo. Parece que los planificador noop o deadline proporcionan mejor rendimiento.

Para cambiar el planificador de nuestro disco lo podemos hacer de dos formas:

• En el arranque del servidor: añadiendo el parámetro elevator=<<nombre-scheduler>> a la línea kernel del gestor de arranque. Esto cambiará el planificador para todos los discos duros de nuestro servidor.
• Mediante el siguiente comando:

# echo "<<nombre-scheduler>>" > /sys/block/<<disco>>/queue/scheduler

La segunda forma permite cambiar el planificador en caliente y también especificar un planificador distinto para cada disco. Por ejemplo, en el caso se un servidor MySQL con un disco para el sistema operativo y otro para los datos del MySQL, podríamos configurar cfq para el disco del sistema operativo y deadline para el disco de los datos.

Más información:

• http://www.kernel-labs.org/?q=blockiolayer
• http://kerneltrap.org/node/7637
• http://www.mysqlperformanceblog.com/2009/01/30/linux-schedulers-in-tpcc-like-benchmark/
• http://planet.mysql.com/entry/?id=19017

DAVID FERNANDEZ ACIN Linux, MySQL Linux, MySQL

Primer día del curso.

Empezamos la sesión con una copia de maquinas virtuales a partir del disco duro.  Como solo eran 3 GB en una hora y pico se ha solventado el problema.

Una vez que ya tenemos las maquinas virtuales, empezamos con la instalación del MySQL en Windows y Linux.

Acabamos la instalación y  nos vamos al café que ya estamos agotados.

Después del café, empezamos a conocer los comandos básicos de MySQL. Hay cosillas interesantes como los inserts multiples:

INSERT INTO t1 VALUES (value11,value12,…),(value21,value22,…),…

También conocemos los comandos que nos permiten saber quienes somos y donde estamos en el MySQL;

select database();

select user();

select version ();

Ahora vamos a conectarnos al servidor MySQL de forma remota. Aprendemos la forma básica de crearnos un usuario con todos los privilegios:

CREATE USER ‘dbaremote’@'%’ IDENTIFIED BY ‘******’;

GRANT ALL ON *.* to ‘dbaremote’@'%’;

(el que % no incluya a localhost parece que es una característica de MySQL).

Y con esto damos por acabada la sesión de hoy….

Empieza el segundo día.

Empezamos revisando los diferentes métodos de conexión al MySQL (TCP/IP, Unix Socket,…)

Ahora revisamos los diferentes directorios usados por MySQL. También vemos los diferentes ficheros de logs y las cosas que MySQL guarda en memoria.

Ahora toca una revisión más en profundidad del fichero de configuración:

- Configuración del networking

- Configuración de los ficheros de logs

- Configuración de los motores disponibles (podemos consultarlos con la sentencia SQL “show engines;”).

A continuación empezamos a ver temas de motores de MySQL. No todos los motores sirven para la mismo.

Hora del café…

Hacemos pruebas de cambio de tablas entre MyISAM e INNODB. Vemos como el MySQL controla que no se usen características de estos motores antes de hacer el cambio.

Con INNODB se pueden usar constraints.

Ahora reconfiguramos el MySQL para que guarde sus ficheros en otros directorios. Esto nos permitiría separar los logs y los datos en discos distintos, usar almacenamiento externo… La cosa es sencilla, pero como Ubuntu utiliza AppArmor, pues hay que hacer algún paso más de los tradicionales.

Y con esto damos por finalizado el segundo día….

Tercer día del curso.

Empezamos el día conociendo un poco la BD information_schema y viendo las diferencias con el SHOW .. Practicamos una serie de querys para ve que información podemos obtener de la BD information_schema.

Continuamos con la revisión del modelo de privilegios de MySQL.

Ahora vamos a ver como securizar de forma básica un servidor MySQL. Existe un script en el MySQL mysql_secure_installation que hace los pasos básicos de esta labor.

Lo siguiente que nos toca es revisar una serie de herramientas para administrar MySQL:

• mysqladmin, mysqldump,…
• MySQL Administrator para monitorizar el servidor, aunque parece tener el problema de que algunas de las funciones se han de ejecutar en local. Parece interesante.
• MySQL WorkBench para la diseño de BD de forma gráfica.
• MySQL Migration Tool es una herramienta para migrar BD desde Access, Oracle, SQL Server,…

Vamos a ver temas de backup de MySQL.  Distinción entre backups binarios (copia de ficheros) y backups de texto (dump de la BD). Revisar opciones del mysqldump.

Por último, vemos una rápida visión de la replicación entre MySQL.  Es más o menos lo mismo que he estado usando hasta la fecha.

Y con esto se da por finalizado el curso…

DAVID FERNANDEZ ACIN MySQL MySQL