Combate real: un artículo te lleva a resolver los errores diarios de la replicación maestro-esclavo de Mysql

Los amigos que han utilizado la base de datos Mysql, deben haber oído hablar de la separación de la lectura y la escritura, y los que escucharon mucho, se estima que sus oídos se han convertido en capullos. Entonces, ¿cómo se logra la separación de lectura y escritura? El método más común es construir una réplica maestro-esclavo de Mysql. La biblioteca principal proporciona operaciones de escritura y la biblioteca esclava proporciona operaciones de lectura, logrando así la separación de lectura y escritura de la aplicación.
Combate real: un artículo te lleva a resolver los errores diarios de la replicación maestro-esclavo de Mysql

Para los recién llegados que recién ingresan al puesto de desarrollo y al puesto de operación y mantenimiento, deben comprender qué es la separación de lectura y escritura y qué problemas comerciales resuelve la separación de lectura y escritura. Solo después de comprenderlos a fondo, pueden utilizar la separación de lectura y escritura. arquitectura.

No hay mucha tontería.
Hablemos de los dos errores más comunes en la replicación maestro-esclavo. El primer tipo: conflicto de clave primaria (Código_error: 1062).
El segundo tipo: pérdida de registros, como operaciones de actualización y eliminación, en la biblioteca esclava. No se pudo encontrar el registro correspondiente (Error_code: 1032)

Simulemos la pérdida de registros en detalle y abordemos todo el proceso.

Verifique si la replicación maestro-esclavo es normal


[root@localhost] 11:34:29 [testdb]>show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.0.1
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000029
          Read_Master_Log_Pos: 3683
               Relay_Log_File: mysql-relay-bin.000003
                Relay_Log_Pos: 2207
        Relay_Master_Log_File: binlog.000029
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

Puede ver que el subproceso IO y el subproceso SQL se ejecutan normalmente.

Cree tablas y registros de prueba

[root@localhost] 11:25:48 [testdb]>show create table test1\G;
*************************** 1. row ***************************
       Table: test1
Create Table: CREATE TABLE `test1` (
  `id` int(11) NOT NULL,
  `name1` char(10) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
  `name2` char(20) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
1 row in set (0.07 sec)

insert into test1 values(1,'test1','test1');
insert into test1 values(2,'test2','test2');
insert into test1 values(3,'test3','test3');

La replicación maestro-esclavo simulada falló debido a la falta de registros en la biblioteca esclava

Paso 1: eliminar el registro con id = 2 de la biblioteca


[root@localhost] 11:26:41 [testdb]>delete from test1 where id=2;
Query OK, 1 row affected (0.44 sec)

[root@localhost] 11:26:52 [testdb]>select * from test1;
+----+-------+-------+
| id | name1 | name2 |
+----+-------+-------+
|  1 | test1 | test1 |
|  3 | test3 | test3 |
+----+-------+-------+
2 rows in set (0.00 sec)

Paso 2: elimine el registro con id = 2 en la base de datos principal

[root@localhost] 11:27:11 [testdb]>delete from test1 where id=2;
Query OK, 1 row affected (0.17 sec)

[root@localhost] 11:27:51 [testdb]>select * from test1;
+----+-------+-------+
| id | name1 | name2 |
+----+-------+-------+
|  1 | test1 | test1 |
|  3 | test3 | test3 |
+----+-------+-------+
2 rows in set (0.00 sec)

Ver la replicación maestro-esclavo en la biblioteca esclava


[root@localhost] 11:34:05 [testdb]>show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.0.1
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000029
          Read_Master_Log_Pos: 3683
               Relay_Log_File: mysql-relay-bin.000003
                Relay_Log_Pos: 1929
        Relay_Master_Log_File: binlog.000029
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 1032
                   Last_Error: Could not execute Delete_rows event on table testdb.test1; Can't find record in 'test1', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log binlog.000029, end_log_pos 3652
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 3405
              Relay_Log_Space: 2414
              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: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1032
               Last_SQL_Error: Could not execute Delete_rows event on table testdb.test1; Can't find record in 'test1', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log binlog.000029, end_log_pos 3652
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 111213106
                  Master_UUID: 3ada166e-c4db-11ea-b21d-000c29cc2388
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State:
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp: 200904 11:33:10
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 3ada166e-c4db-11ea-b21d-000c29cc2388:84830-84835
            Executed_Gtid_Set: 3ada166e-c4db-11ea-b21d-000c29cc2388:1-84834,
3ada166e-c4db-11ea-b21d-000c29cc2389:1-4
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

En este momento, el subproceso sql maestro-esclavo ya se encuentra en un estado detenido y los datos copiados por el maestro-esclavo no están sincronizados. Se informó un error 1032 cuando se inició la copia.

Para resolver el error 1032, puede tener las siguientes 3 soluciones:
Solución 1 : Exporte manualmente los registros comerciales que faltan en la biblioteca principal e impórtelos a la biblioteca esclava, y luego inicie el subproceso sql de la biblioteca esclava. Espere un minuto, ¿ha notado un problema, es decir, en la biblioteca principal, qué registro debe exportarse? No está en el mensaje de error, pero hay una pista, el registro maestro del evento binlog.000029, end_log_pos 3652, entonces También se necesita binlog. Parece un poco complicado analizar el contenido del registro y encontrar el registro que se va a utilizar. Que no cunda el pánico, hay opciones dos y tres.

Solución 2 : la base de datos Mysql proporciona un parámetro slave_skip_errors, este parámetro puede omitir la declaración sql que especifica el código de error, por ejemplo: slave_skip_errors = 1032, desafortunadamente, este parámetro no se puede modificar en línea, la modificación tiene efecto y la instancia debe reiniciarse, es demasiado amigable?


[root@localhost] 11:28:57 [testdb]>set global slave_skip_errors=1032;
ERROR 1238 (HY000): Variable 'slave_skip_errors' is a read only variable

Solución 3 : use la herramienta pt-slave-restart en el conjunto de herramientas percona-toolkits para omitir automáticamente la declaración sql del código de error especificada por la sincronización maestro-esclavo. Este método es menos invasivo para los datos de mysql y no necesita reiniciar el mysql ejemplo


[mysql@mysql ~]$ pt-slave-restart --user=root --password=root --socket=/data/mysql/run/3306/mysql.sock --error-numbers=1032

# A software update is available:
2020-09-04T11:32:07 S=/data/mysql/run/3306/mysql.sock,p=...,u=root mysql-relay-bin.000003        1651 1032

Cuando se omite la declaración sql del código de error especificada por la sincronización maestro-esclavo, después de que se reanude la replicación maestro-esclavo, en un intervalo de 64 segundos, la replicación maestro-esclavo detectará automáticamente si hay un error 1032 nuevamente.

Otros errores similares pueden tratarse con los tres métodos anteriores. Se recomienda que utilice el tercer método.

Supongo que te gusta

Origin blog.51cto.com/15061930/2642093
Recomendado
Clasificación