Quando o banco de dados fica indisponível, a aplicação pode deixar de registrar pedidos, consultar estoques ou concluir atendimentos. O impacto depende de quanto a operação utiliza esses dados e de quanto tempo consegue trabalhar sem acesso a eles.
Alta disponibilidade busca reduzir interrupções por meio de redundância, detecção de falhas e procedimentos de transição para componentes disponíveis. Sua adoção deve partir dos requisitos da aplicação e do impacto de uma parada.
Comece pelo impacto na operação
Considere um sistema interno utilizado durante o horário comercial. Uma interrupção curta pode ser administrada com um procedimento temporário, desde que os dados sejam preservados e a recuperação ocorra dentro do prazo necessário.
Agora considere uma plataforma que recebe pedidos continuamente. Uma falha no banco pode interromper novas transações e afetar clientes enquanto o serviço é recuperado.
Esses ambientes podem exigir estratégias diferentes. Antes de definir a arquitetura, identifique quais atividades dependem do banco, por quanto tempo podem ficar interrompidas e quais consequências essa interrupção traz.
O número de usuários, isoladamente, não determina a necessidade de alta disponibilidade. Um sistema com poucos acessos pode sustentar uma atividade essencial para o negócio.
Entenda o que precisa continuar funcionando
Um ambiente pode ter mais de um servidor de banco de dados e ainda depender de um único componente para operar.
Se todos os servidores utilizam o mesmo armazenamento, equipamento de rede ou alimentação elétrica, uma falha compartilhada pode atingir o conjunto. A arquitetura precisa considerar essas dependências e distribuir os componentes conforme os riscos que pretende cobrir.
A aplicação também faz parte desse planejamento. Ela precisa conseguir se conectar ao banco disponível, lidar com conexões interrompidas e tratar corretamente transações cujo resultado ficou incerto durante a falha.
Adicionar servidores é uma etapa. A continuidade depende do funcionamento do ambiente completo.
Como funciona a transição após uma falha
A mudança do atendimento para outro componente é chamada de failover. Conforme a solução, ela pode ocorrer automaticamente ou depender de intervenção.
Para funcionar de forma segura, o processo precisa identificar a falha, verificar qual servidor pode assumir e direcionar as conexões para ele. Também deve evitar que componentes isolados aceitem gravações conflitantes.
Mesmo com automação, podem ocorrer interrupções de conexão durante a transição. Por isso, o comportamento da aplicação precisa ser validado junto com o banco.
Um teste útil acompanha o processo inteiro: da falha simulada até o momento em que a aplicação volta a concluir suas operações corretamente.
Defina os requisitos de recuperação
Duas perguntas ajudam a orientar o projeto: quanto tempo o serviço pode ficar indisponível e qual perda de dados é tolerável?
O objetivo de tempo de recuperação, ou RTO, estabelece o prazo desejado para restabelecer o serviço. O objetivo de ponto de recuperação, ou RPO, estabelece a perda de dados tolerável, medida em tempo.
Esses requisitos influenciam a escolha da tecnologia, a distribuição dos servidores e o processo de transição. Em uma replicação assíncrona, por exemplo, o destino pode estar atrasado em relação à origem. Esse atraso precisa ser considerado ao avaliar uma possível promoção da réplica.
Metas mais rigorosas exigem validação compatível e podem aumentar o custo e a complexidade operacional.
Mantenha backup e histórico de recuperação
Alta disponibilidade e backup atendem a necessidades diferentes.
Uma estrutura preparada para falhas de servidores pode continuar propagando uma exclusão acidental ou uma alteração incorreta. Nesse caso, manter o serviço acessível não recupera o estado anterior dos dados.
O projeto deve prever cópias de segurança, retenção e testes de restauração. Quando necessário, deve incluir recuperação para um ponto específico no tempo, conforme os recursos da solução e a configuração adotada.
Diferencie disponibilidade de desempenho
Alta disponibilidade não significa, automaticamente, consultas mais rápidas ou maior capacidade de gravação.
O desempenho depende de fatores como consultas, índices, volume de dados, recursos de infraestrutura e comportamento da aplicação. Réplicas de leitura podem ajudar em determinados cenários, mas exigem avaliar quais consultas podem usar dados eventualmente defasados.
Se o problema atual é lentidão, investigue sua origem antes de definir um cluster como solução.
O que avaliar antes da implantação
| Critério | Pergunta que o projeto deve responder |
|---|---|
| Continuidade | Quais falhas o ambiente precisa suportar? |
| Recuperação | Quais são os objetivos de tempo e perda de dados? |
| Aplicação | Como o sistema reage à perda de conexão e à transição? |
| Infraestrutura | Quais dependências ainda podem interromper o conjunto? |
| Operação | Quem monitora, mantém e atende o ambiente? |
| Validação | Como serão testadas as falhas e a recuperação? |
Planeje o banco de dados conforme sua operação
A necessidade de alta disponibilidade deve estar ligada ao impacto de uma interrupção e aos requisitos de recuperação. Com esses critérios definidos, é possível avaliar uma arquitetura e verificar se ela atende à aplicação.
A CloudUnix oferece projeto e implantação de banco de dados MySQL distribuído. Converse com a equipe sobre seu ambiente, suas dependências e os requisitos de continuidade.
Conheça o MySQL Cluster e avalie a arquitetura para sua aplicação.
Conheça os serviços citados
MySQL Cluster