Qualquer grande projeto começa com alguns servidores. No início havia um servidor de banco de dados, depois foram adicionados escravos para dimensionar a leitura. E então - pare! Existe um senhor, mas existem muitos escravos; se um dos escravos sair, tudo ficará bem, mas se o mestre sair, será ruim: tempo de inatividade, os administradores estão tentando aumentar o servidor. O que fazer? Reserve um mestre. Meu colega Pavel já escreveu sobre isso , não vou repetir. Em vez disso, direi por que você definitivamente precisa do Orchestrator for MySQL!
Vamos começar com a questão principal: “Como mudaremos o código para uma nova máquina quando o mestre sair?”
- Gosto mais do esquema com VIP (IP Virtual), falaremos sobre isso a seguir. É o mais simples e óbvio, embora tenha uma limitação óbvia: o master que iremos reservar deve estar no segmento L2 da nova máquina, ou seja, podemos esquecer o segundo DC. E, de forma amigável, se você seguir a regra de que L2 grande é malvado, pois L2 é só por rack, e L3 fica entre os racks, e tal esquema tem ainda mais restrições.
- Você pode escrever um nome DNS no código e resolvê-lo através de /etc/hosts. Na verdade, não haverá resolução. A vantagem do esquema: não há limitação característica do primeiro método, ou seja, é possível organizar um CD cruzado. Mas então surge a pergunta óbvia: com que rapidez podemos entregar a mudança em /etc/hosts via Puppet-Ansible?
- Você pode alterar um pouco o segundo método: instalar o cache DNS em todos os servidores web, através do qual o código irá para o banco de dados mestre. Você pode definir TTL 60 para esta entrada no DNS. Parece que se implementado corretamente, o método é bom.
- Um esquema com descoberta de serviço, implicando a utilização de Consul e etcd.
- Uma opção interessante com . Você precisa rotear todo o tráfego para o MySQL através do ProxySQL; o próprio ProxySQL pode determinar quem é o mestre. Aliás, você pode ler sobre uma das opções de uso deste produto no meu .
O autor do Orchestrator, trabalhando no Github, primeiro implementou o primeiro esquema com VIP e depois o converteu em um esquema com cônsul.
Layout típico de infraestrutura:
Descreverei imediatamente as situações óbvias que precisam ser levadas em consideração:
- O endereço VIP não deve ser cadastrado na configuração de nenhum dos servidores. Vamos imaginar uma situação: o master foi reinicializado e, enquanto carregava, o Orchestrator entrou em modo failover e transformou um dos escravos em master; então o velho mestre subiu, e agora o VIP está em dois carros. Isto é mau.
- Para o orquestrador, você precisará escrever um script para chamar o antigo mestre e o novo mestre. No master antigo você precisa executar o ifdown, e no novo master – ifup vip. Seria bom incluir também neste script que, no caso de um failover, a porta do switch mestre antigo fosse simplesmente desligada para evitar qualquer divisão.
- Após o Orchestrator ter chamado seu script para primeiro remover o VIP e/ou extinguir a porta no switch e, em seguida, chamar o script de aumento de VIP no novo master, não se esqueça de usar o comando arping para informar a todos que o novo VIP está agora aqui.
- Todos os escravos devem ter read_only=1, e assim que você promover o escravo a mestre, ele deverá ter read_only=0.
- Não se esqueça que qualquer escravo que escolhemos para isso pode se tornar um mestre (o orquestrador tem todo um mecanismo de preferência para qual escravo considerar como candidato a novo mestre em primeiro lugar, qual em segundo lugar, e qual escravo deve não será selecionado em nenhuma circunstância mestre). Se o escravo se tornar mestre, então a carga do escravo permanecerá nele e a carga do mestre será adicionada, isso deve ser levado em consideração.
Por que você precisa do Orchestrator se não tem um?
- O Orchestrator possui uma interface gráfica muito amigável que exibe toda a topologia (veja a imagem abaixo).
- O Orchestrator pode rastrear quais escravos estão atrasados e onde a replicação geralmente foi interrompida (temos scripts anexados ao Orchestrator para envio de SMS).
- O Orchestrator informa quais escravos possuem um GTID incorreto.
Interface do orquestrador:
O que é GTID errado?
Existem dois requisitos principais para o Orchestrator funcionar:
- É necessário que o pseudo GTID esteja habilitado em todas as máquinas do cluster MySQL; temos o GTID habilitado.
- É necessário que haja um tipo de binlog em todos os lugares, você pode usar a instrução. Tínhamos uma configuração em que o mestre e a maioria dos escravos possuíam Row, e dois historicamente permaneciam no modo Misto. Como resultado, o Orchestrator simplesmente não queria conectar esses escravos ao novo mestre.
Lembre-se que o mais importante em um escravo de produção é a sua consistência com o mestre! Se você tiver o Global Transaction ID (GTID) ativado no mestre e no escravo, poderá usar a função gtid_subset para descobrir se as mesmas solicitações de alterações de dados foram realmente executadas nessas máquinas. Você pode ler mais sobre isso .
Assim, o Orchestrator mostra através do GTID errante que existem transações no escravo que não estão no mestre. Por que isso está acontecendo?
- Read_only=1 não está habilitado no escravo, alguém conectou e completou uma solicitação para alterar dados.
- Super_read_only=1 não está habilitado no escravo, então o administrador, tendo confundido o servidor, entrou e executou a solicitação lá.
- Se você levou em consideração os dois pontos anteriores, há mais um truque: no MySQL, uma solicitação para liberar binlogs também vai para o binlog, portanto, na primeira liberação, um GTID errante aparecerá no mestre e em todos os escravos. Como evitar isso? Perona-5.7.25-28 introduziu a configuração binlog_skip_flush_commands=1, que proíbe a gravação de flush em binlogs. Existe um estabelecido no site mysql.com .
Deixe-me resumir todos os itens acima. Se você ainda não quiser usar o Orchestrator no modo failover, coloque-o no modo de observação. Então você sempre terá diante de seus olhos um mapa da interação das máquinas MySQL e informações visuais sobre que tipo de replicação existe em cada máquina, se os escravos estão atrasados e, o mais importante, quão consistentes eles são com o mestre!
A pergunta óbvia é: “Como o Orchestrator deve funcionar?” Ele deve selecionar um novo mestre dos escravos atuais e, em seguida, reconectar todos os escravos a ele (é para isso que o GTID é necessário; se você usar o mecanismo antigo com binlog_name e binlog_pos, então mudar um escravo do mestre atual para um novo é simplesmente impossível!). Antes de termos o Orchestrator, uma vez tive que fazer tudo isso manualmente. O antigo mestre estava pendurado devido a um controlador Adaptec com bugs; ele tinha cerca de 10 escravos. Eu precisava transferir o VIP do mestre para um dos escravos e reconectar todos os outros escravos a ele. Quantos consoles tive que abrir, quantos comandos simultâneos digitei... Tive que esperar até as 3 da manhã, retirar a carga de todos os escravos exceto dois, fazer a primeira máquina de dois mestres, conectar imediatamente a segunda máquina a ele, então anexe todos os outros escravos ao novo mestre e devolva a carga. No geral, terrível...
Como o Orchestrator funciona quando entra no modo failover? Isto é mais facilmente ilustrado por um exemplo de situação em que queremos fazer de um mestre uma máquina mais poderosa e mais moderna do que a que temos agora.
A figura mostra o meio do processo. O que já foi feito até agora? Dissemos que queríamos fazer de algum escravo o novo mestre, o Orchestrator começou simplesmente a reconectar todos os outros escravos a ele, com o novo mestre atuando como uma máquina de trânsito. Com esse esquema não ocorre nenhum erro, todos os escravos funcionam, o Orchestrator remove o VIP do mestre antigo, transfere para o novo, faz read_only=0 e esquece o mestre antigo. Todos! O tempo de inatividade do nosso serviço é o tempo de transferência VIP, que é de 2 a 3 segundos.
Por hoje é tudo, obrigado a todos. Haverá um segundo artigo sobre o Orchestrator em breve. No famoso filme soviético “Garagem”, um personagem disse: “Eu não faria um reconhecimento com ele!” Então, orquestrador, eu iria com você no reconhecimento!
Fonte: habr.com