Entendendo a alta disponibilidade do MySQL: razões positivas e negativas para utilizá-la

O custo do tempo de inatividade no ambiente corporativo aumenta rapidamente. Em uma pesquisa, 40% dos entrevistados afirmaram que apenas uma hora de inatividade custava à sua organização mais de US$ 1 milhão em prejuízos. Garantir que os serviços de banco de dados estejam sempre disponíveis claramente vale a pena.

Isso economiza grandes quantias de dinheiro para a sua organização, sem falar na melhoria das relações com as partes interessadas de todos os tipos e tamanhos.

Então, como garantir a disponibilidade contínua? O conceito por trás da disponibilidade persistente é chamado de alta disponibilidade. Neste artigo, explicamos o que é alta disponibilidade e como você pode alcançá-la em seus clusters MySQL.

Também destacamos um lado mais sombrio da alta disponibilidade, em que os administradores de sistemas dependem indevidamente dela para realizar tarefas de manutenção — e explicamos por que isso prejudica os objetivos da alta disponibilidade, colocando em risco as operações da sua empresa.

Introdução à alta disponibilidade

Vamos falar primeiro sobre disponibilidade. Não faz muito sentido manter um serviço, como um banco de dados, se ele não estiver disponível para os usuários na maior parte do tempo. Portanto, quando falamos de disponibilidade, nos referimos ao grau de acessibilidade de um serviço.

Para qualquer serviço em funcionamento, seria razoável esperar que ele estivesse disponível quando necessário — mas também seria de se esperar algum tempo de inatividade, um ou dois dias por ano ou talvez algumas horas por mês.

Um serviço que esteja geralmente disponível pode ser suficiente para muitos cenários de uso, mas quando o serviço é de natureza crítica ou quando um volume muito grande de usuários depende dele, a mera “disponibilidade” simplesmente não é suficiente.

E é aí que entra a alta disponibilidade. Em termos bem básicos, a alta disponibilidade garante um nível de disponibilidade superior ao normalmente esperado e, mais especificamente, um nível acordado, mesmo levando em conta a manutenção, a aplicação de patches e erros e falhas gerais.

Qual nível de disponibilidade é considerado alta disponibilidade?

Não existe uma definição consensual sobre o que se qualifica como alta disponibilidade; sabe-se apenas que ela excede o que seria geralmente aceito como “disponível”, a fim de atender a um requisito específico (mais elevado) de disponibilidade. Na verdade, é provável que sua organização defina a disponibilidade necessária com base nas necessidades operacionais — ponderando os custos da alta disponibilidade em relação às perdas associadas ao tempo de inatividade.

O nível de disponibilidade necessário pode ser expresso em porcentagem. Por exemplo, uma disponibilidade de 99,99% ou “quatro noves” implica um máximo de 52,60 minutos de tempo de inatividade por ano, enquanto uma disponibilidade de “seis noves” ou 99,9999% limita o tempo de inatividade a 31,56 segundos por ano.

Essencialmente, a escolha é sua – mas, mais uma vez, há uma contrapartida. Manter a alta disponibilidade será caro – exigirá recursos físicos e licenças de software adicionais, além de sobrecarregar sua equipe. No entanto, você pode muito bem perceber que vale a pena pagar esse preço para evitar os custos indiretos decorrentes de interrupções ou os riscos de perder receita devido a clientes insatisfeitos.

Como a alta disponibilidade funciona na prática?

A natureza exata da sua infraestrutura de alta disponibilidade dependeria da sua carga de trabalho. No entanto, em termos gerais, pode-se argumentar que a alta disponibilidade é alcançada quando há tolerância a falhas, de modo que, mesmo que um serviço ou dispositivo falhe, a carga de trabalho não seja interrompida. Normalmente, isso significa que não há um único ponto de falha — todos os serviços e dispositivos são totalmente redundantes, tanto no nível da rede quanto no nível da aplicação.

Dependendo do serviço, isso geralmente envolve vários nós — por exemplo, seu cluster MySQL conterá vários nós nos quais os dados são armazenados. Esses vários nós são então combinados com uma ferramenta de balanceamento de carga para que, caso um nó falhe, as solicitações sejam simplesmente redirecionadas para outro nó. Os usuários continuarão acessando um serviço disponível, mesmo que o desempenho seja ligeiramente prejudicado.

Configurando alta disponibilidade no MySQL

O caminho a seguir para obter um banco de dados MySQL de alta disponibilidade dependerá, obviamente, da sua implementação do MySQL. Em linhas gerais, você precisará criar algum tipo de cluster MySQL com vários nós — em outras palavras, seus dados devem estar armazenados em vários servidores MySQL.

Em seguida, você precisará de um serviço capaz de replicar dados entre esses nós, garantindo que cada um deles contenha uma cópia exata dos dados presentes no seu banco de dados. Por fim, você precisará de um balanceador de carga que garanta que todas as solicitações ao banco de dados sejam distribuídas uniformemente entre os nós do banco de dados — garantindo, sim, uma carga equilibrada —, mas também assegurando que as solicitações sejam atendidas mesmo que um nó esteja fora do ar.

Por exemplo, o MySQL oferece um produto comercial voltado para alta disponibilidade – o MySQL InnoDB Cluster. Ele se baseia no MySQL Group Replication, que é uma forma popular de garantir alta disponibilidade em um ambiente de banco de dados MySQL. Se você estiver utilizando versões mais antigas, é fundamental acompanhar o status de fim de vida útil do MySQL para garantir que ainda receba atualizações de segurança ativas.

Outra alternativa é o Galera, que já oferece alta disponibilidade para o MySQL há muitos anos. Se você estiver usando o fork do MySQL chamado MariaDB, poderia, por exemplo, configurar seu ambiente MariaDB para alta disponibilidade executando vários nós com o Galera Cluster – enquanto utiliza o HAProxy para o balanceamento de carga. Como alternativa, você poderia considerar o produto MaxScale, desenvolvido pela própria MariaDB.

Se você estiver utilizando especificamente o MariaDB 10.6, também é importante saber que ele chegará ao fim da vida útil em julho de 2026; informe-se sobre o que o fim da vida útil (EOL) do MariaDB 10.6 significa para o seu ambiente antes de planejar sua configuração de alta disponibilidade (HA).

BOAS RAZÕES PARA CONFIAR NA ALTA DISPONIBILIDADE…

As cargas de trabalho em escala empresarial recorrem cada vez mais aos princípios de alta disponibilidade simplesmente porque, a longo prazo, isso proporciona os melhores resultados. Aqui estão apenas algumas das muitas boas razões pelas quais você deve considerar a implementação de alta disponibilidade em suas operações:

• Aplicações críticas. Algumas aplicações simplesmente não podem arcar com nenhum tempo de inatividade; pense, por exemplo, em aplicações militares ou redes de energia. A alta disponibilidade é imprescindível nesses cenários, e você não tem outra escolha a não ser garantir níveis extremamente altos de disponibilidade — embora ainda possa avaliar os riscos e decidir exatamente qual o nível de garantia de disponibilidade de que necessita.
• Efeitos em cadeia. Quando um sistema é o núcleo de uma carga de trabalho, mesmo um breve tempo de inatividade pode levar a problemas muito mais generalizados, à medida que sistemas conectados e sincronizados entram em colapso em uma reação em cadeia. Vale a pena considerar o investimento em alta disponibilidade em algumas áreas essenciais — como um banco de dados —, pois isso pode muito bem compensar o custo, tendo em vista os custos de problemas em cadeia muito maiores, dos quais pode ser muito difícil se recuperar.
• Perda de receita. A alta disponibilidade, mesmo que se trate de um número modesto de “noves”, pode proteger contra a perda de receita. Para um grande varejista online, apenas algumas horas de vendas perdidas, combinadas com o dano à reputação associado, podem causar um impacto muito significativo nos resultados financeiros.
• Expectativas dos clientes e SLAs. Suas operações podem estar sujeitas a acordos de nível de serviço que garantem aos seus clientes um determinado nível de disponibilidade. Se for esse o caso, você precisa garantir que os serviços que dão suporte às cargas de trabalho dos seus clientes tenham o nível de disponibilidade exigido — e você fará isso por meio da alta disponibilidade. Não cumprir essa exigência pode levar à rescisão dos contratos ou à aplicação de multas previstas nos contratos.

Essas são algumas das razões válidas para a alta disponibilidade – e, mais uma vez, no mundo atual, em que a tecnologia vem em primeiro lugar, há muitas cargas de trabalho que simplesmente não conseguem operar sem uma plataforma de alta disponibilidade em funcionamento.

… e o motivo errado para confiar na alta disponibilidade 

A crescente prevalência da alta disponibilidade, infelizmente, também levou ao seu uso indevido. Como a alta disponibilidade torna os sistemas incrivelmente robustos, as equipes de tecnologia podem se sentir tentadas a tomar atalhos ao realizar tarefas de administração de sistemas, como a aplicação de patches, pois partem do princípio de que a infraestrutura de alta disponibilidade simplesmente arcará com o ônus de colocar uma máquina fora do ar.

Na prática, a situação pode se tornar rapidamente mais complicada. Veja o caso de um cluster do MySQL, por exemplo. Sim, se você reiniciar uma máquina para aplicar uma correção, seu cluster do MySQL continuará em funcionamento graças à alta disponibilidade. No entanto, lembre-se de que, quando você desativa um nó para aplicar uma correção e, em seguida, o reinicia, isso resulta em um acúmulo de dados que precisam ser importados. Esse processo pode levar muito tempo para ser concluído.

Não é preciso dizer que todos os servidores de banco de dados devem ter acesso aos mesmos dados. O risco surge durante a ressincronização: se outro nó ficar fora do ar enquanto você já tiver retirado um nó para aplicar uma correção, pode ocorrer uma perda do quorum válido. Em outras palavras, o número de servidores que detêm a “verdade” sobre os dados fica abaixo de um nível aceitável. A recuperação a partir desse estado pode ser difícil e complexa, podendo até mesmo levar à perda de dados.

Não conte com a alta disponibilidade para realizar manutenção

A alta disponibilidade existe para manter seus sistemas em funcionamento mesmo quando ocorre uma falha. Essa proteção inerente contra falhas não é um passe livre para se confiar na robustez da alta disponibilidade a fim de realizar a manutenção do sistema de forma irresponsável, na esperança de que ninguém perceba.

Em vez disso, as equipes técnicas devem recorrer a outras soluções — por exemplo, implementar redundância total para um sistema que está recebendo patches, em vez de simplesmente esperar que a infraestrutura de alta disponibilidade absorva a pressão. Ou, sempre que possível contar com a aplicação de patches em tempo real , o que elimina a necessidade de reiniciar um serviço para instalar um patch.

No entanto, a dependência da alta disponibilidade para tarefas de manutenção está dando sinais preocupantes de que está se tornando uma prática comum. Basta dar uma olhada por aí para encontrar até mesmo orientações oficiais dos fornecedores que instruem os usuários a contar com a alta disponibilidade para executar tarefas de aplicação de patches, e que os usuários simplesmente esperem que nada mais dê errado nos outros nós enquanto um nó fica fora de operação para a aplicação do patch.

CONCLUSÃO

A alta disponibilidade é fundamental para muitas aplicações – e traz grandes benefícios para muitas outras. Quando configurado corretamente, um banco de dados MySQL pode oferecer disponibilidade praticamente perfeita, mas isso não significa que as equipes técnicas possam considerar a disponibilidade como algo garantido.

Usar indevidamente a arquitetura de alta disponibilidade para tomar atalhos na manutenção simplesmente não é uma opção — os riscos são maiores do que pode parecer à primeira vista.

Em vez disso, os administradores de sistemas devem recorrer a alternativas comprovadas — incluindo redundância e aplicação de patches em tempo real — para realizar operações de manutenção sem comprometer os recursos das soluções de alta disponibilidade.