Como controlar o failover de replicação para MySQL e MariaDB

O failover automatizado é praticamente obrigatório para muitos aplicativos - o tempo de atividade é um dado adquirido. É muito difícil aceitar que um aplicativo fique inativo por 20 ou 30 minutos porque alguém precisa ser chamado para fazer login e investigar a situação antes de agir.

No mundo real, as configurações de replicação tendem a crescer com o tempo para se tornarem complexas, às vezes confusas. E há restrições. Por exemplo, nem todo nó em uma configuração é um bom candidato mestre. Talvez o hardware seja diferente e algumas das réplicas tenham hardware menos poderoso, pois são dedicadas a lidar com alguns tipos específicos de carga de trabalho? Talvez você esteja no meio da migração para uma nova versão do MySQL e alguns dos slaves já tenham sido atualizados? Você prefere não ter um mestre na versão mais recente replicando para réplicas antigas, pois isso pode interromper a replicação. Se você tiver dois datacenters, um ativo e outro para recuperação de desastres, talvez prefira escolher candidatos mestres apenas no datacenter ativo, para manter o mestre próximo aos hosts do aplicativo. Essas são apenas situações de exemplo, nas quais você pode precisar de intervenção manual durante o processo de failover. Felizmente, muitas ferramentas de failover têm a opção de controlar o processo usando listas brancas e listas negras. Nesta postagem do blog, gostaríamos de mostrar alguns exemplos de como você pode influenciar o algoritmo do ClusterControl para escolher candidatos mestres.

Configuração de lista de permissões e lista negra

O ClusterControl oferece a opção de definir a lista branca e a lista negra de réplicas. Uma lista branca é uma lista de réplicas que se destinam a se tornarem candidatas mestres. Se nenhum deles estiver disponível (seja porque estão inativos, ou há transações errôneas, ou há outros obstáculos que impedem que algum deles seja promovido), o failover não será executado. Dessa forma, você pode definir quais hosts estão disponíveis para se tornar um candidato mestre. As listas negras, por outro lado, definem quais réplicas não são adequadas para se tornar um candidato mestre.

Ambas as listas podem ser definidas no arquivo de configuração cmon para um determinado cluster. Por exemplo, se seu cluster tem id de '1', você deseja editar '/etc/cmon.d/cmon_1.cnf'. Para whitelist você usará a variável ‘replication_failover_whitelist’, para blacklist será uma ‘replication_failover_blacklist’. Ambos aceitam uma lista separada por vírgulas de 'host:port'.

Vamos considerar a seguinte configuração de replicação. Temos um mestre ativo (10.0.0.141) que possui duas réplicas (10.0.0.142 e 10.0.0.143), ambas atuam como mestres intermediários e possuem uma réplica cada (10.0.0.144 e 10.0.0.147). Também temos um mestre em espera em um datacenter separado (10.0.0.145) que possui uma réplica (10.0.0.146). Esses hosts devem ser usados em caso de desastre. As réplicas 10.0.0.146 e 10.0.0.147 atuam como hosts de backup. Veja abaixo a captura de tela.

Dado que o segundo datacenter destina-se apenas à recuperação de desastres, não queremos que nenhum desses hosts seja promovido como mestre. Na pior das hipóteses, tomaremos uma ação manual. A infraestrutura do segundo datacenter não é dimensionada para o tamanho do datacenter de produção (há três réplicas a menos no datacenter de DR), portanto, ações manuais são necessárias de qualquer maneira antes que possamos promover um host no datacenter de DR. Também não gostaríamos que uma réplica de backup (10.0.0.147) fosse promovida. Também não queremos que uma terceira réplica na cadeia seja escolhida como mestre (mesmo que isso possa ser feito com GTID).

Configuração da lista de permissões

Podemos configurar uma lista branca ou uma lista negra para garantir que o failover seja tratado como quisermos. Nesta configuração específica, o uso da lista de permissões pode ser mais adequado - definiremos quais hosts podem ser usados para failover e, se alguém adicionar um novo host à configuração, ele não será considerado como candidato mestre até que alguém decida manualmente que é ok para usá-lo e adicioná-lo à lista de permissões. Se usássemos a lista negra, adicionar uma nova réplica em algum lugar da cadeia poderia significar que tal réplica poderia teoricamente ser usada automaticamente para failover, a menos que alguém diga explicitamente que ela não pode ser usada. Vamos ficar no lado seguro e definir uma whitelist em nosso arquivo de configuração de cluster (neste caso é /etc/cmon.d/cmon_1.cnf, pois temos apenas um cluster):

replication_failover_whitelist=10.0.0.141:3306,10.0.0.142:3306,10.0.0.143:3306

Temos que ter certeza de que o processo cmon foi reiniciado para aplicar as alterações:

service cmon restart

Vamos supor que nosso mestre travou e não pode ser alcançado pelo ClusterControl. Um trabalho de failover será iniciado:

A topologia ficará como abaixo:

Como você pode ver, o antigo mestre está desabilitado e o ClusterControl não tentará recuperá-lo automaticamente. Cabe ao usuário verificar o que aconteceu, copiar quaisquer dados que possam não ter sido replicados para o candidato mestre e reconstruir o mestre antigo:

Então é uma questão de algumas mudanças de topologia e podemos trazer a topologia para o estado original, apenas substituindo 10.0.0.141 por 10.0.0.142:

Configuração da lista negra

Agora vamos ver como funciona a lista negra. Mencionamos que, em nosso exemplo, pode não ser a melhor opção, mas vamos tentar por uma questão de ilustração. Colocaremos na lista negra todos os hosts, exceto 10.0.0.141, 10.0.0.142 e 10.0.0.143, pois esses são os hosts que queremos ver como candidatos mestres.

replication_failover_blacklist=10.0.0.145:3306,10.0.0.146:3306,10.0.0.144:3306,10.0.0.147:3306

Também reiniciaremos o processo cmon para aplicar as alterações de configuração:

service cmon restart

O processo de failover é semelhante. Novamente, assim que a falha principal for detectada, o ClusterControl iniciará um trabalho de failover.

Quando uma réplica pode não ser um bom candidato a mestre

Nesta breve seção, gostaríamos de discutir com mais detalhes alguns dos casos em que você pode não querer promover uma determinada réplica para se tornar um novo mestre. Espero que isso lhe dê algumas ideias sobre os casos em que você pode precisar considerar a indução de mais controle manual do processo de failover.

Versão diferente do MySQL

Primeiro, se sua réplica usa uma versão MySQL diferente da master, não é uma boa ideia promovê-la. De um modo geral, uma versão mais recente é sempre proibida, pois a replicação da nova para a versão antiga do MySQL não é suportada e pode não funcionar corretamente. Isso é relevante principalmente para versões principais (por exemplo, 8.0 replicando para 5.7), mas a boa prática é evitar essa configuração completamente, mesmo se estivermos falando de pequenas diferenças de versão (5.7.x+1 -> 5.7.x). A replicação da versão inferior para a superior/mais recente é suportada, pois é uma obrigação para o processo de atualização, mas ainda assim, você preferiria evitar isso (por exemplo, se seu mestre estiver em 5.7.x+1, você preferiria não substituí-lo com uma réplica em 5.7.x).

Funções diferentes

Você pode atribuir diferentes funções às suas réplicas. Você pode escolher um deles para que os desenvolvedores testem suas consultas em um conjunto de dados de produção. Você pode usar um deles para carga de trabalho OLAP. Você pode usar um deles para backups. Não importa o que seja, normalmente você não gostaria de promover essa réplica para mestre. Todas essas cargas de trabalho adicionais não padrão podem causar problemas de desempenho devido à sobrecarga adicional. Uma boa escolha para um candidato a mestre é uma réplica que está lidando com carga “normal”, mais ou menos o mesmo tipo de carga que o mestre atual. Você pode ter certeza de que ele lidará com a carga mestre após o failover se tiver manipulado antes disso.

Diferentes especificações de hardware

Mencionamos diferentes funções para réplicas. Não é incomum ver especificações de hardware diferentes também, especialmente em conjunto com diferentes funções. Por exemplo, um escravo de backup provavelmente não precisa ser tão poderoso quanto uma réplica regular. Os desenvolvedores também podem testar suas consultas em um banco de dados mais lento que o de produção (principalmente porque você não esperaria o mesmo nível de simultaneidade no banco de dados de desenvolvimento e produção) e, por exemplo, a contagem de núcleos de CPU pode ser reduzida. As configurações de recuperação de desastres também podem ser reduzidas em tamanho se sua função principal for acompanhar a replicação e espera-se que a configuração de DR tenha que ser dimensionada (verticalmente, dimensionando a instância e horizontalmente, adicionando mais réplicas) antes que o tráfego possa ser redirecionado para ele.

Réplicas atrasadas

Algumas das réplicas podem ser atrasadas - é uma maneira muito boa de reduzir o tempo de recuperação se os dados forem perdidos, mas os torna candidatos mestres muito ruins. Se uma réplica estiver atrasada em 30 minutos, você perderá esses 30 minutos de transações ou terá que esperar (provavelmente não 30 minutos, pois, provavelmente, a réplica pode se recuperar mais rapidamente) para que a réplica aplique todas as transações atrasadas. O ClusterControl permite que você escolha se deseja esperar ou se deseja fazer o failover imediatamente, mas isso funcionaria bem para um atraso muito pequeno - dezenas de segundos no máximo. Se o failover deve levar alguns minutos, não faz sentido usar essa réplica e, portanto, é uma boa ideia colocá-la na lista negra.

Datacenter diferente

Mencionamos configurações de DR reduzidas, mas mesmo que seu segundo datacenter seja dimensionado para o tamanho da produção, ainda pode ser uma boa ideia manter os failovers apenas em um único DC. Para começar, seus hosts de aplicativos ativos podem estar localizados no datacenter principal, portanto, mover o mestre para um DC em espera aumentaria significativamente a latência para consultas de gravação. Além disso, no caso de uma divisão de rede, convém lidar manualmente com essa situação. O MySQL não possui um mecanismo de quorum embutido, portanto, é meio complicado lidar corretamente (de maneira automática) com a perda de rede entre dois datacenters.