O MySQL tem uma longa tradição em replicação geográfica. A distribuição de clusters para data centers remotos reduz os efeitos da latência geográfica ao aproximar os dados do usuário. Ele também fornece um recurso para recuperação de desastres. Devido ao custo significativo de duplicar o hardware em um local separado, muitas empresas não podiam pagar no passado. Outro custo é a equipe qualificada capaz de projetar, implementar e manter um ambiente sofisticado de vários data centers.
Com a revolução da automação em nuvem e DevOps, ter um datacenter distribuído nunca foi tão acessível às massas. Os provedores de nuvem estão aumentando a gama de serviços que oferecem por um preço melhor. É possível criar ambientes híbridos entre nuvens com dados espalhados por todo o mundo. Pode-se fazer planos de DR flexíveis e escaláveis para abordar uma ampla variedade de cenários de interrupção. Em alguns casos, isso pode ser apenas um backup armazenado fora do local. Em outros casos, pode ser uma cópia de 1 para 1 de um ambiente de produção em execução em outro lugar.
Neste blog, veremos alguns desses casos e abordaremos cenários comuns.
Armazenando backups na nuvem
Um plano de DR é um termo geral que descreve um processo para recuperar sistemas de TI interrompidos e outros ativos críticos que uma organização usa. Backup é o principal método para conseguir isso. Quando um backup está no mesmo data center que seus servidores de produção, você corre o risco de que todos os dados sejam apagados caso perca esse data center. Para evitar isso, você deve ter a política de criar uma cópia em outro local físico. Ainda é uma boa prática manter um backup em disco para reduzir o tempo necessário para a restauração. Na maioria dos casos, você manterá seu backup principal no mesmo datacenter (para minimizar o tempo de restauração), mas também deverá ter um backup que possa ser usado para restaurar procedimentos de negócios quando o datacenter principal estiver inativo.
ClusterControl:Carregar Backup para a nuvem O ClusterControl permite a integração perfeita entre seu ambiente de banco de dados e a nuvem. Ele fornece opções para migrar dados para a nuvem. Oferecemos uma combinação completa de backups de banco de dados para Amazon Web Services (AWS), Google Cloud Services ou Microsoft Azure. Os backups agora podem ser executados, agendados, baixados e restaurados diretamente do provedor de nuvem de sua escolha. Essa capacidade oferece maior redundância, melhores opções de recuperação de desastres e benefícios em desempenho e economia de custos.
ClusterControl:Gerenciando credenciais de nuvem A primeira etapa para configurar o "backup à prova de falhas do data center" é fornecer credenciais para seu operador de nuvem. Você pode escolher entre vários fornecedores aqui. Vamos dar uma olhada no processo configurado para o operador de nuvem mais popular - AWS.
ClusterControl:adicionando credenciais de nuvem Tudo o que você precisa é o AWS Key ID e o segredo da região em que deseja armazenar seu backup. Você pode obter isso no console da AWS. Você pode seguir alguns passos para obtê-lo.
- Use o endereço de e-mail e a senha da sua conta da AWS para fazer login no Console de gerenciamento da AWS como usuário raiz da conta da AWS.
- Na página Painel do IAM, escolha o nome da sua conta na barra de navegação e selecione Minhas credenciais de segurança .
- Se você vir um aviso sobre como acessar as credenciais de segurança de sua conta da AWS, escolha Continuar para credenciais de segurança .
- Expanda a seção Chaves de acesso (ID da chave de acesso e chave de acesso secreta).
- Escolha Criar nova chave de acesso . Em seguida, escolha Baixar arquivo de chave para salvar o ID da chave de acesso e a chave de acesso secreta em um arquivo em seu computador. Depois de fechar a caixa de diálogo, você não poderá recuperar essa chave de acesso secreta novamente.
ClusterControl:backup em nuvem híbrida Quando tudo estiver definido, você pode ajustar sua programação de backup e habilitar a opção de backup na nuvem. Para reduzir o tráfego de rede, certifique-se de habilitar a compactação de dados. Faz backups menores e minimiza o tempo necessário para upload. Outra boa prática é criptografar o backup. O ClusterControl cria uma chave automaticamente e a usa se você decidir restaurá-la. As políticas de backup avançadas devem ter tempos de manutenção diferentes para backups armazenados em servidores no mesmo datacenter e backups armazenados em outro local físico. Você deve definir um período de retenção mais estendido para backups baseados em nuvem e um período mais curto para backups armazenados próximos ao ambiente de produção, pois a probabilidade de restauração diminui com o tempo de vida do backup.
ClusterControl:política de retenção de backup Estenda seu cluster com replicação assíncrona
Galera com replicação assíncrona pode ser uma excelente solução para construir um nó de DR ativo em um data center remoto. Existem algumas boas razões para anexar um escravo assíncrono a um Galera Cluster. Consultas do tipo OLAP de longa duração em um nó Galera podem tornar um cluster inteiro mais lento. Com a opção de aplicação de atraso, a replicação atrasada pode salvá-lo de erros humanos, de modo que todas essas entradas douradas não serão aplicadas imediatamente ao seu nó de backup.
ClusterControl:replicação atrasada No ClusterControl, a extensão de um grupo de nós Galera com replicação assíncrona é feita em um assistente de página única. Você precisa fornecer as informações necessárias sobre seu servidor escravo futuro ou existente. O escravo será configurado a partir de um backup existente ou de um XtraBackup recém-transmitido do mestre para o escravo.
Balanceadores de carga em vários datacenters
Os balanceadores de carga são um componente crucial na alta disponibilidade do banco de dados MySQL e MariaDB. Não é suficiente ter um cluster abrangendo vários data centers. Você ainda precisa de seus serviços para acessá-los. Uma falha de um balanceador de carga disponível em um data center tornará todo o seu ambiente inacessível.
Proxies da Web em ambiente de cluster Um dos métodos populares para ocultar a complexidade da camada de banco de dados de um aplicativo é usar um proxy. Os proxies atuam como um ponto de entrada para os bancos de dados, rastreiam o estado dos nós do banco de dados e devem sempre direcionar o tráfego apenas para os nós disponíveis. O ClusterControl facilita a implantação e configuração de várias tecnologias de balanceamento de carga diferentes para MySQL e MariaDB, incluindo ProxySQL, HAProxy, com uma interface gráfica de apontar e clicar.
ClusterControl:balanceador de carga HA Também permite tornar este componente redundante adicionando keepalived em cima dele. Para evitar que seus balanceadores de carga sejam um único ponto de falha, um deve configurar duas instâncias HAProxy, ProxySQL ou MariaDB Maxscale idênticas (uma ativa e outra em DC diferente como standby) e usar Keepalived para executar o Virtual Router Redundancy Protocol (VRRP) entre eles. O VRRP fornece um endereço IP virtual para o balanceador de carga ativo e transfere o IP virtual para o HAProxy em espera em caso de falha. É perfeito porque as duas instâncias de proxy não precisam de estado compartilhado.
Claro, há muitas coisas a serem consideradas para tornar seus bancos de dados imunes a falhas do data center.
Planejamento e automação adequados farão com que funcione! Feliz Agrupamento!
