Archivo

Archivo para la categoría ‘MySQL’

Error replicación MySQL al reiniciar Iptables local

Martes, 16 de Febrero de 2010

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.

Linux, MySQL ,

Innotop: monitorización MySQL

Miércoles, 9 de Diciembre de 2009

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.

MySQL , , ,

MySQL Query Profiler

Jueves, 3 de Diciembre de 2009

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:

MySQL

IO Scheduler en Linux & MySQL

Miércoles, 2 de Diciembre de 2009

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:

Linux, MySQL ,