Em arquiteturas de alta disponibilidade MySQL, a replicação primária de banco de dados é um tipo muito comum.
Quando o banco de dados primário cai do ar, você pode atualizar um banco de dados escravo como um novo banco de dados primário para garantir a disponibilidade do serviço. Ao mesmo tempo, o QPS de todo o cluster pode ser melhorado estendendo a biblioteca de escravos.
Sob a arquitetura de replicação mestre-escravo, o MySQL usa binlog para alcançar consistência de dados mestre-escravo.
Como mostrado na figura acima, a replicação mestre-escravo do MySQL tem principalmente os seguintes passos
1. Master loga as alterações no log binário
2. O escravo io_thread solicitar o binlog da biblioteca principal e escrever o binlog resultante no log de relé
3. Eventos de refazer sql_thread escravos no registro de retransmissão
Além de servir como link para replicação mestre-escravo do MySQL, o binlog também serve a outros propósitos. Como o quê:
1. Use a ferramenta mysqlbinlog para analisar o arquivo binlog e realizar a recuperação de banco de dados em um momento no tempo.
2. Flashback do banco de dados baseado em eventos binlog (o MariaDB pode usar diretamente mysqlbinlog para flashback)
3. A ferramenta de alteração de tabelas online de código aberto do Github, gh-ost, também é implementada via binlog
4. Você também pode se inscrever e consumir incrementalmente analisando binlogs
O binlog é muito útil, mas é inevitável que você encontre alguns problemas no processo diário de operação e manutenção. Aqui estão alguns erros relacionados ao binlog.
Uma das perguntas mais frequentes
Fenômeno
MySQLBINLOG5.5 analisa o arquivo binlog MySQL5.7 aparece
ERROR: Error in Log_event::read_log_event(): 'Sanity check failed', data_len: 31, event_type: 35ERROR: Could not read entry at offset 123: Error in log format or read error.
Análise da causa
MySQL 5.6 e outras versões superiores dos arquivos binlog adicionaram novos eventos binlog, como eventos GTID.
MySQLBINlog no MySQL5.5 não reconhece tais eventos binlog.
Solução alternativa
Use a versão superior do mysqlbinlog para resolver o binlog gerado pela versão inferior do mysql
Pergunta frequente dois
Fenômeno
Um servidor Mysql saudável mostra status de escravo
Last_SQL_Error: Falha na leitura do log de relé: Não foi possível analisar a entrada do evento do log de relé.
As possíveis razões são: o log binário do mestre está corrompido (você pode verificar isso rodando 'mysqlbinlog' no log binário),
O registro de relé do escravo está corrompido (você pode verificar isso rodando 'mysqlbinlog' no registro de relé),
um problema de rede, ou um bug no código MySQL do mestre ou do escravo.
Se quiser verificar o log binário do mestre ou o log de relé do escravo,
você poderá saber seus nomes emitindo 'MOSTRAR STATUS DE ESCRAVO' sobre esse escravo.
Análise da causa
As entradas no registro de retransmissão não podem ser lidas devido a erros de binlog na biblioteca master, erros de log de retransmissão na biblioteca escrava, ou problemas e bugs de rede. Geralmente é causada por uma falha na rede ou pressão excessiva sobre a biblioteca escrava, resultando em um formato incorreto do registro de relé.
Solução alternativa
Após encontrar o ponto atual de sincronização e resetar a sincronização mestre-escravo, um novo log de relé será gerado e a sincronização mestre-escravo será restaurada.
A partir do resultado de "mostrar status de escravo\G", encontre as seguintes informações:
Relay_Master_Log_File: mysql-bin.002540 // O binlogExec_Master_Log_Pos do mestre lido pela biblioteca escrava: 950583017 // O ponto de posição que foi executado no escravo
Pare o escravo e defina a sincronização novamente, começando pelo arquivo binlog que o escravo leu e pela posição que foi executada.
Relay_Master_Log_File: mysql-bin.002540 // O binlogExec_Master_Log_Pos do mestre lido pela biblioteca escrava: 950583017 // O ponto de posição que foi executado no escravo
Pergunta frequente três
Fenômeno
Restaurar o status de escravo após erro de inatividade:
Last_SQL_Error: Erro inicializando a posição do log do relé: erro de I/O ao ler o cabeçalho do log binário
Last_SQL_Error: Erro inicializando a posição do log do relé: Binlog tem número mágico ruim; Não é um arquivo de log binário que pode ser usado por esta versão do MySQL
Análise da causa
Tempo de inatividade, como queda de energia, queima na placa-mãe, etc., ou desligamento ilegal, resultando em corrupção do arquivo do relé-bin
Solução alternativa
Mesma pergunta em segundo.
relay_log_recovery = 1 também pode ser definido.
Quando o escravo cai da biblioteca, se o log de relé for corrompido e parte do log de relé não for processada, o log de relay é automaticamente abandonado e o log é recuperado novamente do master, completando a recuperação do log de relé.
Pergunta frequente quatro
Fenômeno
Aparece quando muda o master para depois que uma reinicialização da máquina da biblioteca cai
Erro (Código 1201): Não foi possível inicializar a estrutura de informações mestre; mais mensagens de erro podem ser encontradas no registro de erro do MySQL
ou
ERRO 1872 (HY000): O escravo falhou em inicializar a estrutura de informações do log do relé a partir do repositório
Análise da causa
Tempo de inatividade, como queda de energia, queima na placa-mãe, etc., ou desligamento ilegal, causando danos a arquivos master.info ou realy-log.info
Solução alternativa
escravo> resetar escravo tudo, mudar mestre para
Medidas preventivas
Configurações de perfil
relay_log_info_repository=tabela
master_info_repository=tabela
O mecanismo de armazenamento do MySQL 5.6.5 mysql.slave_master_info e mysql.slave_relay_log_info está configurado para o MyISAM por padrão, e você precisa mudá-lo para o mecanismo de armazenamento do InnoDB
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info tabela será atualizada após sync_master_info eventos.
mysql.slave_relay_log_info tabela será atualizada a cada commit de transação.
Pergunta frequente 5
Fenômeno
O master slave binlog_format originalmente uma instrução, após mudar a binlog_format principal do banco de dados para row, mostrar status do slave aparece na biblioteca:
Last_Error: Erro ao executar evento de linha: 'Não é possível executar a instrução: impossível escrever em log binário, pois a instrução está em formato de linha e BINLOG_FORMAT = STATEMENT.'
Análise da causa
Quando a binlog_format principal do banco de dados é a linha, e a binlog_format da biblioteca escrava é a instrução, o erro acima aparecerá.
Mas a biblioteca principal binlog_format é a declaração, e a biblioteca escrava binlog_format fileira;
Ou, se a binlog_format principal do banco de dados for linha, o erro não será reportado se a binlog_format do banco de dados estiver mista.
Se o seu thread SQL estiver realmente configurado com
binlog_format=STATEMENT: uma vez que recebe um evento ROW, ele para. O
razão é que não seria possível registrar esse evento ROW no formato STATEMENTformat (às vezes chamamos isso de injeção ROW, que é ou um
Instrução BINLOG ou um evento ROW executado pela thread SQL do escravo)
Referência detalhada do motivo:https://bugs.mysql.com/bug.php?id=69095
Solução alternativa
ESCRAVA> ESCRAVA;
ESCLAVO> CONJUNTO GLOBAL binlog_format=MISTO;
ESCRAVO> ESCRAVO INICIAL;
Pergunta frequente número 6
Fenômeno
Erro ao sincronizar mysql5.6 para mysql5.5
Last_IO_Error: Recebi erro fatal 1236 do mestre ao ler dados do log binário: 'O escravo não consegue lidar com eventos de replicação com a soma de verificação que o mestre está configurado para logar; o primeiro evento 'mysql-bin.000001' às 4, o último evento lido de 'mysql-bin.000001' às 120, o último byte lido de 'mysql-bin.000001' às 120.'
Análise da causa
Para resolver o problema de que as instruções SQL rodando no servidor principal são inconsistentes com as instruções SQL rodando no servidor (chamado de evento corrupto) devido a erros de software e hardware ou transmissão de rede, o MySQL 5.6 adiciona a função de Checksum de Evento de Replicação. Quando um evento é gravado no log binário, a soma de verificação também é gravada no log binário e, após o evento ser transmitido ao escravo pela rede, ele é verificado no escravo e gravado no log de relé do escravo. Como eventos e somas de verificação são registrados a cada etapa, podemos rapidamente descobrir qual é o problema.
No mysql5.6.5 e versões posteriores binlog_checksum o valor padrão é crc32,
O valor padrão binlog_checksum versão anterior era nenhum
solução
Slave> definir global binlog_checksum=nenhum
Pergunta frequente 7
Fenômeno
Depois que o disco estiver cheio, limpe manualmente o arquivo binlog e o arquivo mysql-bin.index
Os logs binários de mostrar estão vazios, mas o status de mostrar mestre está normal.
mysql> mostrar logs binários; Conjunto vazio (0,00 seg)mysql> mostrar status mestre;
+------------------+-----------+--------------+------------------+
| Arquivo | Posição | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Análise da causa
Depois de checar o arquivo mysql-bin.index, encontrei a primeira linha em branco.
No código-fonte do mysql rpl_master.cc:show_binlogs() você encontrará o seguinte código:
/* The file ends with EOF or empty line */
enquanto ((comprimento=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Linhas em branco são consideradas o final do documento
(Referência.)https://yq.aliyun.com/articles/213657Artigo)
Medidas preventivas
Não delete binlog manualmente, não edite manualmente o arquivo mysql-bin.index, a menos que você saiba o que está fazendo, senão pode acabar colocando minas para si mesmo!
resumo
DBAs precisam prestar atenção às melhorias no binlog em cada nova versão do MySQL (como o recurso gtid adicionado na versão 5.6, Enhanced Multi-threaded Slaves na versão 5.7), e entender o significado de cada parâmetro em detalhes, para que possam entender o que eles querem dizer quando encontram erros e resolvem problemas facilmente.
|
Publicado em 25/09/2018 10:31:40
|
|
|
|
