Estoy usando MySQL-5.1.50 con una configuración de replicación maestro-esclavo.

La mayoría de las veces el esclavo va a la zaga del maestro.

Cuando ejecuto show processlist;, no hay consulta que tarde mucho tiempo. También lo habilité slow_log. Sin embargo, no encuentra ninguna consulta de ejecución lenta.

El esclavo está continuamente alertando que la replicación está segundos por detrás del maestro. A veces, el tiempo de retraso aumenta.

¿Cómo diagnostico la causa del problema?

Necesito ayuda urgente, ya que este problema ha persistido durante los últimos 20 días.

El Seconds_Behind_Master es realmente como ver el pasado a través del viaje en el tiempo.

Piénsalo de esta manera:

• El Sol está a 93,000,000 millas de distancia de la Tierra
• La velocidad de la luz es de 186,000 millas / seg.
• La división simple muestra que la luz del Sol tarda aproximadamente 500 segundos (8 minutos 20 segundos) en llegar a la Tierra
• Cuando miras al Sol, en realidad no ves el Sol. Ya ves dónde estaba hace 8 minutos y 20 segundos.

De la misma manera, parece que el Maestro está procesando muchas consultas al mismo tiempo.

Miras hacia atrás al Esclavo, corres SHOW SLAVE STATUS\Gy dice 200 por Seconds_Behind_Master. ¿Cómo se calcula ese número? Hora del reloj del esclavo (UNIX_TIMESTAMP (NOW ()) - TIMESTAMP de la consulta cuando se completó y se registró en el registro binario del maestro.

Hay otra métrica para mirar además Seconds_Behind_Master. Esa métrica se llama Relay_Log_Space. Eso representa la suma de todos los bytes para todos los archivos de retransmisión en el esclavo. Por defecto, el registro de retransmisión individual más grande está limitado a 1 GB. Si Relay_Log_Spacees inferior a 1 GB, esto indica que muchas consultas de larga ejecución se ejecutan en el maestro en paralelo. Desafortunadamente, debido al subproceso SQL de Replication de naturaleza de subproceso único, las consultas se ejecutan una detrás de otra.

Por ejemplo, suponga que tiene el siguiente escenario en el maestro:

• El registro de consulta lenta está habilitado
• 20 consultas ejecutadas en paralelo en el maestro
• Cada consulta tomó 3 segundos
• Cada consulta se registra en el registro binario maestro con la misma marca de tiempo

Cuando el Esclavo lee esas consultas de su registro de retransmisión y las procesa una por una

• el reloj del esclavo se moverá
• el TIMESTAMP para cada una de las 20 consultas será idéntico
• la diferencia aumentará 3 segundos se completará consulta
• esto resulta en 60 segundos para Seconds_Behind_Master

Con respecto al registro lento, el valor predeterminado para long_query_time es de 10 segundos. Si todas sus consultas en los registros de retransmisión son inferiores a 10 segundos, nunca capturará nada en el Registro de consultas lentas.

Tengo las siguientes recomendaciones para los servidores Master y Slave.

• RECOMENDACIÓN # 1 : Actualice a MySQL 5.5 . En MySQL 5.5 y Percona Server 5.1.38+, puede ajustar InnoDB para acceder a múltiples CPU. He escrito publicaciones pasadas sobre esto
  • Apr 26, 2012: ¿El rendimiento de la CPU es relevante para un servidor de base de datos?
  • Sep 20, 2011: Multi núcleos y rendimiento MySQL
  • Sep 12, 2011: ¿Es posible hacer que MySQL use más de un núcleo?
  • May 26, 2011: Acerca del rendimiento de las bases de datos de subprocesos simples o multiprocesos
• RECOMENDACIÓN # 2 : Use InnoDB para todas las tablas . InnoDB almacena en caché datos e índices en RAM, MyISAM solo almacena en caché índices.
• RECOMENDACIÓN # 3 : Aumente la RAM . Debe almacenar en caché más datos e índices tanto en el esclavo como en el maestro
• RECOMENDACIÓN # 4 : Ajuste todas las consultas. La reducción de milisegundos de las consultas que se ejecutan cientos de veces es muy útil Seconds_Behind_Master.

MÁS RESOLUCIÓN DE PROBLEMAS

Si desea ver las consultas que causan el retraso de respuesta, haga lo siguiente:

• SHOW SLAVE STATUS\G
• Obtener el nombre del registro de retransmisión de Relay_Log_File
• STOP SLAVE;
• START SLAVE;
• En el sistema operativo, cd /var/lib/mysqlo donde se escriben los registros de retransmisión
• Volcar el registro de retransmisión a un archivo de texto

Por ejemplo, vamos a hacer SHOW SLAVE STATUS\G

               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.64.51.149
                  Master_User: replicant
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000009
          Read_Master_Log_Pos: 1024035856
               Relay_Log_File: relay-bin.000030
                Relay_Log_Pos: 794732078
        Relay_Master_Log_File: mysql-bin.000009
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB: search_cache
           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: 1024035856
              Relay_Log_Space: 794732271
              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
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 106451149

Si corro STOP SLAVE; START SLAVE;, el registro de retransmisión se cierra y se abre uno nuevo. Sin embargo, tú quieres relay-bin.000030.

Volcar el contenido de la siguiente manera:

cd /var/lib/mysql
mysqlbinlog relay-bin.000030 > /root/RelayLogQueries.txt
less /root/RelayLogQueries.txt

Ahora puede ver las consultas que el Esclavo está tratando de procesar actualmente. Puede usar esas consultas como punto de partida para la optimización.

¿Qué formato de registro binario estás usando? ¿Estás usando ROW o STATEMENT?
" SHOW GLOBAL VARIABLES LIKE 'binlog_format';"

Si está utilizando ROW como formato binlog, asegúrese de que todas sus tablas tengan Clave primaria o única:
SELECT t.table_schema,t.table_name,engine FROM information_schema.tables t INNER JOIN information_schema .columns c on t.table_schema=c.table_schema and t.table_name=c.table_name and t.table_schema not in ('performance_schema','information_schema','mysql') GROUP BY t.table_schema,t.table_name HAVING sum(if(column_key in ('PRI','UNI'), 1,0)) =0;

Si ejecuta, por ejemplo, una declaración de eliminación en el maestro para eliminar 1 millón de registros en una tabla sin una PK o clave única, entonces solo se realizará una exploración completa de la tabla en el lado del maestro, que no es el caso en el esclavo.
Cuando se utiliza ROW binlog_format, MySQL escribe los cambios de las filas en los registros binarios (no como una declaración como STATEMENT binlog_format) y ese cambio se aplicará en el lado del esclavo fila por fila, lo que significa que se realizará un escaneo completo de 1 millón de tablas en el esclavo para reflejar solo una declaración de eliminación en el maestro y eso está causando un problema de retraso del esclavo.

El valor de segundos_detrás_master en SHOW SLAVE STATUS es la diferencia entre la hora del sistema en el maestro, que se almacenó cuando el evento se ejecutó originalmente y se registró en el registro binario ... y la hora del sistema en el esclavo cuando el evento se ejecuta allí.

Los segundos detrás del maestro darán valores incorrectos si los relojes de los dos sistemas no están sincronizados.