Início / dba / Perguntas / 18031
Accepted
Jim Dennis
Asked: 2012-05-17 17:15:31 +0800 CST

Usando um nome de arquivo binlog MySQL mais antigo (com posição zero)? Riscos? Desvantagens?

  • 772

Digamos que estou configurando um novo slave. Eu começo com um mysqldump depois de executar mysql -e "STOP SLAVE", transfiro e restauro para o novo servidor.

Se eu não capturei o nome do arquivo BINLOG e a posição após STOP SLAVE e antes de executar o mysqldump, o que acontece se eu simplesmente usar um nome de arquivo binlog anterior/mais antigo (verificado para estar presente no mestre e mais antigo que o backup), com um posição de zero?

Parece apenas forçar o novo mestre a reproduzir todos os eventos para o novo escravo, obviamente incluindo uma série de INSERTs, UPDATEs e DELETEs que já foram representados no backup (aqueles que aconteceram durante o período de tempo sobreposto).

Há algo de errado ou arriscado nisso? Existe uma desvantagem além do tempo extra desperdiçado e dos ciclos de CPU (repetindo talvez um dia inteiro de transações sobrepostas)?

mysql restore

2 respostas

  1. Best Answer

    eu tenho uma surpresa para você

    Cada posição dentro de um log binário é baseada no tamanho do arquivo do log binário a partir do momento em que uma instrução SQL foi escrita.

    O que é ainda mais interessante sobre esse conceito é o fato de que o cabeçalho dos logs binários difere na posição inicial (não existe uma posição literal 0)

    Estes são os pontos de partida para a replicação do log binário vazio de um mestre

    • 107 para MySQL 5.5
    • 106 para MySQL 5.1
    • 98 para MySQL 5.0 e de volta

    Escrevi sobre isso pela primeira vez em 4 de fevereiro de 2011

    Aqui está um curso de ação sugerido

    • Se os logs de retransmissão ainda existirem no Escravo
      • encontre o último log de retransmissão
      • executar mysqlbinlogcontra esse log de retransmissão
      • localize o timestamp do momento em que você executou o mysqldump
      • Pegue esse carimbo de data/hora e localize o mesmo carimbo de data/hora nos logs binários do mestre\
      • Perto da cópia do mestre do carimbo de data/hora no apropriado deve estar a posição
      • Qualquer que seja o log binário mestre que você selecionou, use esse log binário no CHANGE MASTER TOcomando no Slave
      • Qualquer que seja a posição que você encontrou no log binário mestre que você selecionou, use essa posição no CHANGE MASTER TOcomando no Slave

    Essa é a melhor maneira de minimizar qualquer colisão de dados devido a chaves duplicadas

    Só para ter certeza, no Slave adicione isso ao my.cnf

    [mysqld]
slave-skip-errors=1062

    Em seguida, reinicie o mysql. Isso ignorará todas as colisões de chaves duplicadas após a execução START SLAVE;. Quando Seconds_Behind_Master atingir 0, remova essa linha e reinicie o mysql no Slave. Tudo em termos de replicação do MySQL deve estar bem a partir daí.

    • 2

  2. Riscos/desvantagens, especialmente se estiver usando replicação baseada em instrução:

    • inserir na tabela (pk_auto_inc_col, value_column) valores (null, 123); Nenhuma colisão lá, apenas criará um registro duplicado. As inserções subsequentes agora são todas deslocadas
    • atualizar tbl set col=col+1; O valor col é incrementado novamente
    • 1

relate perguntas