Tenho um banco de dados em execução em nosso servidor da Web de produção que configurei como mestre com um único escravo em outro datacenter. Ao ler as instruções de configuração de replicação do MySQL, eles aconselham colocar o servidor off-line, colocar um bloqueio de leitura, fazer o dump e, em seguida, criar o escravo com ele. Fiz isso, configurei a replicação e ficamos felizes.

Hoje decidi que ter essa replicação em claro na WAN provavelmente não é uma boa prática. Então, procurei configurar a replicação por meio de um túnel SSH (temporário). Isso exigiu que eu mudasse master_hostpara 127.0.0.1 em vez do IP do meu mestre. Ao fazer isso, interrompi minha replicação e agora tenho que começar de novo. O problema é que o Master só tinha expire_logs_days=1, então não posso repetir o processo original desde a semana passada. Eu tenho backups dos outros binlogs, mas usar mysqlbinlog para restaurar todos eles continua falhando devido a problemas de tabelas temporárias.

Portanto, agora estou tentando obter o backup do escravo e executá-lo sem derrubar o mestre. A cada 3 horas, no mestre, fazemos um dump do banco de dados para backups. Usamos mysqldump -v --flush-logs --single-transaction --routines ....para que o log binário atual seja cortado e um novo seja criado a cada backup que fazemos. No entanto, se eu restaurar um despejo de banco de dados e tentar iniciar o backup de replicação com o novo log binário que foi criado com o último --flush-logs comando, ainda me deparo com colisões de chave, exatamente como eles avisaram.

Dadas essas informações, existe uma maneira de iniciar com êxito o backup do escravo com os despejos que temos sem desativar o servidor novamente? Não estarei em um bom lugar se tiver que pedir mais tempo de inatividade.