Estou executando servidores de replicação mestre-escravo do MySQL. Como parte da limpeza de dados antigos, executei uma consulta de exclusão que exclui um grande número de registros do banco de dados. Funcionou bem no servidor mestre, mas no servidor escravo, está me dando o seguinte erro:
A thread SQL do escravo tentou novamente a transação 10 vezes em vão, desistindo. Considere aumentar o valor da variável slave_transaction_retries.
A máquina servidora escrava é menos poderosa que a master. Como posso superar isso?
A consulta é uma consulta de exclusão de linha única. Estou executando o MySQL 5.6.
Você precisa interromper a replicação, fazer com que o Slave tenha as mesmas especificações do Master e, em seguida, iniciar a replicação.
Certifique-se de que o Escravo não tenha conexões de entrada. Caso contrário, isso fará com que o thread SQL no Slave concorra com as conexões de entrada que estão executando
SELECTconsultas na mesma tabela que você está executandoDELETE.Se você não puder redirecionar as conexões de entrada, terá que executar novamente os
DELETEblocos (talvez 5.000 linhas por vez) no Escravo localmente.Como último recurso, reconstrua o escravo (depois de aumentar o hardware e as configurações do escravo).
Existem várias perguntas; Vou tentar cobrir a maioria deles.
A replicação, até recentemente, era de thread único. (Mesmo agora, ele tem limitações de multiencadeamento.) Portanto, era fácil para um mestre fazer muitas coisas em paralelo, mas uma vez que fossem enviados para o escravo e executados em série, o escravo ficaria para trás. Isso é ainda pior se o Escravo tiver um hardware mais lento que o Mestre.
Uma exclusão de linha única que exclui, digamos, um milhão de linhas pode ser executada com SBR ou RBR, dependendo de sua configuração. Os detalhes são visivelmente diferentes:
SBR (Statement Based Replication): Após o Mestre finalizar a exclusão, a instrução é replicada rapidamente. A replicação (assumindo single-threaded) trava até que o Slave possa deletar todos os milhões de linhas. Isso leva tempo. Todos os comandos de replicação subseqüentes ficarão parados e aguardarão; o escravo fica "para trás".
RBR (Row Based Replication): Depois que o mestre termina a exclusão, um milhão de registros de uma linha são bombeados pela rede para o escravo. Isso adiciona sobrecarga. Mas o escravo pode (provavelmente) executar as exclusões mais rapidamente devido à simplicidade do fluxo. Ainda assim, a replicação ficará presa por um período de tempo não trivial, durante o qual o Escravo estará "atrasado".
Nenhuma quantidade de hardware pode evitar ficar "para trás".
Enquanto isso, qualquer um
SELECTsno Slave que esteja atingindo aquela mesa é um pouco impactado, e vice-versa. Ou seja,SELECTspode retardar a exclusão.Exclusões grandes são um problema comum. Meu blog descreve várias soluções. Inclui detalhes sobre como fazer o "chunking" que Rolando sugeriu.
Se você "chunk" e fizer de cada chunk sua própria transação, haverá menos impacto tanto no Master quanto no Slave. A desvantagem é que uma falha pode deixar a tabela com alguns pedaços excluídos, outros não. (Executar novamente a exclusão em partes provavelmente será simples e seguro.)
Presumo o tamanho (portanto, a duração) do lead de exclusão para a mensagem de erro.
Observe que uma das sugestões em meu blog é... Se "a maior parte" da tabela estiver sendo excluída, copie as linhas a serem mantidas e renomeie para trocar as tabelas. Muito mais rápido etc