Binario De MySQL Registro De Replicación:Puede ser configurado para ignorar los errores?

Question

Estoy corriendo un maestro-esclavo binario de MySQL registro de sistema de replicación (¡uf!) que, para algunos datos, no está en modo de sincronización (es decir, el maestro contiene más datos que el esclavo).Pero el esclavo deja muy frecuentemente en el más mínimo error MySQL, este puede ser deshabilitado?(tal vez un mi.cnf configuración para replicar el esclavo ignorar-réplica-de los errores o de algunos de la especie ;) )

Esto es lo que sucede, cada ahora y entonces, cuando el esclavo intenta replicar un elemento que no existe, el esclavo muere.una comprobación rápida 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 pronto me revisión (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 de conseguir una especie de molesto, y antes de escupir una cierta clase de PHP que lo hace por mí, me preguntaba si hay algo de mi.cnf entrada que no va a matar a los esclavos en el primer error.

Saludos,

/mp

Answer 1

Sí, con --esclavo-skip-errores=xxx en mi.cnf, donde xxx es el 'todo' o una coma sep lista de códigos de error.

Answer 2

dejar de esclavo;set global sql_slave_skip_counter=1;start slave;

Usted puede ignorar sólo el error actual y continuar con el proceso de replicación.

Answer 3

Primero, ¿de verdad quieres ignorar los errores?Si recibe un error, es probable que los datos no está en la sincronización de más.Tal vez lo que desea es dejar a los esclavos de la base de datos y reiniciar el proceso de sincronización cuando usted obtiene un mensaje de error.

Segundo, creo que el error que está recibiendo no es al replicar un elemento que no existe (¿qué significaría eso de todos modos?) - parece que se están replicando un elemento que ya existe en el esclavo de la base de datos.

Sospecho que el problema principalmente surge de no partir de una limpia de copia de datos.Parece que el maestro ha sido copiado al esclavo;a continuación, la replicación se ha apagado (o no);y, a continuación, se ha puesto en marcha de nuevo, pero sin dar el esclavo la oportunidad de ponerse al día con lo que se perdió.

Si alguna vez tienes un tiempo cuando el maestro puede ser cerrado para el acceso de escritura el tiempo suficiente para clonar la base de datos y la importación en el esclavo, este podría conseguir que los problemas desaparezcan.

Answer 4

Moderno mysqldump los comandos tienen un par de opciones para ayudar con la creación constante de replicación.Echa un vistazo --master-data que va a poner el log binario del archivo y su posición en el vertedero y establece automáticamente cuando se carga al esclavo.También --single-transaction va a hacer el volcado dentro de una transacción, de modo que ninguna de bloqueo de escritura que es necesario hacer una constante de volcado.

Answer 5

Si el esclavo no se utiliza para cualquier escribe distinto de la replicación, los autores de Alto Rendimiento de MySQL recomienda la adición de read_only en el servidor esclavo para evitar que los usuarios erróneamente cambiar los datos en el esclavo como este es también crear los mismos errores que has experimentado.

Answer 6

creo que se están haciendo de replicación con la sincronización de la base de datos de sincronización de la base de datos y prueba para la replicación y los servidores están generando los mismos identificadores únicos y tratar de establecer auto incerment offset