Os clusters de seguidores são um recurso do ScaleGrid que permite manter dois sistemas de banco de dados independentes (do mesmo tipo) em sincronia. Ao contrário da clonagem ou replicação, isso permite que você mantenha uma cópia ativa e pontual dos seus dados de produção. Esse cluster extra, conhecido como cluster seguidor, pode ser aproveitado para vários casos de uso, inclusive para analisar, otimizar e testar o desempenho de seu aplicativo para MongoDB, MySQL e PostgreSQL. Nesta postagem do blog, abordaremos os três principais cenários para aproveitar os clusters de seguidores para seu aplicativo.
Como os clusters de seguidores diferem da replicação?
Ao contrário de um clone estático, esses dados são importados em uma programação definida para que seu cluster seguidor esteja sempre sincronizado com seu cluster de produção. Aqui estão algumas maneiras críticas em que ele difere da replicação:
- Você pode controlar com que frequência o sistema de destino sincroniza a partir da origem – uma vez por semana, uma vez por dia ou até menos. Isso ajuda a reduzir a carga no sistema de origem.
- Como são dois sistemas independentes, você tem muito mais flexibilidade sobre os dados que são sincronizados. Você pode ter credenciais de usuário diferentes e até mesmo remover alguns dados do destino com base nos requisitos de segurança (observação:isso requer script do lado do usuário – não é um recurso interno dos clusters de seguidores).
- O sistema 'seguidor' é gravável, então você pode usá-lo como um ambiente de teste para testar as alterações do seu aplicativo. Isso não é algo que você pode fazer em um nó de réplica.
Observação:ScaleGrid implementa clusters seguidores usando instantâneos de armazenamento. Ele não está disponível para nossas ofertas de banco de dados em memória, como hospedagem para Redis™*.
1. Configuração de desenvolvimento/teste de banco de dados
Todos nós já passamos por isso – um trecho de código supostamente bem testado é implantado em produção e, então, o inferno começa. Os fluxos de trabalho de produção falham ou são tão lentos que são basicamente inutilizáveis. Engenheiros são acordados de suas camas para iniciar uma operação completa de combate a incêndio. Um monte de noites sem dormir depois, essa temida causa raiz emerge.
O aplicativo se comporta de maneira diferente nas configurações de produção e engenharia.
Em outras palavras, testamos em “dados de teste”. O que, como se vê, não era nada parecido com os dados de produção. De forma alguma.
A maneira óbvia de evitar essa situação é executar testes em seus dados de produção. Não é a produção real, é claro – isso será flertar com o desastre. Em uma cópia clonada dos dados de produção. Embora as preocupações com privacidade e segurança de dados tornem isso impraticável em muitos cenários, se os requisitos de privacidade permitirem, essa é a melhor solução. Não precisamos mais depender de engenheiros para gerar conjuntos de dados apropriados – se transmitir dados de teste, transmitirá dados de produção.
Isto é, até que os dados de teste fiquem tão fora de sincronia com a produção que não seja mais uma boa aproximação. E estamos de volta à estaca zero.
É aqui que entram os grupos de seguidores.
Usando clusters de seguidores, você pode importar dados periodicamente de seu banco de dados de produção para o banco de dados dev/test. E como toda a importação é realizada usando instantâneos de armazenamento, em vez de um dump lógico, o processo é quase instantâneo. Você pode agendar suas importações uma vez a cada 24 horas, uma vez por semana ou qualquer frequência que se adeque ao seu cenário específico.
Com seus clusters de desenvolvimento e controle de qualidade definidos para seguir o cluster de produção, você pode ficar tranquilo. Se o seu aplicativo passar no conjunto de dados de teste, ele definitivamente está apto para implantação em produção!
2. Análise de dados
Se você trabalhou como DBA, provavelmente já conversou com sua equipe sobre o desempenho do sistema "misteriosamente" desacelerar em determinados momentos. Na maioria dos casos, o culpado acaba sendo um trabalho de análise que está acessando toneladas de dados e acaba deixando todo o sistema lento.
Como fornecedor de DBaaS, tivemos essa conversa várias vezes com nossos clientes. Aqui estão as duas opções que normalmente sugerimos:
- Se o trabalho de análise estiver sendo executado no servidor primário/mestre, mova-o para um servidor secundário/de réplica.
- Se o trabalho de análise já estiver em execução em um nó secundário e a degradação do desempenho for inaceitável, recomendamos mover os trabalhos para um cluster de análise dedicado.
Usando nosso recurso de cluster de seguidores, é muito fácil manter um cluster de análise atualizado com dados reais de produção. Você pode criar uma programação de seguidores para sincronizar os dados mais recentes da produção pouco antes do início do trabalho de análise.
A melhor parte? A sincronização do seguidor não executa nenhuma operação no nível do banco de dados - apenas restaura o instantâneo mais recente! Portanto, há impacto zero em seu cluster de produção.
3. Relatório
Outro caso de uso comum em que nossos clientes usam o recurso de clusters de seguidores é para geração de relatórios. Os processos de geração de relatórios geralmente são executados com pouca frequência, mas acessam grandes quantidades de dados e ocupam a maior parte dos recursos de um cluster de banco de dados. Quando a degradação do desempenho for inaceitável, recomendamos que nossos clientes movam a carga de trabalho de relatórios para um novo cluster.
Como as operações de relatórios não são frequentes, muitos de nossos clientes preferem aproveitar nosso recurso de pausa/retomada para "pausar" clusters de relatórios quando não estiverem em uso. Isso ajuda a economizar muito nos custos de infraestrutura. Normalmente, os clusters de relatórios também são muito “menores” (menor CPU/RAM), para ajudar a reduzir custos.
Depois de criar um cluster de seguidores a partir de nossa interface do usuário, você pode usar este fluxo de trabalho para automatizar seu fluxo de relatórios:
- Use nossa API de currículo para retomar o cluster.
- Aguarde até que o cluster volte ao estado de execução (você pode usar sua API get-status para essa finalidade).
- Acione um backup em seu cluster de produção, se necessário (normalmente, se backups regulares estiverem programados em sua produção, você pode pular esta etapa. No entanto, se você deseja que seus relatórios sejam executados nos dados mais recentes, isso é essencial).
- Aguarde a conclusão do backup.
- Acionar um trabalho de sincronização no seguidor – isso encontra o instantâneo mais recente no cluster de origem e restaura no destino.
- Aguarde a conclusão do trabalho de sincronização.
- Execute suas tarefas de relatório.
- Use nossa API de pausa para pausar o cluster até seu próximo trabalho de relatório!
Você acha que os clusters de seguidores são adequados para o seu caso de usuário específico? Você pode aprender tudo sobre como implantar e gerenciar clusters de seguidores para MongoDB, MySQL e PostgreSQL em nossos documentos de ajuda!
Se você não tiver certeza se os clusters de seguidores são a solução correta para o seu caso de uso, deixe um comentário ou entre em contato conosco em [email protected] – nós estamos felizes em discutir qual recurso melhor se adapta às suas necessidades.
