Streaming Replication é um novo recurso que foi introduzido com a versão 4.0 do Galera Cluster. O Galera usa a replicação de forma síncrona em todo o cluster, mas antes desta versão os conjuntos de gravação maiores que 2 GB não eram suportados. A replicação de streaming permite agora replicar grandes conjuntos de gravação, o que é perfeito para inserções em massa ou carregamento de dados em seu banco de dados.
Em um blog anterior, escrevemos sobre Manipulação de grandes transações com replicação de streaming e MariaDB 10.4, mas até o momento a Codership ainda não havia lançado sua versão do novo Galera Cluster. A Percona, no entanto, lançou sua versão binária experimental do Percona XtraDB Cluster 8.0, que destaca os seguintes recursos...
-
Replicação de streaming compatível com grandes transações
-
As funções de sincronização permitem a coordenação de ações (wsrep_last_seen_gtid, wsrep_last_written_gtid, wsrep_sync_wait_upto_gtid)
-
Registro de erros mais granular e aprimorado. wsrep_debug agora é uma variável de vários valores para auxiliar no controle do registro, e as mensagens de registro foram significativamente melhoradas.
-
Alguns erros DML e DDL em um nó de replicação podem ser ignorados ou suprimidos. Use a variável wsrep_ignore_apply_errors para configurar.
-
Várias tabelas de sistema ajudam a descobrir mais sobre o estado do cluster.
-
A infraestrutura wsrep do Galera 4 é mais robusta que a do Galera 3. Ela apresenta uma execução mais rápida de código com melhor manipulação de estado, previsibilidade aprimorada e manipulação de erros.
O que há de novo no Galera Cluster 4.0?
O novo recurso de replicação de streaming
Com a Replicação de Streaming, as transações são replicadas gradualmente em pequenos fragmentos durante o processamento da transação (ou seja, antes da confirmação real, replicamos vários fragmentos de tamanho pequeno). Os fragmentos replicados são então aplicados em threads escravos, preservando o estado da transação em todos os nós do cluster. Os fragmentos mantêm bloqueios em todos os nós e não podem entrar em conflito posteriormente.
Galera SystemTables
Administradores de banco de dados e clientes com acesso ao banco de dados MySQL podem ler essas tabelas, mas não podem modificá-las, pois o próprio banco de dados fará as modificações necessárias. Se seu servidor não possui essas tabelas, pode ser que seu servidor esteja usando uma versão mais antiga do Galera Cluster.
#> show tables from mysql like 'wsrep%';
+--------------------------+
| Tables_in_mysql (wsrep%) |
+--------------------------+
| wsrep_cluster |
| wsrep_cluster_members |
| wsrep_streaming_log |
+--------------------------+
3 rows in set (0.12 sec)Novas funções de sincronização
Esta versão apresenta uma série de funções SQL para uso em operações de sincronização wsrep. Você pode usá-los para obter o ID de transação global que é baseado na última gravação ou na última transação vista. Você também pode configurar o nó para aguardar a replicação e aplicação de um GTID específico antes de iniciar a próxima transação.
Seleção inteligente de doadores
Alguns recursos discretos que estão presentes desde o Galera 3.x incluem seleção inteligente de doadores e recuperação de falhas de cluster. Eles foram originalmente planejados para o Galera 4, mas foram lançados em versões anteriores em grande parte devido aos requisitos do cliente. Quando se trata de seleção de nó doador no Galera 3, o doador State Snapshot Transfer (SST) foi selecionado aleatoriamente. No entanto, com o Galera 4, você tem uma escolha muito mais inteligente na hora de escolher um doador, pois favorecerá um doador que possa fornecer uma Transferência Incremental de Estado (IST), ou escolher um doador no mesmo segmento. Como administrador de banco de dados, você pode forçar isso configurando wsrep_sst_donor.
Por que usar a replicação de streaming de cluster do MySQL Galera?
Transações de longa duração
Os problemas e limitações do Galera sempre giravam em torno de como ele lidava com transações de longa duração e, muitas vezes, fazia com que todo o cluster ficasse lento devido à replicação de grandes conjuntos de gravação. Seu controle de fluxo geralmente fica alto, fazendo com que as gravações diminuam ou até mesmo encerre o processo para reverter o cluster de volta ao seu estado normal. Este é um problema bastante comum nas versões anteriores do Galera Cluster.
Codership aconselha o uso de Streaming Replication para suas transações de longa duração para mitigar essas situações. Depois que o nó replica e certifica um fragmento, não é mais possível que outras transações o abortem.
Grandes transações
Isso é muito útil ao carregar dados para seu relatório ou análise. Criar inserções em massa, exclusões, atualizações ou usar a instrução LOAD DATA para carregar uma grande quantidade de dados pode cair nesta categoria. Embora isso dependa de como você gerencia seus dados para recuperação ou armazenamento. Você deve levar em consideração que a Replicação de Streaming tem suas limitações, de modo que as chaves de certificação são geradas a partir de bloqueios de registros.
Sem Streaming Replication, a atualização de um grande número de registros resultaria em um conflito e toda a transação teria que ser revertida. Os escravos que também estão replicando grandes transações estão sujeitos ao controle de fluxo à medida que atingem o limite e começam a desacelerar todo o cluster para processar quaisquer gravações, pois tendem a relaxar o recebimento de transações de entrada da replicação síncrona. O Galera relaxará a replicação até que o conjunto de gravação seja gerenciável, pois permite continuar a replicação novamente. Confira este blog externo da Percona para ajudá-lo a entender mais sobre o controle de fluxo no Galera.
Com Streaming Replication, o nó começa a replicar os dados com cada fragmento de transação, em vez de aguardar a confirmação. Isso significa que não há como abortar transações conflitantes em execução nos outros nós, pois isso simplesmente afirma que o cluster certificou o conjunto de gravação para esse fragmento específico. É gratuito aplicar e confirmar outras transações simultâneas sem bloquear e processar grandes transações com um impacto mínimo no cluster.
Hot Records/Hot Spots
Registros ou linhas quentes são aquelas linhas em sua tabela que são constantemente atualizadas. Esses dados podem ser os mais visitados e obter o tráfego de todo o seu banco de dados (por exemplo, feeds de notícias, um contador como número de visitas ou logs). Com a replicação de streaming, você pode forçar atualizações críticas para todo o cluster.
Conforme observado pela Equipe Galera na Codership
“Executar uma transação dessa maneira bloqueia efetivamente o registro ativo em todos os nós, impedindo que outras transações modifiquem a linha. Também aumenta as chances de que a transação seja confirmada com sucesso e que o cliente, por sua vez, receba o resultado desejado.”
Isso vem com limitações, pois pode não ser persistente e consistente que você tenha commits bem-sucedidos. Sem usar a Replicação de Streaming, você terá grandes chances ou reversões e isso pode adicionar sobrecarga ao usuário final ao enfrentar esse problema na perspectiva do aplicativo.
Aspectos a serem considerados ao usar a replicação de streaming
- As chaves de certificação são geradas a partir de bloqueios de registro, portanto, não cobrem bloqueios de intervalo ou bloqueios de próxima chave. Se a transação tiver um gap lock, é possível que uma transação, executada em outro nó, aplique um conjunto de gravação que encontre o log de gap e aborte a transação de streaming.
- Ao habilitar a Replicação de Streaming, os logs de conjunto de gravação são gravados na tabela wsrep_streaming_log encontrada no banco de dados do sistema mysql para preservar a persistência em caso de falha, portanto, essa tabela serve na recuperação. Em caso de log excessivo e sobrecarga de replicação elevada, a replicação de streaming causará uma taxa de transferência de transação degradada. Isso pode ser um gargalo de desempenho quando a alta carga de pico é atingida. Dessa forma, é recomendável ativar a replicação de streaming apenas no nível da sessão e apenas para transações que não seriam executadas corretamente sem ela.
- O melhor caso de uso é usar a replicação de streaming para cortar grandes transações
- Defina o tamanho do fragmento para ~10 mil linhas
- As variáveis de fragmento são variáveis de sessão e podem ser definidas dinamicamente
- O aplicativo inteligente pode ativar/desativar a replicação de streaming conforme a necessidade
Conclusão
Obrigado pela leitura, na segunda parte discutiremos como habilitar a Galera Cluster Streaming Replication e como podem ser os resultados para sua configuração.
