errores - log de accesos a mysql

Replicación de registro binario de MySQL: ¿se puede configurar para ignorar errores?

Question

Estoy ejecutando un sistema de replicación de registro binario MySQL maestro-esclavo (phew!) Que, para algunos datos, no está sincronizado (es decir, el maestro tiene más datos que el esclavo). Pero el esclavo se detiene con mucha frecuencia en el más mínimo error de MySQL, ¿se puede deshabilitar? (tal vez una configuración my.cnf para el esclavo de replicación ignorar-replicar-errores o algo así;))

Esto es lo que sucede, de vez en cuando, cuando el esclavo intenta replicar un objeto que no existe, el esclavo simplemente muere. un control rápido en SHOW SLAVE STATUS / G; da

       Slave-IO-Running: Yes
      Slave-SQL-Running: No
        Replicate-Do-DB: 
             Last-Errno: 1062
             Last-Error: Error ''Duplicate entry ''15218'' for key 1'' on query. Default database: ''db''. Query: ''INSERT INTO db.table ( FIELDS ) VALUES ( VALUES )''

que corrijo rápidamente (una vez que me doy cuenta de que el esclavo ha sido detenido) haciendo lo siguiente:

STOP SLAVE;
RESET SLAVE;
START SLAVE;

... últimamente esto se ha vuelto tedioso, y antes de escupir un tipo de PHP que hace esto por mí, me preguntaba si hay alguna entrada my.cnf que no mate al esclavo en el primer error.

Aclamaciones,

/ mp

Answer 1

Los comandos modernos de mysqldump tienen un par de opciones para ayudar a configurar la replicación consistente. Verifique --master-data que colocarán el archivo de registro binario y la posición en el volcado y se establecerán automáticamente cuando se carguen en el esclavo. Además, --single-transaction hará el volcado dentro de una transacción para que no se necesite un bloqueo de escritura para hacer un volcado consistente.

Answer 2

Primero, ¿realmente quieres ignorar los errores? Si obtiene un error, es probable que los datos ya no estén sincronizados. Quizás lo que desea es eliminar la base de datos esclava y reiniciar el proceso de sincronización cuando se produce un error.

En segundo lugar, creo que el error que está obteniendo no se produce cuando se replica un elemento que no existe (¿qué significaría eso de todos modos?) - parece que está replicando un elemento que ya existe en la base de datos esclava.

Sospecho que el problema surge principalmente de no comenzar en una copia de datos limpia. Parece que el maestro ha sido copiado al esclavo; luego la replicación se ha desactivado (o ha fallado); y luego ha comenzado de nuevo, pero sin darle al esclavo la oportunidad de ponerse al día con lo que se perdió.

Si alguna vez tiene un momento en que el maestro se puede cerrar para el acceso de escritura el tiempo suficiente para clonar la base de datos e importarla en el esclavo, esto puede hacer que los problemas desaparezcan.

Answer 3

Sí, con --slave-skip-errors = xxx en my.cnf, donde xxx es ''todo'' o una lista separada de códigos de error.

Answer 4

Si el esclavo no se usa para ninguna escritura que no sea la replicación, los autores de High Performance MySQL recomiendan agregar read_only en el servidor esclavo para evitar que los usuarios modifiquen erróneamente los datos en el esclavo, ya que esto también creará los mismos errores que experimentó.

Answer 5

Creo que está haciendo la replicación sin sincronizar la base de datos, primero sincroniza la base de datos y trata de replicar, y los servidores están generando los mismos identificadores únicos y tratando de establecer el ajuste de incerment automático.

Answer 6

detener esclavo; establecer global sql_slave_skip_counter = 1; iniciar esclavo;

Puede ignorar solo el error actual y continuar el proceso de replicación.