Geralmente, erros de replicação como esse são causados por inconsistências de dados entre o mestre e o escravo - a restrição foi obviamente satisfeita no mestre, já que a consulta foi bem-sucedida, mas não no escravo.
Nesse ponto, todo o seu banco de dados (escravo) se torna suspeito. Você pode rastrear a inconsistência específica e corrigi-lo manualmente, mas como você sabe que é o único? O mais seguro é iniciar um novo escravo e, assim que a replicação for alcançada, mate a antiga.
No entanto, isso só conserta o sintoma; você precisa considerar como a escrava ficou fora de sincronia com o mestre em primeiro lugar. De longe, o problema mais comum é a execução de comandos de modificação (ou seja, não SELECT
) no escravo. Infelizmente, você não pode desabilitar isso completamente, pois o processo de replicação do MySQL precisa de privilégios de gravação, mas você pode auditar quem tem privilégios. Todo ser humano que tem acesso de consulta ao escravo precisa saber que ele não deve executar UPDATE
s (e, idealmente, limitar suas permissões para que elas não possam ). Cada pedaço de código que fala com o escravo da mesma forma precisa fazer SELECT
s.
Outra causa possível é que o processo usado para criar o conjunto de dados inicial do escravo (por exemplo, trazendo-o de um backup do mestre) é falho e começou com uma inconsistência antes mesmo de a replicação começar.