mysql 5.6 gtid esclavo de replicación atascado (sistema de bloqueo)?

Question

He configurado 5.6 gtid basado en la replicación (en 5.6.26) parecía funcionar cuando lo hice, replica mi prueba al azar db más que he creado junto a los datos normales.Sin embargo, en algún punto algo debe haber sucedido porque todo lo que veo es esto:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: System lock
                  Master_Host: xxxxxxxxxxxxxxxxxx
                  Master_User: xxxxxxxxxxxxxxxx
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysqld-bin.000141
          Read_Master_Log_Pos: 169293671
               Relay_Log_File: mysqld-relay-bin.000003
                Relay_Log_Pos: 16861206
        Relay_Master_Log_File: mysqld-bin.000141
             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: 16860994
              Relay_Log_Space: 169298584
              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: 55203
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: 1
                  Master_UUID: 7846a847-62c7-11e5-91a6-e06995de432e
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: System lock
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:4757140-5030085
            Executed_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:1-4783274
                Auto_Position: 1

ahora originalmente "Slave_SQL_Running_State", dijo el "evento de lectura de registro de la retransmisión" o algo así, ahora se ha cambiado el sistema de bloqueo (IO estado siempre dijo que).

Parece que el Seconds_Behind_Master está en constante aumento, y el registro de la retransmisión crece rápidamente en tamaño en el sistema de archivos, mientras Executed_gtid_set no parece cambiar, pero aún así algo me parece mal porque es mucho detrás....

Aquí está el processlist:

mysql> show processlist;
+------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+
| Id   | User        | Host      | db   | Command | Time  | State                                 | Info             |
+------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+
| 1877 | root        | localhost | NULL | Sleep   |  6076 |                                       | NULL             |
| 1878 | root        | localhost | NULL | Query   |     0 | init                                  | show processlist |
| 1886 | system user |           | NULL | Connect |   783 | System lock                           | NULL             |
| 1887 | system user |           | NULL | Connect |     0 | System lock                           | NULL             |
| 1888 | system user |           | NULL | Connect |   783 | Waiting for an event from Coordinator | NULL             |
| 1889 | system user |           | NULL | Connect | 55455 | System lock                           | NULL             |
+------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+

He intentado dejar el esclavo y empezar de nuevo, pero no ayuda.

¿Alguien tiene alguna idea de lo que podría tratar de hacer que esto funcione de nuevo?Sería muy apreciada.

Gracias

Answer 1

Ya veo a más de 2 system user las entradas en el processlist, quiero suponer que usted está utilizando Multi-Roscado de Replicación (slave_parallel_workers > 1).

Que parece un bug

• Error #73066 :La replicación de ducha con multi-roscado de replicación
• Error #72794 :Registro de la retransmisión sin xid_log_event puede caso paralelo de replicación de colgar

En Octubre 29, 2014, esto fue expresado por David Moss

Gracias por sus comentarios.Este tema fue cubierto en el bug 17326020 y el siguiente se agregó a la de MySQL 5.6.21 y 5.7.5 changelogs:

Cuando el subproceso de e/S se vuelven a conectar a un maestro en el uso de GTIDs y multiproceso esclavos, mientras que en el medio de una transacción, no para anular la transacción, dejando un parcial de transacciones en el relé de registro y, a continuación, recuperar la misma transacción de nuevo.Esto ocurrió cuando se realiza una rotación de la retransmisión de registro.Ahora al volver a conectar, el servidor comprueba antes de girar el registro en tales casos, y espera primero para cualquier curso de la transacción finalice.

Por lo tanto, nada nuevo será añadido a la cubierta de este error y estoy cerrando como fijo.

On Dec 10, 2014, esto fue expresado por Laurynas Biveinis

Problema:

Con MTS, GTIDs y auto posicionamiento habilitado, cuando un trabajador se aplica un transacción parcial a la izquierda en relaylog por un IO hilo de reconexión, se se espera para el XID de registro de eventos para confirmar la transacción.

Por desgracia, el subproceso SQL coordinador de llegar a la maestría GIRE evento en el siguiente relaylog de archivo y esperar a que todos los trabajadores para terminar sus tareas antes de la aplicación de la rotación.

Análisis:

Como toda la transacción se recupera de nuevo por el IO hilo después de la la reconexión, el esclavo debe deshacer la transacción parcial una vez darse cuenta de este ROTAR desde el maestro.

Este error se informa de la misma cuestión ya ha sido corregido por el BUG#17326020, y el informó problema no es reproducible más.Así, este parche es solo la adición de un nuevo caso de prueba.

SUGERENCIA

Ejecutar FLUSH BINARY LOGS; en el Maestro

A ver si el movimiento desencadena una respuesta de los subprocesos SQL.

Si no, vaya por delante y eliminar slave_parallel_workers de my.cnf y reiniciar mysql.

Desde que comenzó a MySQL y el maestro y el esclavo y consiguió error 1236, que significa que usted está tratando de establecer la replicación de una posición imposible.En el contexto de GTID y el mensaje de error que tienes, los registros binarios necesarios para la completa identificación de un conjunto de consultas dentro de un GTID conjunto ya no existe,

Mirar hacia atrás en tu SHOW SLAVE STATUS\G

Retrieved_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:4757140-5030085
 Executed_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:1-4783274

A partir de este, el último GTID ejecutado es 7846a847-62c7-11e5-91a6-e06995de432e:4783274

Esto significa que el registro binario que tiene o ha tenido 7846a847-62c7-11e5-91a6-e06995de432e:4783275 ya no existe.

Puedo ver que esto sucede si usted detiene la replicación en el Esclavo, a la izquierda de la replicación fuera el tiempo suficiente para que el Maestro girar sus registros binarios (a través de expire_logs_days) el esclavo todavía necesitaba ver, luego se convirtió en la replicación.

En su caso particular, trate de hacer un mysqlbinlog volcado del registro binario mysqld-bin.000141.Si no sale nada de ella, tendrá que volver a cargar el Esclavo y la configuración de la replicación de cero.