O MariaDB Server oferece replicação assíncrona e síncrona. Ele pode ser configurado para ter uma replicação de várias fontes ou com uma configuração de vários mestres.
Para um aplicativo intensivo de leitura e gravação, uma configuração mestre-escravo é comum, mas pode diferir com base na pilha subjacente necessária para criar um ambiente de banco de dados altamente disponível.
Ter uma configuração de replicação mestre-escravo pode não satisfazer suas necessidades, especialmente em um ambiente de produção. Um servidor MariaDB sozinho (configuração mestre-escravo) não é suficiente para oferecer alta disponibilidade, pois ainda possui um único ponto de falha (SPOF).
O MariaDB introduziu um produto corporativo (Plataforma MariaDB) para resolver esse problema de alta disponibilidade. Ele inclui vários componentes:uma versão corporativa do MariaDB, MariaDB ColumnStore, MaxScale e conectores leves do MariaDB. Comparado a outros fornecedores com a mesma oferta de solução corporativa, pode ser uma opção econômica, mas nem todos precisam desse nível de complexidade.
Neste blog, mostraremos como usar o MariaDB Server usando replicação em um ambiente altamente disponível com a opção de usar todas as ferramentas gratuitas ou nosso software de gerenciamento econômico para executar e monitore sua infraestrutura do MariaDB Server.
Configuração da topologia de alta disponibilidade MariaDB
Uma configuração usual para uma topologia mestre-escravo com MariaDB Server usa abordagem assíncrona ou síncrona com apenas um mestre recebendo gravações, então replica suas alterações para os escravos como no diagrama abaixo:
Mas, novamente, isso não oferece alta disponibilidade e tem um ponto unico de falha. Se o mestre morrer, seu cliente de aplicativo não funcionará mais. Agora, precisamos adicionar na pilha para ter um mecanismo de failover automático para evitar SPOF e também oferecer balanceamento de carga para dividir leitura-gravação e de forma round-robin. Por enquanto, teremos o tipo de topologia,
Agora, essa topologia oferece mais segurança em termos de SPOF. O MaxScale fará a divisão de leitura e gravação dos nós do banco de dados do seu mestre contra os escravos. MaxScale faz uma abordagem perfeita ao lidar com esse tipo de configuração. MaxScale também possui detecção automática integrada. Portanto, quaisquer alterações que ocorram no estado dos nós do banco de dados, ele detectará e agirá de acordo. MaxScale tem a disponibilidade para proceder a um failover ou até mesmo um switchover. Para saber mais sobre seu mecanismo de failover, leia nosso blog anterior que aborda o mecanismo de failover MariaDB MaxScale.
Observe que o mecanismo de failover MaxScale com o MariaDB Monitor também tem suas limitações. É melhor aplicado apenas para uma configuração mestre-escravo sem configuração complicada. Isso significa que uma configuração mestre-mestre não é suportada. No entanto, MaxScale tem mais coisas a oferecer. Ele não apenas faz algum balanceamento de carga, pois executa divisões de leitura e gravação, mas também possui um SmartRouter integrado que envia a consulta para o nó com melhor desempenho. Embora isso não adicione o recurso de ser altamente disponível, mas ajuda os nós a ficarem presos no tráfego e evitar que certos nós de banco de dados tenham baixo desempenho, o que pode causar tempos limite ou um servidor totalmente indisponível causado por atividade intensiva de alto recurso em andamento .
Uma coisa como uma advertência de usar MaxScale, eles estão usando BSL (Business Source LICense). Você pode ter que revisar o FAQ antes de adotar este software.
Outra opção para escolher é usar uma abordagem mais conveniente. Pode ser econômico para você escolher usar o ClusterControl e ter proxies no meio usando HaProxy, MaxScale ou ProxySQL, para os quais o último pode ser configurado de leve a uma configuração mais em nível de produção que faz roteamento de consultas, filtragem de consultas, firewall ou segurança. Veja a ilustração abaixo:
Agora, em cima deles está o ClusterControl. O ClusterControl é configurado com alta disponibilidade, ou seja, CMON HA. Alternativamente, a camada proxy pode ser escolhida entre HaProxy - uma opção muito leve para escolher, MaxScale, como mencionado anteriormente, ou ProxySQL, que possui um conjunto de parâmetros mais refinado, se você deseja mais flexibilidade e configuração ideal para um configuração de produção. O ClusterControl tratará da detecção automática em termos do status de integridade dos nós, especialmente o mestre que é o nó principal para determinar se requer um failover ou não. Agora, isso pode ser mais autossuficiente, mas adiciona mais custo devido a vários nós necessários para implementar essa configuração e também usando o failover automático do ClusterControl, que se aplica à nossa licença avançada e corporativa. Mas, por outro lado, ele fornece toda a segurança, proteção e observabilidade para sua infraestrutura de banco de dados. Na verdade, é mais uma implementação corporativa de baixo custo em comparação com as soluções disponíveis no mercado global.
Implantando sua replicação MariaDB Master-Slave para alta disponibilidade
Vamos supor que você tenha uma configuração master-slave existente do MariaDB. Para este exemplo, usaremos o ClusterControl usando a edição gratuita da comunidade que você pode instalar e usar gratuitamente. Ele apenas torna seu trabalho fácil e rápido de configurar. Para fazer isso, você só precisa importar seu cluster de replicação MariaDB existente. Confira nosso blog anterior sobre como gerenciar MariaDB com ClusterControl. Para este blog, tenho a seguinte configuração inicialmente como meu cluster de replicação MariaDB, conforme visto abaixo:
Agora, vamos usar o MaxScale aqui como uma solução alternativa da Plataforma MariaDB que também oferece alta disponibilidade. Para fazer isso, é muito fácil usar o ClusterControl com apenas alguns cliques, você pode configurar seu MaxScale que está sendo executado em cima do seu cluster de replicação MariaDB existente. Para fazer isso, basta ir em Gerenciar → Load Balancer → MaxScale, e você poderá configurar e fornecer os valores apropriados conforme visto abaixo,
Em seguida, basta habilitar ou clicar na opção checkbox para selecionar quais servidores devem ser adicionado como parte de seu monitoramento MaxScale. Ver abaixo,
Supondo que você tenha mais de um nó MaxScale para adicionar, apenas repita o mesmos passos.
Por fim, configuraremos o Keepalived para manter nossos nós MaxScale sempre disponíveis sempre que necessário. Isso é muito rápido com apenas etapas simples usando o ClusterControl. Novamente, você precisa ir para Gerenciar → Load Balancer, mas em vez disso, selecione Keepalived,
Como você notou, coloquei meu Keepalived junto com MaxScale no mesmo nó do meu slave (192.168.10.30). Considerando que, por outro lado, o segundo (2º) Keepalived está sendo executado em 192.168.10.40 junto com Maxscale no mesmo host.
O resultado da topologia está pronto para produção, o que pode fornecer roteamento de consulta, alta disponibilidade e com failover automático equipado com monitoramento e observabilidade abrangentes usando o ClusterControl. Ver abaixo,
Conclusão
Usar apenas a replicação do MariaDB Server não oferece alta disponibilidade. Estender e usar ferramentas de terceiros irá equipá-lo para ter sua pilha de banco de dados altamente disponível, não apenas confiando nos produtos MariaDB ou mesmo usando a Plataforma MariaDB.
Existem maneiras de conseguir isso e gerenciá-lo de forma mais econômica. No entanto, há uma grande diferença em aproveitar essas soluções disponíveis no mercado, como o ClusterControl, pois oferece velocidade, menos complicações e, claro, a melhor observabilidade com eventos em tempo real e atualizados, não apenas a saúde mas também os eventos que ocorrem em seu cluster de banco de dados.
