Replicación de registro binario MySQL: ¿se puede configurar para ignorar los 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? (quizás una configuración my.cnf para el esclavo replicante ignore-replicating-errors o algo por el estilo;))

Esto es lo que sucede, de vez en cuando, cuando el esclavo intenta replicar un elemento que no existe , el esclavo simplemente muere. una comprobación rápida al 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 rápidamente FIX (una vez que me di cuenta de que el esclavo se ha detenido) de la siguiente manera:

STOP SLAVE; 
RESET SLAVE; 
START SLAVE; 

... últimamente esto ha sido cada tipo de tedioso, y antes Escupí algún 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.

Saludos,

/mp

Answer 1

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

Answer 2

En primer lugar, lo que realmente quiere hacer caso omiso de 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á recibiendo no es cuando replica un elemento que no existe (¿qué significa eso de todos modos?) - parece que está replicando un elemento que ya existe en la base de datos esclava.

Sospecho que el problema se debe principalmente a no comenzar con 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 puede cerrarse 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

Los comandos modernos mysqldump tienen un par de opciones para ayudar a configurar la replicación consistente. Consulte --master-data que colocará el archivo de registro binario y la posición en el volcado y se establecerá automáticamente cuando se cargue en el esclavo. También --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 4

Si el esclavo no se utiliza para escrituras que no sean la replicación, los autores de alto rendimiento 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á el mismo errores que experimentaste

Answer 5

Creo que está haciendo la replicación con sincronización a cabo la base de datos sincronizar la base de datos primero y tratar de replicación y servidores están generando mismos identificadores únicos y tratar de establecer incerment automático compensado

Answer 6

parada de esclavos; establecer global sql_slave_skip_counter = 1; iniciar esclavo;

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