Orchestrator for MySQL: por que um projeto à prova de falhas não pode ser construído sem ele

Qualquer projeto importante começou com um par de servidores. Primeiro, havia um servidor de banco de dados e, em seguida, escravos foram adicionados a ele para escalar a leitura. E aqui - pare! Um mestre, mas muitos escravos; se um dos escravos sair, tudo ficará bem, mas se o mestre sair, será ruim: o tempo de inatividade, os administradores do sabão aumentam o servidor. O que fazer? Reserve o mestre. Meu colega Pavel já escreveu um artigo sobre isso , não vou repetir. Em vez disso, vou lhe dizer por que você definitivamente precisa de um orquestrador para MySQL!

Vamos começar com a pergunta principal: "Como vamos mudar o código para uma nova máquina quando o assistente sair?"

• O esquema com VIP (IP virtual) que eu mais gosto, falaremos sobre isso abaixo. É o mais simples e mais óbvio, embora tenha uma limitação óbvia: o mestre, que reservaremos, deve estar no segmento L2 com uma nova máquina, ou seja, você pode esquecer o segundo CD. E, de uma maneira boa, se você seguir a regra de que L2 grande é ruim, porque L2 é apenas por rack e entre os racks L3, e esse esquema tem ainda mais restrições.
• Você pode registrar um nome DNS no código e resolvê-lo através do / etc / hosts. De fato, não haverá resolução. Vantagem do esquema: não há característica de restrição do primeiro método, ou seja, você também pode organizar cross-DCs. Mas então surge a pergunta óbvia: com que rapidez através do Puppet-Ansible podemos entregar a alteração para / etc / hosts.
• Você pode alterar um pouco o segundo método: em todos os servidores da Web, colocamos o DNS em cache, através do qual o código irá para o banco de dados mestre. Você pode registrar o TTL 60 para esta entrada DNS. Parece que, com a devida implementação, o método é bom.
• Esquema com descoberta de serviço, envolvendo o uso de Consul e etcd.
• Uma opção interessante com o ProxySQL . É necessário agrupar todo o tráfego no MySQL através do ProxySQL, o ProxySQL pode determinar quem é o mestre agora. A propósito, sobre uma das opções para usar este produto pode ser encontrada em meu artigo .

O autor do Orchestrator, enquanto trabalhava no Github, primeiro implementou o primeiro esquema com VIP e depois o redesenhou com c consul.

Esquema típico de infraestrutura:

Descreverei imediatamente as situações óbvias a serem consideradas:

• VIP- . : , , Orchestrator failover ; , VIP . .
• . ifdown, — ifup vip. , failover , splitbrain.
• , Orchestrator , VIP / , VIP, arping , VIP .
• Todos os escravos devem ter read_only = 1 e, assim que você promover o escravo para o mestre, ele deve ter read_only = 0.
• Não esqueça que qualquer escravo que escolhemos para isso pode se tornar um mestre (o orquestrador tem todo um mecanismo de preferência, qual escravo deve ser considerado candidato a um novo mestre em primeiro lugar, qual é o segundo e qual escravo não deve ser selecionado em nenhuma circunstância) mestre). Se o escravo se tornar um mestre, a carga do escravo permanecerá nele e a carga do mestre será adicionada, isso deve ser levado em consideração.

Por que você precisa absolutamente do Orchestrator se não possui um?

• O Orchestrator possui uma interface gráfica muito amigável que exibe toda a topologia (veja a captura de tela abaixo).
• O Orchestrator pode rastrear quais escravos estão atrasados ​​e onde a replicação foi interrompida (temos scripts para enviar SMS ao Orchestrator).
• O orquestrador informa quais slides apresentam um erro incorreto no GTID.

Interface do orquestrador:

O que é um erro de GTID?

Existem dois requisitos básicos para o Orchestrator funcionar:

• É necessário que o pseudo GTID esteja habilitado em todas as máquinas no cluster MySQL, tenhamos o GTID habilitado.
• É necessário que, em qualquer lugar que exista um tipo de binlog, você possa declarar. Tínhamos uma configuração em que Row estava no mestre e na maioria dos escravos, e o modo Misto permaneceu historicamente em dois. Como resultado, o Orchestrator simplesmente não queria conectar esses escravos ao novo mestre.

Lembre-se de que a coisa mais importante em um escravo de produção é sua consistência com o mestre! Se você tiver o ID de transação global (GTID) ativado no mestre e no escravo, poderá usar a função gtid_subset para descobrir se as mesmas solicitações de alteração de dados são realmente executadas nessas máquinas. Leia mais sobre isso aqui .

Portanto, o Orchestrator mostra, através de um erro incorreto do GTID, que há transações no escravo que não estão no assistente. Por que isso acontece?

• Read_only = 1 não está ativado no escravo, alguém conectado e executou uma solicitação de alteração de dados.
• Super_read_only = 1 não está ativado no escravo, então o administrador, tendo misturado o servidor, entrou e executou uma solicitação lá.
• Se você levou em consideração os dois parágrafos anteriores, há mais um truque: no MySQL, a solicitação para liberar binlogs também cai no binlog; portanto, quando você liberar pela primeira vez, um erro de GTID aparecerá no assistente e em todos os escravos. Como evitar isso? Em perona-5.7.25-28, a configuração binlog_skip_flush_commands = 1 apareceu, o que proíbe a gravação de descarga nos binlogs. Há um erro no mysql.com .

Resumo todas as opções acima. Se você ainda não deseja usar o Orchestrator no modo de failover, coloque-o no modo de vigilância. Você sempre terá diante de seus olhos um mapa da interação das máquinas MySQL e informações claras sobre que tipo de replicação em cada máquina, se os escravos estão atrasados ​​e o mais importante - quanta consistência eles têm com o mestre!

A pergunta óbvia é: "Como o Orchestrator deve funcionar?" Ele deve selecionar um novo mestre dos escravos atuais e reconectar todos os escravos a ele (é para isso que serve o GTID; se você usar o mecanismo antigo com binlog_name e binlog_pos, é simplesmente impossível mudar o escravo do mestre atual para o novo!). Antes do Orchestrator chegar até nós, uma vez eu tive que fazer tudo isso manualmente. O velho mestre travou devido a um controlador Adaptec com erros, 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 eu tive que abrir, quantos comandos simultâneos para entrar ... Eu tive que esperar até as três da manhã, remover a carga de todos os escravos, exceto dois, fazer o primeiro carro com dois mestres, ligar imediatamente o segundo carro a ele,portanto, pegue todos os outros escravos no novo mestre e retorne a carga. Em geral, o horror ...

Como o Orchestrator funciona quando entra no modo de failover? Isso é mais facilmente demonstrado pelo exemplo de uma situação em que queremos tornar um mestre uma máquina mais poderosa e mais moderna do que agora.

A figura mostra o meio do processo. O que já foi feito até este ponto? Dissemos que queremos transformar algum tipo de escravo em um novo mestre, o Orchestrator começou a reconectar todos os outros escravos, e o novo mestre atua como uma máquina de trânsito. Com esse esquema, os erros não ocorrem, todos os escravos funcionam, o Orchestrator remove o VIP do mestre antigo, transfere para o novo mestre, faz read_only = 0 e esquece o mestre antigo. Todos! O tempo de inatividade do nosso serviço é o tempo de transferência VIP, é de 2 a 3 segundos.

Por hoje é tudo, obrigado a todos. Em breve, haverá um segundo artigo sobre o Orchestrator. No famoso filme soviético "The Garage", um herói disse: "Eu não entraria em contato com ele!" Então, orquestrador, eu iria com você explorar!