Drupal é um sistema de gerenciamento de conteúdo (CMS) projetado para criar tudo, desde pequenos até grandes sites corporativos. Mais de 1.000.000 de sites são executados no Drupal e são usados para criar muitos dos sites e aplicativos que você usa todos os dias (incluindo este). O Drupal possui um ótimo conjunto de recursos padrão, como fácil criação de conteúdo, desempenho confiável e excelente segurança. O que diferencia o Drupal é sua flexibilidade, pois a modularidade é um de seus princípios fundamentais.
O Drupal também é uma ótima opção para criar estruturas digitais integradas. Você pode estendê-lo com os milhares de complementos disponíveis. Esses módulos expandem a funcionalidade do Drupal. Os temas permitem que você personalize a apresentação do seu conteúdo e as distribuições (pacotes Drupal) são pacotes que você pode usar como kits iniciais. Você pode usar todas essas funcionalidades para misturar e combinar para aprimorar as principais habilidades do Drupal ou integrar o Drupal com serviços externos. É um software de gerenciamento de conteúdo poderoso e escalável.
O Drupal usa bancos de dados para armazenar seu conteúdo da web. Quando seu site ou aplicativo baseado em Drupal está passando por uma grande quantidade de tráfego, isso pode afetar seu servidor de banco de dados. Quando estiver nessa situação, você precisará de balanceamento de carga, alta disponibilidade e uma arquitetura redundante para manter seu banco de dados online.
Quando comecei a pesquisar este blog, percebi que existem muitas respostas para esse problema online, mas as soluções recomendadas eram muito desatualizadas. Isso pode ser resultado do aumento da participação de mercado do WordPress, resultando em uma comunidade de código aberto menor. O que encontrei foram alguns exemplos de implementação de alta disponibilidade usando Master/Master (High Availability) ou Master/Master/Slave (High Availability/High Performance).
O Drupal oferece suporte para uma ampla variedade de bancos de dados, mas foi inicialmente projetado usando variantes do MySQL. Embora o uso do MySQL seja totalmente suportado, existem abordagens melhores que você pode implementar. A implementação dessas outras abordagens, no entanto, se não for feita corretamente, pode fazer com que seu site sofra grandes períodos de inatividade, faça com que seu aplicativo sofra problemas de desempenho e possa resultar em problemas de gravação para seus escravos. A execução da manutenção também seria difícil, pois você precisa de failover para aplicar as atualizações ou patches do servidor (hardware ou software) sem tempo de inatividade. Isso é especialmente verdadeiro se você tiver uma grande quantidade de dados, causando um grande impacto potencial em seus negócios.
Estas são situações que você não quer que aconteçam e é por isso que neste blog vamos discutir como você pode implementar o failover de banco de dados para seus bancos de dados MySQL ou PostgreSQL.
Por que seu site Drupal precisa de failover de banco de dados?
Da Wikipedia, “failover é alternar para um servidor de computador redundante ou em espera, sistema, componente de hardware ou rede após a falha ou encerramento anormal do aplicativo, servidor, sistema, componente de hardware ou rede anteriormente ativo. Failover e switchover são essencialmente a mesma operação, exceto que o failover é automático e geralmente opera sem aviso, enquanto o switchover requer intervenção humana.”
Em operações de banco de dados, a alternância também é um termo usado para failover manual, o que significa que requer uma pessoa para operar o failover. O failover é útil para qualquer administrador, pois isola problemas indesejados, como exclusões/quedas acidentais de tabelas, longas horas de inatividade causando impacto nos negócios, corrupção do banco de dados ou corrupção no nível do sistema.
O Failover de banco de dados consiste em mais de um único nó de banco de dados, fisicamente ou virtualmente. Idealmente, como o failover exige que você alterne para um nó diferente, você também pode alternar para um servidor de banco de dados diferente, se um host estiver executando várias instâncias de banco de dados em um único host. Isso ainda pode ser switchover ou failover, mas normalmente é mais redundância e alta disponibilidade caso ocorra uma catástrofe nesse host atual.
Failover MySQL para Drupal
A execução de um failover para seu aplicativo baseado em Drupal requer que os dados manipulados pelo banco de dados não sejam diferenciados nem separados. Existem várias soluções disponíveis, e já discutimos algumas delas em blogs anteriores do Vários Nines. Você provavelmente pode querer ler nossa Introdução ao Failover for MySQL Replication - o 101 Blog.
A alternância mestre-escravo
As abordagens mais comuns para MySQL Failover é usar o switch over master-slave ou o failover manual. Existem duas abordagens que você pode fazer aqui:
- Você pode implementar seu banco de dados com uma típica replicação assíncrona mestre-escravo.
- ou pode implementar com replicação mestre-escravo assíncrona usando replicação baseada em GTID.
Mudar para outro mestre pode ser mais rápido e fácil. Isso pode ser feito com a seguinte sintaxe do MySQL:
mysql> SET GLOBAL read_only = 1; /* enable read-only */
mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_LOG_FILE = '<master-log-file>', MASTER_LOG_POS=<master_log_position>; /* master information to connect */
mysql> START SLAVE; /* start replication */
mysql> SHOW SLAVE STATUS\G /* check replication status */ou com GTID, você pode simplesmente fazer,
...
mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_AUTO_POSITION = 1; /* master information to connect */
...
WitUsar a abordagem não-GTID requer que você determine primeiro o arquivo de log do mestre e a pos de log do mestre. Você pode determinar isso observando o status do mestre no nó mestre antes de alternar.
mysql> MASTER STATUS;Você também pode considerar fortalecer seu servidor adicionando sync_binlog =1 e innodb_flush_log_at_trx_commit =1, pois, no caso de seu mestre travar, você terá uma chance maior de que as transações do mestre sejam sincronizadas com seu escravo ( s). Nesse caso, o mestre promovido tem uma chance maior de ser um nó de fonte de dados consistente.
Esta, no entanto, pode não ser a melhor abordagem para seu banco de dados Drupal, pois pode impor longos tempos de inatividade se não for executado corretamente, como ser retirado abruptamente. Se o nó do banco de dados mestre apresentar um bug que resultará na falha de um banco de dados, você precisará que seu aplicativo aponte para outro banco de dados aguardando em espera como seu novo mestre ou que seu escravo seja promovido a mestre. Você precisará especificar exatamente qual nó deve assumir o controle e, em seguida, determinar o atraso e a consistência desse nó. Conseguir isso não é tão fácil quanto apenas fazer SET GLOBAL read_only=1; MUDAR MESTRE PARA… (etc), existem certas situações que requerem uma análise mais profunda, olhando para as transações viáveis que precisam estar presentes naquele servidor standby ou master promovido, para que isso seja feito.
Failover do Drupal usando MHA
Uma das ferramentas mais comuns para failover automático e manual é o MHA. Já existe há muito tempo e ainda é usado por muitas organizações. Você pode conferir esses blogs anteriores que temos sobre o assunto, Principais problemas comuns com MHA e como corrigi-los ou Ferramentas de alta disponibilidade do MySQL - Comparando MHA, MRM e ClusterControl.
Failover do Drupal usando o orquestrador
Orchestrator foi amplamente adotado agora e está sendo usado por grandes organizações como Github e Booking.com. Ele não apenas permite gerenciar um failover, mas também gerenciamento de topologia, descoberta de host, refatoração e recuperação. Há um bom blog externo aqui que achei muito útil aprender sobre seu mecanismo de failover com o Orchestrator. É uma série de blogs em duas partes; parte um e parte dois.
Failover do Drupal usando MaxScale
MaxScale não é apenas um balanceador de carga projetado para o servidor MariaDB, ele também estende alta disponibilidade, escalabilidade e segurança para MariaDB e, ao mesmo tempo, simplifica o desenvolvimento de aplicativos ao desacoplá-lo da infraestrutura de banco de dados subjacente. Se você estiver usando o MariaDB, o MaxScale pode ser uma tecnologia relevante para você. Confira nossos blogs anteriores sobre como você pode usar o mecanismo de failover MaxScale.
Failover do Drupal usando ClusterControl
O ClusterControl de Severalnines oferece uma ampla gama de soluções de monitoramento e gerenciamento de banco de dados. Parte das soluções que oferecemos é failover automático, failover manual e recuperação de cluster/nó. Isso é muito útil, pois atua como seu administrador de banco de dados virtual, notificando você em tempo real caso seu cluster esteja em “modo de pânico”, enquanto a recuperação está sendo gerenciada pelo sistema. Você pode conferir este blog Como automatizar o failover de banco de dados com o ClusterControl para saber mais sobre o failover do ClusterControl.
Outras soluções MySQL
Algumas das abordagens antigas ainda são aplicáveis quando você deseja fazer failover. Há MMM, MRM, ou você pode fazer check-out Group Replication ou Galera (observação:Galera não usa replicação assíncrona, em vez de síncrona). O failover em um Galera Cluster não funciona da mesma forma que na replicação assíncrona. Com o Galera você pode simplesmente escrever em qualquer nó ou, se você implementar uma abordagem mestre-escravo, você pode direcionar sua aplicação para outro nó que será o gravador ativo do cluster.
Failover do PostgreSQL do Drupal
Como o Drupal suporta PostgreSQL, também verificaremos as ferramentas para implementar um processo de failover ou switchover para PostgreSQL. O PostgreSQL usa Replicação de Streaming integrada, mas você também pode configurá-lo para usar uma Replicação Lógica (adicionada como um elemento central do PostgreSQL na versão 10).
Failover do Drupal usando pg_ctlcluster
Se seu ambiente for Ubuntu, usar pg_ctlcluster é uma maneira simples e fácil de obter failover. Por exemplo, você pode simplesmente executar o seguinte comando:
$ pg_ctlcluster 9.6 pg_7653 promoteou com RHEL/Centos, você pode usar o comando pg_ctl como,
$ sudo -iu postgres /usr/lib/postgresql/9.6/bin/pg_ctl promote -D /data/pgsql/slave/data
server promotingVocê também pode acionar o failover de um servidor de espera de envio de log criando um arquivo de acionador com o nome do arquivo e o caminho especificados pelo trigger_file no recovery.conf.
Você deve ter cuidado com a promoção de espera ou promoção de escravo aqui, pois pode ter que garantir que apenas um mestre esteja aceitando a solicitação de leitura e gravação. Isso significa que, ao fazer a alternância, talvez seja necessário garantir que o mestre anterior tenha sido relaxado ou interrompido.
Cuidar da alternância ou do failover manual do servidor primário para o de espera pode ser rápido, mas requer algum tempo para preparar novamente o cluster de failover. Alternar regularmente do primário para o standby é uma prática útil, pois permite um tempo de inatividade regular em cada sistema para manutenção. Isso também serve como um teste do mecanismo de failover, para garantir que ele realmente funcione quando você precisar. Procedimentos de administração por escrito são sempre aconselhados.
Failover automático do PostgreSQL do Drupal
Em vez de uma abordagem manual, você pode exigir failover automático. Isso é especialmente necessário quando um servidor fica inativo devido a falha de hardware ou corrupção de máquina virtual. Você também pode exigir que um aplicativo execute automaticamente o failover para diminuir o tempo de inatividade do seu aplicativo Drupal. Veremos agora algumas dessas ferramentas que podem ser utilizadas para failover automático.
Failover do Drupal usando Patroni
Patroni é um modelo para você criar sua própria solução personalizada e de alta disponibilidade usando Python e - para máxima acessibilidade - uma loja de configuração distribuída como ZooKeeper, etcd, Consul ou Kubernetes. Engenheiros de banco de dados, DBAs, engenheiros de DevOps e SREs que desejam implantar rapidamente o PostgreSQL de alta disponibilidade no datacenter - ou em qualquer outro lugar - o acharão útil
Failover do Drupal usando Pgpool
Pgpool-II é um software proxy que fica entre os servidores PostgreSQL e um cliente de banco de dados PostgreSQL. Além de ter um failover automático, ele possui vários recursos que incluem pool de conexões, balanceamento de carga, replicação e limitação das conexões excedentes. Você pode ler mais sobre essa ferramenta em nosso blog de três partes; parte um, parte dois, parte três.
Failover do Drupal usando pglookout
pglookout é um daemon de monitoramento de replicação e failover do PostgreSQL. O pglookout monitora os nós do banco de dados, seu status de replicação e age de acordo com esse status. Por exemplo, chamar um comando de failover predefinido para promover um novo mestre caso o anterior esteja ausente.
pglookout suporta dois tipos de nós diferentes, aqueles que são instalados nos próprios nós de banco de dados e nós observadores que podem ser instalados em qualquer lugar. O propósito de ter pglookout nos nós do banco de dados PostgreSQL é monitorar o status de replicação do cluster e agir de acordo, os observadores têm uma missão mais limitada:eles apenas observam o status do cluster para dar outro ponto de vista ao estado do cluster.
Failover do Drupal usando repmgr
repmgr é um conjunto de ferramentas de código aberto para gerenciar replicação e failover em um cluster de servidores PostgreSQL. Ele aprimora os recursos internos de espera a quente do PostgreSQL com ferramentas para configurar servidores em espera, monitorar a replicação e executar tarefas administrativas, como operações de failover ou alternância manual.
repmgr fornece suporte avançado para mecanismos de replicação integrados do PostgreSQL desde que foram introduzidos na versão 9.0. A atual série repmgr, repmgr 4, suporta os mais recentes desenvolvimentos na funcionalidade de replicação introduzidos a partir do PostgreSQL 9.3, como replicação em cascata, comutação de linha do tempo e backups básicos por meio do protocolo de replicação.
Failover do Drupal usando ClusterControl
ClusterControl suporta failover automático para PostgreSQL. Se você tiver um incidente, seu escravo pode ser promovido ao status de mestre automaticamente. Com o ClusterControl, você também pode implantar banco de dados PostgreSQL autônomo, replicado ou em cluster. Você também pode adicionar ou remover facilmente um nó com uma única ação.
Outras soluções de failover do PostgreSQL Drupal
Certamente existem soluções de failover automático que eu poderia ter perdido neste blog. Se sim, adicione seus comentários abaixo para que possamos conhecer seus pensamentos e experiências com sua implementação e configuração para failover, especialmente para sites ou aplicativos Drupal.
Soluções adicionais para failover do Drupal
Enquanto as ferramentas que mencionei anteriormente definitivamente tratam da solução para seus problemas com failover, adicionar algumas ferramentas que tornem o failover bem mais fácil, seguro e tenham um isolamento total entre sua camada de banco de dados pode ser satisfatório.
Failover do Drupal usando ProxySQL
Com o ProxySQL, você pode simplesmente apontar seus sites ou aplicativos Drupal para o host do servidor ProxySQL e ele designará qual nó receberá gravações e quais nós receberão as leituras. A mágica acontece de forma transparente dentro da camada TCP e nenhuma alteração é necessária para a configuração do seu aplicativo/site. Além disso, o ProxySQL também atua como seu balanceador de carga para suas solicitações de gravação e leitura para o tráfego do banco de dados. Isso só é aplicável se você estiver usando variantes de banco de dados MySQL.
Failover do Drupal usando HAProxy com Keepalived
Usar HAProxy e Keepalived adiciona mais alta disponibilidade e redundância ao banco de dados do Drupal. Se você quiser fazer failover, isso pode ser feito sem que seu aplicativo saiba o que está acontecendo na camada de banco de dados. Basta apontar sua aplicação para o IP vrrp que você configurou em seu Keepalived e tudo será tratado com total isolamento da sua aplicação. Ter um failover automático será tratado de forma transparente e inadvertida pelo seu aplicativo para que nenhuma alteração ocorra uma vez que, por exemplo, um desastre tenha ocorrido e uma recuperação ou failover tenha sido aplicado. O bom dessa configuração é que ela é aplicável para bancos de dados MySQL e PostgreSQL. Sugiro que você confira nosso blog PostgreSQL Load Balancing Using HAProxy &Keepalived para saber mais sobre como fazer isso.
Todas as opções acima são suportadas pelo ClusterControl. Você pode implantar ou importar o banco de dados e, em seguida, implantar ProxySQL, MaxScale ou HAProxy &Keepalived. Tudo será gerenciado, monitorado e configurado automaticamente sem nenhuma configuração adicional necessária para você. Tudo acontece em segundo plano e cria automaticamente um pronto para produção.
Conclusão
Ter um site ou aplicativo Drupal sempre ativo, especialmente se você espera uma grande quantidade de tráfego, pode ser complicado de criar. No entanto, se você tiver as ferramentas certas, a configuração certa e a pilha de tecnologia certa, é possível obter alta disponibilidade e redundância.
E se não? Bem, então o ClusterControl irá configurá-lo e mantê-lo para você. Como alternativa, você pode criar uma configuração usando as tecnologias mencionadas neste blog, a maioria das quais são ferramentas gratuitas e de código aberto que atendem às suas necessidades.
