I. Introdução
Nos últimos dias on-line, houve um problema de que os dados não podem ser encontrados após a conclusão da operação comercial. A princípio, pensei que a verificação chamava a verificação de outras localizações de documentos. Posteriormente, levei o SQL para o mestre banco de dados e o banco de dados escravo para verificar. A biblioteca não tem dados e está atrasada por mais de uma hora.
Dois, investigação
Mysql5.7 é usado online, em modo semi-síncrono. Ao se comunicar com dba, pensei que fosse o modo síncrono no início, e depois o backup físico do banco de dados standby leva quatro horas todas as manhãs. Quando o banco de dados principal tem ddl, o banco de dados standby Travado, o sistema não leu os dados da biblioteca.
Aqui estão algumas perguntas: ① Como o banco de dados de backup pode ser usado para alta disponibilidade apenas uma vez por dia no início da manhã? Não deveria ser sincronização em tempo real?
②A biblioteca principal tem ddl. Uma vez que ainda pode responder às gravações do sistema, isso significa que os dados do binlog ainda estão sendo atualizados. A biblioteca escrava é sincronizada através do binlog. Por que não há dados?
Então conversamos sobre isso novamente. A estrutura real é a seguinte:
Como preparação para alta disponibilidade, a biblioteca principal 2 sincroniza a biblioteca principal em tempo real. Quando a biblioteca principal estiver inativa, ela se tornará a biblioteca principal. Normalmente, um arquivo de backup físico será gerado no início da manhã para restaurar os dados para o dia anterior quando há um problema.
Embora log_slave_update esteja ativado, a biblioteca slave também registrará binlog, que pode ser usado para sincronização em cascata, mas na verdade o atraso será relativamente grande e o dba ainda será configurado para puxar a biblioteca principal. O log binário da biblioteca escrava pode ser sincronizado com ferramentas como data warehouses e Flink.
A biblioteca principal 2 também é usada como parte da leitura. O motivo do atraso real é: quando o sistema lê os dados, o nome de domínio de leitura muda para a biblioteca principal 2 e a biblioteca principal 2 está fazendo backup físico. backup está preso, a atualização de dados está bloqueada.
Três, resolva
Existem várias soluções:
1. Exclua a biblioteca principal 2 como uma consulta de leitura. Isso não está planejado por enquanto. Se ainda houver problemas a serem considerados posteriormente, e se todas as três bibliotecas escravas forem desligadas?
2. Defina o tempo de bloqueio da biblioteca principal 2 para backup físico. Se o tempo de bloqueio exceder um determinado período, o backup será interrompido. Depois de um tempo, ele começará do início. Este método é melhor para dba e blogueiros acho que é um perigo oculto, o que levará facilmente a um ciclo de backup contínuo.
3. Combinar backup físico e backup lógico LVM, backup físico uma vez por semana é suficiente e backup lógico LVM é usado todos os dias. Este também é o método recomendado de "Mysql de alto desempenho" lido por blogueiros. Combinar 2 basicamente não causará problemas . Mas isso requer a automação do desenvolvimento de operação e manutenção e gerenciamento de backup, e o dba parece desnecessário.
Quatro. Resumo
Isso envolve o conhecimento básico relacionado à sincronização e backup do Mysql. Blogueiros têm preguiça de escrever. Alunos interessados podem ler "Mysql de alto desempenho"
Os problemas causados por diferentes arquiteturas correspondem a diferentes soluções de otimização, e os interessados podem se comunicar entre si