Dicas para migrar da replicação do MySQL para o MySQL Galera Cluster 4.0

Nós já escrevemos sobre o que há de novo no MySQL Galera Cluster 4.0, Handling Large Transactions with Streaming Replication e MariaDB 10.4 e apresentamos alguns guias sobre como usar o novo recurso Streaming Replication em uma série parte 1 e parte 2.

A migração de sua tecnologia de banco de dados da Replicação MySQL para o MySQL Galera Cluster requer que você tenha as habilidades certas e uma compreensão do que está fazendo para ter sucesso. Neste blog, compartilharemos algumas dicas para migrar de uma configuração do MySQL Replication para o MySQL Galera Cluster 4.0.

As diferenças entre a replicação do MySQL e o Galera Cluster

Se você ainda não estiver familiarizado com o Galera, sugerimos que você consulte nosso Tutorial Galera Cluster for MySQL. Galera Cluster usa um nível totalmente diferente de replicação baseado em replicação síncrona, em contraste com a Replicação MySQL que usa replicação assíncrona (mas pode ser configurada também para obter uma replicação semi-síncrona).

O Galera Cluster também oferece suporte à replicação de vários mestres. Ele é capaz de aplicação paralela irrestrita (ou seja, “replicação paralela”), replicação multicast e provisionamento automático de nós.

O foco principal do Galera Cluster é a consistência dos dados, enquanto que com o MySQL Replication, é propenso à inconsistência de dados (que pode ser evitada com as melhores práticas e configuração adequada, como aplicar somente leitura nos escravos para evitar gravações indesejadas dentro dos escravos).

Embora as transações recebidas pelo Galera sejam aplicadas a todos os nós ou não, cada um desses nós certifica o conjunto de gravação replicado na fila do aplicador (confirmações de transação), que também inclui informações sobre todos os bloqueios que foram mantidos pelo banco de dados durante a transação. Esses conjuntos de gravação, uma vez que nenhum bloqueio conflitante seja identificado, são aplicados. Até este ponto, as transações são consideradas confirmadas e continuam a aplicá-las ao tablespace. Ao contrário da replicação assíncrona, essa abordagem também é chamada de replicação virtualmente síncrona, pois as gravações e confirmações ocorrem em um modo lógico síncrono, mas a gravação e a confirmação reais no espaço de tabela ocorrem independentemente e são assíncronas em cada nó.

Ao contrário do MySQL Replication, um Galera Cluster é um verdadeiro escravo multi-master, multi-threaded, um puro hot-standby, sem necessidade de master-failover ou divisão de leitura-gravação. No entanto, migrar para o Galera Cluster não significa uma resposta automática para seus problemas. O Galera Cluster suporta apenas InnoDB, portanto, pode haver modificações de design se você estiver usando mecanismos de armazenamento MyISAM ou Memory.

Convertendo tabelas não InnoDB para InnoDB

O Galera Cluster permite que você use o MyISAM, mas não foi para isso que o Galera Cluster foi projetado. O Galera Cluster foi projetado para implementar estritamente a consistência de dados em todos os nós do cluster e isso requer um mecanismo de banco de dados compatível com ACID forte. O InnoDB é um motor que possui fortes capacidades nesta área e é recomendado que você use o InnoDB; especialmente quando se trata de transações.

Se você estiver usando o ClusterControl, poderá se beneficiar facilmente para determinar sua(s) instância(s) de banco de dados para qualquer tabela MyISAM fornecida pelo Performance Advisors. Você pode encontrar isso na aba Performance → Advisors. Por exemplo,

Se você precisar de tabelas MyISAM e MEMORY, você ainda pode usá-lo, mas faça certifique-se de seus dados que não precisam ser replicados. Você pode usar seus dados armazenados para somente leitura e usar "INICIAR TRANSAÇÃO READONLY" sempre que apropriado.

Adicionando chaves primárias às suas tabelas InnoDB

Como o Galera Cluster suporta apenas InnoDB, é muito importante que todas as suas tabelas tenham um índice clusterizado (também chamado de chave primária ou chave exclusiva). Para obter o melhor desempenho de consultas, inserções e outras operações de banco de dados, é muito importante que você defina cada tabela com uma(s) chave(s) exclusiva(s), pois o InnoDB usa o índice clusterizado para otimizar as operações de pesquisa e DML mais comuns para cada tabela . Isso ajuda a evitar consultas de longa execução no cluster e possivelmente pode diminuir a velocidade das operações de gravação/leitura no cluster.

No ClusterControl, existem orientadores que podem notificá-lo sobre isso. Por exemplo, em seu cluster mestre/escravo de Replicação MySQL, você receberá um alarme do ou exibirá a lista de orientadores. A captura de tela de exemplo abaixo revela que você não tem tabelas sem chave primária:

Identifique um nó mestre (ou gravador ativo)

O Galera Cluster é puramente uma verdadeira replicação multimestre. No entanto, isso não significa que você está livre para escrever qualquer nó que você gostaria de direcionar. Uma coisa a identificar é que, ao escrever em um nó diferente e uma transação conflitante for detectada, você entrará em um problema de impasse como abaixo:

2019-11-14T21:14:03.797546Z 12 [Note] [MY-011825] [InnoDB] *** Priority TRANSACTION:

TRANSACTION 728431, ACTIVE 0 sec starting index read

mysql tables in use 1, locked 1

MySQL thread id 12, OS thread handle 140504401893120, query id 1414279 Applying batch of row changes (update)

2019-11-14T21:14:03.797696Z 12 [Note] [MY-011825] [InnoDB] *** Victim TRANSACTION:

TRANSACTION 728426, ACTIVE 3 sec updating or deleting

mysql tables in use 1, locked 1

, undo log entries 11409

MySQL thread id 57, OS thread handle 140504353195776, query id 1414228 localhost root updating

update sbtest1_success set k=k+1 where id > 1000 and id < 100000

2019-11-14T21:14:03.797709Z 12 [Note] [MY-011825] [InnoDB] *** WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 1663 page no 11 n bits 144 index PRIMARY of table `sbtest`.`sbtest1_success` trx id 728426 lock_mode X

Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0

 0: len 8; hex 73757072656d756d; asc supremum;;

O problema com vários nós gravando sem identificar um nó de gravador ativo atual, você acabará com esses problemas que são problemas muito comuns que eu vi ao usar o Galera Cluster ao escrever em vários nós em o mesmo tempo. Para evitar isso, você pode usar a abordagem de configuração de mestre único:

Na documentação,

Para relaxar o controle de fluxo, você pode usar as configurações abaixo:

wsrep_provider_options = "gcs.fc_limit = 256; gcs.fc_factor = 0.99; gcs.fc_master_slave = YES"

O acima requer uma reinicialização do servidor, pois fc_master_slave não é dinâmico.

Ative o modo de depuração para registrar conflitos ou impasses

Depurar ou rastrear problemas com o Galera Cluster é muito importante. Os bloqueios no Galera são implementados de maneira diferente em comparação com a Replicação do MySQL. Ele usa bloqueio otimista ao lidar com transações em todo o cluster. Ao contrário da Replicação do MySQL, ele possui apenas um bloqueio pessimista que não sabe se há essa mesma transação ou conflitante sendo executada em um co-mestre em uma configuração multi-mestre. O Galera ainda usa bloqueio pessimista, mas no nó local, pois é gerenciado pelo InnoDB, que é o mecanismo de armazenamento suportado. Galera usa bloqueio otimista quando vai para outros nós. Isso significa que nenhuma verificação é feita com outros nós no cluster quando os bloqueios locais são alcançados (bloqueio pessimista). Galera assume que, uma vez que a transação passe pela fase de commit dentro do storage engine e os outros nós sejam informados, tudo ficará bem e não surgirão conflitos.

Na prática, é melhor habilitar wsrep_logs_conflicts. Isso registrará os detalhes do MDL conflitante, bem como os bloqueios do InnoDB no cluster. A ativação dessa variável pode ser definida dinamicamente, mas ressalte uma vez que isso seja ativado. Ele preencherá detalhadamente seu arquivo de log de erros e poderá encher seu disco quando o tamanho do arquivo de log de erros for muito grande.

Tenha cuidado com suas consultas DDL

Diferente da Replicação do MySQL, a execução de uma instrução ALTER pode afetar apenas as conexões de entrada que requerem acessar ou referenciar a tabela alvo de sua instrução ALTER. Também pode afetar escravos se a tabela for grande e pode trazer lag escravo. No entanto, as gravações em seu mestre não serão bloqueadas, desde que suas consultas não entrem em conflito com o ALTER atual. No entanto, esse não é totalmente o caso ao executar suas instruções DDL, como ALTER com Galera Cluster. As instruções ALTER podem trazer problemas como Galera Cluster travado devido ao bloqueio em todo o cluster ou o controle de fluxo começa a relaxar a replicação enquanto alguns nós estão se recuperando de grandes gravações.

Em algumas situações, você pode acabar tendo tempo de inatividade no Galera Cluster se essa tabela for muito grande e for uma tabela primária e vital para seu aplicativo. No entanto, isso pode ser alcançado sem tempo de inatividade. Como Rick James apontou em seu blog, você pode seguir as recomendações abaixo:

RSU x TOI

• Atualização de esquema contínuo =faça manualmente um nó (offline) por vez
• Isolamento total da ordem =O Galera sincroniza para que seja feito ao mesmo tempo (na sequência de replicação) em todos os nós. RSU e TOI

Cuidado:Como não há como sincronizar os clientes com o DDL, você deve certificar-se de que os clientes estejam satisfeitos com o esquema antigo ou o novo. Caso contrário, você provavelmente precisará derrubar todo o cluster enquanto alterna simultaneamente o esquema e o código do cliente.

Um DDL "rápido" também pode ser feito via TOI. Esta é uma lista provisória de tais:

• CRIAR/DROP/RENOMEAR BANCO DE DADOS/TABELA
• ALTER para alterar DEFAULT
• ALTER para alterar a definição de ENUM ou SET (consulte as advertências no manual)
• Certos PARTITION ALTERs que são rápidos.
• DROP INDEX (exceto PRIMARY KEY)
• ADICIONAR ÍNDICE?
• Outros ALTERs em tabelas 'pequenas'.
• Com o 5.6 e especialmente o 5.7 com muitos casos ALTER ALGORITHM=INPLACE, verifique quais ALTERs devem ser feitos e de que maneira.

Caso contrário, use RSU. Faça o seguinte separadamente para cada nó:

SET GLOBAL wsrep_OSU_method='RSU';

Isso também retira o nó do cluster.

ALTER TABLE
SET GLOBAL wsrep_OSU_method='TOI';

Coloca de volta, levando à ressincronização (espero que um IST rápido, não um SST lento)

Preserve a consistência do seu cluster

O Galera Cluster não oferece suporte a filtros de replicação como binlog_do_db ou binlog_ignore_db, pois o Galera não depende de log binário. Ele se baseia no arquivo de buffer de anel também chamado GCache, que armazena conjuntos de gravação que são replicados ao longo do cluster. Você não pode aplicar nenhum comportamento ou estado inconsistente de tais nós de banco de dados.

O Galera, por outro lado, implementa estritamente a consistência de dados dentro do cluster. Ainda é possível que haja inconsistência onde linhas ou registros não possam ser encontrados. Por exemplo, configurar sua variável wsrep_OSU_method RSU ou TOI para suas instruções DDL ALTER pode trazer um comportamento inconsistente. Confira este blog externo da Percona discutindo sobre inconsistência com Galera com TOI vs RSU.

Configurar wsrep_on=OFF e, posteriormente, executar consultas DML ou DDL pode ser perigoso para seu cluster. Você também deve revisar seus procedimentos armazenados, gatilhos, funções, eventos ou visualizações se os resultados não dependerem do estado ou ambiente de um nó. Quando um determinado nó pode ser inconsistente, pode potencialmente fazer com que todo o cluster fique inativo. Assim que o Galera detectar um comportamento inconsistente, o Galera tentará sair do cluster e encerrar esse nó. Portanto, é possível que todos os nós sejam inconsistentes, deixando você em um estado de dilema.

Se um nó do Galera Cluster também sofrer uma falha, especialmente em um período de tráfego intenso, é melhor não iniciar o nó imediatamente. Em vez disso, execute um SST completo ou traga uma nova instância o mais rápido possível ou quando o tráfego diminuir. Pode ser possível que o nó possa trazer um comportamento inconsistente que pode ter dados corrompidos.

Segregar transações grandes e determinar se deve usar a replicação de streaming 

Vamos direto a este. Uma das maiores mudanças, especialmente no Galera Cluster 4.0, é a replicação de streaming. Nas versões anteriores do Galera Cluster 4.0, ele limita as transações <2GiB que normalmente são controladas pelas variáveis ​​wsrep_max_ws_rows e wsrep_max_ws_size. Desde o Galera Cluster 4.0, você pode enviar> 2GiB de transações, mas deve determinar o tamanho dos fragmentos a serem processados ​​durante a replicação. Ele deve ser definido por sessão e as únicas variáveis ​​que você precisa tomar cuidado são wsrep_trx_fragment_unit e wsrep_trx_fragment_size. Desativar a replicação de streaming é simples, pois definir o wsrep_trx_fragment_size =0 fará isso. Observe que, replicar uma transação grande também possui sobrecarga nos nós escravos (nós que estão replicando em relação ao nó mestre/gravador ativo atual), pois os logs serão gravados na tabela wsrep_streaming_log no banco de dados MySQL.

Outra coisa a acrescentar, já que você está lidando com uma transação grande, é considerável que sua transação possa levar algum tempo para terminar, portanto, definir a variável innodb_lock_wait_timeout como alta deve ser levada em consideração. Defina isso por sessão dependendo do tempo estimado, mas maior do que o tempo estimado para terminar, caso contrário, aumente o tempo limite.

Recomendamos que você leia este blog anterior sobre a replicação de streaming em ação.

Replicando declarações de GRANTs

Se você estiver usando GRANTs e operações relacionadas, aja nas tabelas MyISAM/Aria no banco de dados `mysql`. As instruções GRANT serão replicadas, mas as tabelas subjacentes não. Então isso significa que INSERT INTO mysql.user ... não será replicado porque a tabela é MyISAM.

No entanto, o acima pode não ser mais verdade desde que Percona XtraDB Cluster(PXC) 8.0 (atualmente experimental) como tabelas de esquema mysql foram convertidos para InnoDB, enquanto no MariaDB 10.4, algumas das tabelas ainda são no formato Aria, mas outros estão em CSV ou InnoDB. Você deve determinar qual versão e provedor do Galera você possui, mas é melhor evitar o uso de instruções DML referenciando o esquema mysql. Caso contrário, você poderá obter resultados inesperados, a menos que tenha certeza de que este é o PXC 8.0.

Transações XA, LOCK/UNLOCK TABLES, GET_LOCK/RELEASE_LOCK não são suportados

O Galera Cluster não oferece suporte a transações XA, pois as transações XA tratam de reversão e confirmação de maneira diferente. As instruções LOCK/UNLOCK ou GET_LOCK/RELEASE_LOCK são perigosas para serem aplicadas ou usadas com o Galera. Você pode experimentar uma falha ou bloqueios que não podem ser eliminados e permanecem bloqueados. Por exemplo,

---TRANSACTION 728448, ACTIVE (PREPARED) 13356 sec

mysql tables in use 2, locked 2

3 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 5

MySQL thread id 67, OS thread handle 140504353195776, query id 1798932 localhost root wsrep: write set replicated and certified (13)

insert into sbtest1(k,c,pad) select k,c,pad from sbtest1_success limit 5

Esta transação já foi desbloqueada e até mesmo foi eliminada, mas sem sucesso. Sugerimos que você redesenhe seu cliente de aplicação e se livre dessas funções ao migrar para o Galera Cluster.

Estabilidade de rede é OBRIGATÓRIO!!!

O Galera Cluster pode funcionar mesmo com topologia inter-WAN ou topologia inter-geo sem problemas (verifique este blog sobre como implementar topologia inter-geo com Galera). No entanto, se a conectividade de rede entre cada nó não for estável ou estiver inativando intermitentemente por um tempo insuspeito, isso poderá ser problemático para o cluster. É melhor que você tenha um cluster em execução em uma rede privada e local onde cada um desses nós esteja conectado. Ao projetar um nó como uma recuperação de desastre, planeje criar um cluster se eles estiverem em uma região ou geografia diferente. Você pode começar a ler nosso blog anterior, Using MySQL Galera Cluster Replication to Create a Geo-Distributed Cluster:Part One, pois isso pode ajudá-lo a decidir melhor a topologia do Galera Cluster.

Outra coisa a acrescentar sobre o investimento em seu hardware de rede, seria problemático se sua taxa de transferência de rede fornecesse uma velocidade menor durante a reconstrução de uma instância durante o IST ou pior no SST, especialmente se seu conjunto de dados for enorme . Pode levar longas horas de transferência de rede e isso pode afetar a estabilidade de seu cluster, especialmente se você tiver um cluster de 3 nós, enquanto 2 nós não estiverem disponíveis onde esses 2 são um doador e um associado. Observe que, durante a fase SST, os nós DONOR/JOINER não podem ser usados ​​até que finalmente seja possível sincronizar com o cluster primário.

Na versão anterior do Galera, quando se trata de seleção de nó doador, o doador State Snapshot Transfer (SST) era selecionado aleatoriamente. No Glera 4, ele melhorou muito mais e tem a possibilidade de escolher o doador certo dentro do cluster, pois favorecerá um doador que possa fornecer uma Transferência Incremental de Estado (IST), ou escolher um doador no mesmo segmento. Alternativamente, você pode definir a variável wsrep_sst_donor para o doador certo que você gostaria de sempre escolher.

Faça backup de seus dados e faça testes rígidos durante a migração e antes da produção

Depois de se preparar e decidir tentar migrar seus dados para o Galera Cluster 4.0, certifique-se de sempre ter seu backup preparado. Se você tentou o ClusterControl, fazer backups será mais fácil de fazer isso.

Certifique-se de estar migrando para a versão correta do InnoDB e não se esqueça de sempre aplicar e executar mysql_upgrade antes de fazer o teste. Certifique-se de que todos os seus testes passem no resultado desejado a partir do qual a Replicação MySQL pode lhe oferecer. Provavelmente, não há diferença entre o mecanismo de armazenamento InnoDB que você está usando em um MySQL Replication Cluster versus o MySQL Galera Cluster, desde que as recomendações e dicas tenham sido aplicadas e preparadas com antecedência.

Conclusão