Traduzido do 日本語 • Ver original Olá. Aqui é a Komiya.
Este é um registro do erro que surgiu anteriormente.
・Registro de erro
>mostrar status de escravo\G
Last_Error: Erro 'Entrada duplicada '1133523-2013-08-18 05:03:01' para a chave 'PRIMARY'' na consulta. Banco de dados padrão: '*****'. Consulta: 'INSERIR em 'event_****_logs' ...
Parece ser um erro que parece uma duplicação porque o tempo é a chave primária.
Sinto que logs e sessões são fáceis de duplicar.
Olhei a opção mysqldump só por precaução, mas
--skip-opt não está incluído, então --add-drop-table deve ser válido para que o opt seja arbitrário.
MYDUMP_PAR='--transação única --dump-slave=2 --rotinas --inclui-porta-mestre-host--todos os bancos de dados'
http://dev.mysql.com/doc/refman/5.5/en/mysqldump.html
Não parecia haver problema com o procedimento, como resetar o escravo após a entrada dos dados e iniciar o escravo de acordo com o arquivo de log e a posição.
Quando pedi ao cliente para confirmar se estava tudo bem pular todas as entradas duplicadas.
Se é aceitável que a chave primária seja coberta pelo Insert será confirmada separadamente pelo lado do desenvolvimento, e por enquanto, é uma história de pular.
(Acho que era prioridade restaurar porque o alvo não queria ser usado no serviço.) Se você está preocupado com inconsistências, é melhor refazer o dump do master. ）
・Como pular uma consulta de erro
Se houver apenas um,
CONJUNTO SQL_SLAVE_SKIP_COUNTER GLOBAL = 1;
Mas se vier cheio
Último_SQL_Errno: 1062
Especifique esse número de erro e pule. Isso significa que todas as entradas duplicadas serão puladas.
Se o perconatoolkit estiver incluído
pt-slave-restart -u raiz -p'cat /raiz/.mysql_pwd' --números-de-erro 1062 --verboso
Ele sai como saída padrão, então se você redirecionar, pode ver a consulta pulada depois.
Se não estiver incluído,
Também existe uma forma de escrever em my.cnf da seguinte forma. (Reiniciar mysqld necessário)
erros-pulo-escravos=1062
http://fr.slideshare.net/billkarwin/percona-toolkit
http://jitsu102.hatenablog.com/entry/2012/03/08/073448
Houve casos em que dados como logs e sessões foram duplicados em outros projetos.
Se quiser refazer o dump, pode ser uma boa ideia travar para que ele não receba atualização, esperar alguns segundos e confirmar a posição antes de tirar a foto.
Mesmo que você use --single-transaction no InnoDB, parece que pode haver duplicados.
Pensei sobre isso, mas descobri toda a história desse incidente, então vou registrar também.
Na verdade, em vez de olhar para o conteúdo dos dados de dump para arquivos de log binários e posições,
Depois de travar, mostrei o status de mestre manualmente; Depois disso, eu estava fazendo cocô,
Os dados de dump de cerca de 11 consultas que haviam sido sutilmente atualizadas eram novos, então foram duplicados! Era isso mesmo.
cabeça -30 dumpdata ou zcat dumpdata.gz|cabeça -30 parece ser inútil.
---masta-data Se você está despejando, deveria dar uma boa olhada.
*Se você adicionar --masta-data, a instrução CHANGE MASTER será registrada no início dos dados de dump.
Se for 1, será executado, e se for 2, será um comentário. Quando os dados foram realocados, foram definidos para 2 para evitar que fossem para o mestre antigo.
Obrigado por assistir ao que foi dito acima.