Em um dos blogs anteriores, abordamos novos recursos que estão sendo lançados no MariaDB 10.4. Mencionamos lá que incluído nesta versão será um novo lançamento do Galera Cluster. Nesta postagem do blog, examinaremos os recursos do Galera Cluster 26.4.0 (ou Galera 4), daremos uma olhada rápida neles e exploraremos como eles afetarão sua configuração ao trabalhar com o MariaDB Galera Cluster.
Replicação de streaming
O Galera Cluster não é de forma alguma um substituto imediato para o MySQL autônomo. A forma como a certificação do conjunto de escrita funciona introduziu várias limitações e casos extremos que podem limitar seriamente a capacidade de migrar para o Galera Cluster. As três limitações mais comuns são...
- Problemas com transações longas
- Problemas com grandes transações
- Problemas com pontos de acesso em tabelas
O que é ótimo de ver é que o Galera 4 apresenta o Streaming Replication, que pode ajudar a reduzir essas limitações. Vamos revisar o estado atual com um pouco mais de detalhes.
Transações de longa duração
Neste caso estamos falando em termos de tempo, que são definitivamente problemáticos em Galera. A principal coisa a entender é que o Galera replica as transações como writesets. Esses conjuntos de gravação são certificados nos membros do cluster, garantindo que todos os nós possam aplicar determinado conjunto de gravação. O problema é que os bloqueios são criados no nó local, eles não são replicados no cluster, portanto, se sua transação demorar vários minutos para ser concluída e se você estiver gravando em mais de um nó Galera, com o tempo é cada vez mais provável que no um dos nós restantes algumas transações modificarão algumas das linhas atualizadas em sua transação de longa duração. Isso fará com que a certificação falhe e a transação de longa duração terá que ser revertida. Em resumo, se você enviar gravações para mais de um nó no cluster, quanto maior a transação, maior a probabilidade de falha na certificação devido a algum conflito.
Pontos de acesso
Com isso, queremos dizer linhas, que são atualizadas com frequência. Normalmente, é algum tipo de contador que está sendo atualizado repetidamente. O culpado do problema é o mesmo que em transações longas - as linhas são bloqueadas apenas localmente. Novamente, se você enviar gravações para mais de um nó, é provável que o mesmo contador seja modificado ao mesmo tempo em mais de um nó, causando conflitos e fazendo com que a certificação falhe.
Para ambos os problemas, há uma solução - você pode enviar suas gravações para apenas um nó em vez de distribuí-las por todo o cluster. Você pode usar proxies para isso - ClusterControl implementa HAProxy e ProxySQL, ambos podem ser configurados para que as gravações sejam enviadas para apenas um nó. Se você não puder enviar gravações para apenas um nó, terá que aceitar que verá conflitos de certificação e reversões de tempos em tempos. Em geral, o aplicativo deve ser capaz de lidar com rollbacks do banco de dados - não há como contornar isso, mas é ainda mais importante quando o aplicativo trabalha com o Galera Cluster.
Ainda assim, enviar o tráfego para um nó não é suficiente para lidar com o terceiro problema.
Grandes transações
O que é importante ter em mente é que o writeset é enviado para certificação somente quando a transação é concluída. Em seguida, o writeset é enviado para todos os nós e ocorre o processo de certificação. Isso induz limites no tamanho da transação única, pois o Galera, ao preparar o writeset, o armazena no buffer da memória. Transações muito grandes reduzirão o desempenho do cluster. Portanto, duas variáveis foram introduzidas:wsrep_max_ws_rows, que limita o número de linhas por transação (embora possa ser definido como 0 - ilimitado) e, mais importante:wsrep_max_ws_size, que pode ser configurado em até 2 GB. Portanto, a maior transação que você pode executar com o Galera Cluster é de até 2 GB. Além disso, você deve ter em mente que a certificação e a aplicação da transação grande também levam tempo, criando “lag” - leitura após gravação, aquele nó de acesso diferente de onde você inicialmente confirmou a transação, provavelmente resultará em dados incorretos como o transação ainda está sendo aplicada.
O Galera 4 vem com Streaming Replication, que pode ser usado para mitigar todos esses problemas. A principal diferença será que o writeset agora pode ser dividido em partes - não será mais necessário esperar que toda a transação termine antes que os dados sejam replicados. Isso pode fazer você se perguntar - como é a certificação nesse caso? Resumindo, a certificação é imediata - cada fragmento é certificado e todas as linhas envolvidas são bloqueadas em todos os nós do cluster. Esta é uma mudança séria na forma como o Galera funciona - até agora os bloqueios eram criados localmente, com os bloqueios de replicação de streaming sendo criados em todos os nós. Isso ajuda nos casos que discutimos acima - bloquear linhas à medida que os fragmentos da transação chegam, ajuda a reduzir a probabilidade de que a transação precise ser revertida. As transações conflitantes executadas localmente não conseguirão obter os bloqueios de que precisam e terão que aguardar a conclusão da transação de replicação e liberar os bloqueios de linha.
No caso de hotspots, com a replicação de streaming é possível obter os bloqueios em todos os nós ao atualizar a linha. Outras consultas que desejam atualizar a mesma linha terão que aguardar a liberação do bloqueio antes de executar suas alterações.
Grandes transações se beneficiarão da replicação de streaming porque não será mais necessário esperar a conclusão de toda a transação nem serão limitadas pelo tamanho da transação - transações grandes serão divididas em fragmentos. Também ajuda a utilizar melhor a rede - em vez de enviar 2 GB de dados de uma só vez, os mesmos 2 GB de dados podem ser divididos em fragmentos e enviados por um longo período de tempo.
Existem duas opções de configuração para a replicação de streaming:wsrep_trx_fragment_size, que informa o tamanho que um fragmento deve ter (por padrão, é definido como 0, o que significa que a replicação de streaming está desabilitada) e wsrep_trx_fragment_unit, que informa o que o fragmento realmente é. Por padrão, são bytes, mas também podem ser 'instruções' ou 'linhas'. Essas variáveis podem (e devem) ser definidas em nível de sessão, possibilitando ao usuário decidir qual consulta específica deve ser replicada usando a replicação de streaming. Definir unit para ‘statements’ e size para 1 permite, por exemplo, usar a replicação de streaming apenas para uma única consulta que, por exemplo, atualiza um hotspot.
Obviamente, há desvantagens na execução da replicação de streaming, principalmente devido ao fato de que os bloqueios agora são feitos em todos os nós do cluster. Se você viu transações grandes sendo revertidas por muito tempo, agora essa transação terá que ser revertida em todos os nós. Obviamente, a melhor prática é reduzir o tamanho de uma transação o máximo possível para evitar que as reversões levem horas para serem concluídas. Outra desvantagem é que, por motivos de recuperação de falha, os conjuntos de gravação criados a partir de cada fragmento são armazenados na tabela wsrep_schema.SR em todos os nós, o que, de certa forma, implementa buffer de gravação dupla, aumentando a carga no cluster. Portanto, você deve decidir cuidadosamente qual transação deve ser replicada usando a replicação de streaming e, desde que seja viável, ainda deve seguir as práticas recomendadas de ter transações pequenas e curtas ou dividir a transação grande em lotes menores.
Bloqueios de backup
Por fim, os usuários do MariaDB poderão se beneficiar dos bloqueios de backup para SST. A ideia por trás do SST executado usando (para MariaDB) mariabackup é que todo o conjunto de dados deve ser transferido, em tempo real, com redo logs sendo coletados em segundo plano. Então, um bloqueio global deve ser adquirido, garantindo que nenhuma gravação aconteça, a posição final do redo log deve ser coletada e armazenada. Historicamente, para o MariaDB, a parte de travamento era realizada usando FLUSH TABLES WITH READ LOCK, que fazia seu trabalho, mas sob carga pesada era bastante difícil de adquirir. Também é bastante pesado - não apenas as transações precisam esperar que o bloqueio seja liberado, mas também os dados precisam ser liberados para o disco. Agora, com o MariaDB 10.4, será possível usar BACKUP LOCK menos intrusivo, que não exigirá que os dados sejam liberados, apenas os commits serão bloqueados durante o bloqueio. Isso deve significar operações SST menos intrusivas, o que é definitivamente ótimo de ouvir. Todos que tiveram que executar seu Galera Cluster no modo de emergência, em um nó, mantendo os dedos cruzados para que o SST não afete as operações do cluster, devem ficar mais do que felizes em ouvir sobre essa melhoria.
Leituras Causais do Aplicativo
O Galera 4 introduziu três novas funções que visam ajudar a adicionar suporte para leituras causais nas aplicações - WSREP_LAST_WRITTEN_GTID(), que retorna o GTID da última gravação feita pelo cliente, WSREP_LAST_SEEN_GTID(), que retorna o GTID da última transação de gravação observada pelo cliente e WSREP_SYNC_WAIT_UPTO_GTID(), que bloqueará o cliente até que o GTID passado para a função seja confirmado no nó. Claro, você pode impor leituras causais no Galera mesmo agora, mas utilizando essas funções será possível implementar leitura após gravação segura nas partes do aplicativo onde é necessário, sem a necessidade de fazer alterações na configuração do Galera.
Atualizando para o MariaDB Galera 10.4
Se você quiser experimentar o Galera 4, ele está disponível na versão mais recente do MariaDB 10.4. De acordo com a documentação do MariaDB, neste momento não há como fazer uma atualização ao vivo do Galera 10.3 para 10.4. Você precisa parar todo o cluster 10.3, atualizá-lo para 10.4 e reiniciá-lo. Este é um bloqueador sério e esperamos que essa limitação seja removida em uma das próximas versões. É de extrema importância ter a opção de uma atualização ao vivo e para isso o MariaDB 10.3 e o MariaDB 10.4 terão que coexistir no mesmo Galera Cluster. Outra opção, que também pode ser adequada, é configurar a replicação assíncrona entre o Galera Cluster antigo e o novo.
Nós realmente esperamos que você tenha gostado desta breve revisão dos recursos do MariaDB 10.4 Galera Cluster, estamos ansiosos para ver a replicação de streaming em ambientes de produção ao vivo reais. Também esperamos que essas mudanças ajudem a aumentar ainda mais a adoção do Galera. Afinal, a replicação de streaming resolve muitos problemas que podem impedir que as pessoas migrem para o Galera.
