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

A veces en el fichero error_log del Apache nos puede aparecer un mensaje como el siguiente:

[Thu Feb 04 15:23:42 2010] [notice] child pid 1241 exit signal Segmentation fault (11)

Revisando el fichero error_log y el access_log no encontramos más información sobre la posible causa del error. Para obtener más información lo que podemos hacer es activar los core dumps en el Apache. Para ello añadiremos al fichero de configuración la directiva:

CoreDumpDirectory /var/tmp

En esta directiva le indicamos el directorio donde guardar los dumps. Deberá ser un directorio escribible por el usuario con el que se ejecuta Apache (apache, nobody,…). Ahora se reinicia el servidor Apache.

Cuando se produzca el error, se nos debería generar un fichero /var/tmp/core.nnnn

Para poder analizar este fichero podemos usar un programa como gdb (the GNU project debugger).

# gdb /usr/sbin/httpd core.nnnn

Al ejecutar este comando obtendremos información sobre el error y con un poco de suerte podremos averiguar que biblioteca ha sido la causante del error.

DAVID FERNANDEZ ACIN Apache Apache, core dump, debug, gdb, Linux