Compartilhamento de tecnologia

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Ecossistema de código aberto

Como todos sabemos, os bancos de dados primários e secundários MySQL (dois nós) geralmente alcançam alta disponibilidade de dados por meio de replicação assíncrona e replicação semissíncrona (Semi-Sync). No entanto, em cenários anormais, como falhas de rede em salas de computadores e interrupções de host, o. arquiteturas primárias e secundárias encontrarão sérios problemas após a troca de HA. Haverá uma probabilidade de inconsistência de dados (referida como RPO!=0).Portanto, se os dados de negócios forem de certa importância, você não deve escolher um produto de banco de dados com arquitetura primária e secundária MySQL (dois nós. Recomenda-se escolher uma arquitetura multicópia com RPO = 0).

Comunidade MySQL, em relação à evolução da tecnologia multicópia com RPO=0:

• MySQL é oficialmente de código aberto e lançou a solução de alta disponibilidade MySQL Group Replication (MGR) baseada na replicação de grupo. O protocolo Paxos é encapsulado internamente por meio de XCOM para garantir a consistência dos dados.
• Ali Nuvem PolarDB-X , derivado do polimento de negócios e verificação do e-commerce Double Eleven do Alibaba e multiatividade em diferentes lugares, será de código aberto em todo o núcleo em outubro de 2021, abraçando totalmente o ecossistema de código aberto MySQL. PolarDB-X está posicionado como um banco de dados integrado centralizado e distribuído. Seu nó de dados Data Node (DN) adota o protocolo X-Paxos autodesenvolvido e é altamente compatível com MySQL 5.7/8.0. Ele não fornece apenas recursos de alta disponibilidade de nível financeiro. , mas também possui as características de mecanismo de transação altamente escalonável, operação flexível e manutenção, recuperação de desastres e armazenamento de dados de baixo custo. Referência: ".PolarDB-X Open Source | Três cópias do MySQL baseadas em Paxos》。

PolarDB-X O conceito de integração centralizada e distribuída: o DN do nó de dados pode ser usado de forma independente como um formulário centralizado (versão padrão), que é totalmente compatível com o formulário de banco de dados independente. Quando o negócio cresce até o ponto em que a expansão distribuída é necessária, a arquitetura é atualizada para um formato distribuído e os componentes distribuídos são perfeitamente conectados aos nós de dados originais. Não há necessidade de migração ou modificação de dados no lado do aplicativo. , e você pode aproveitar a distribuição da usabilidade e escalabilidade trazidas por esta fórmula, descrição da arquitetura:"Integração Distribuída Centralizada"

O MGR do MySQL e a versão padrão DN do PolarDB-X usam o protocolo Paxos do princípio mais baixo. Então, quais são os desempenhos específicos e as diferenças no uso real? Este artigo discorre sobre os aspectos de comparação de arquitetura, principais diferenças e comparação de testes.

Descrição da abreviatura MGR/DN: MGR representa a forma técnica do MySQL MGR e DN representa a forma técnica do PolarDB-X único DN centralizado (versão padrão).

Resumo

A análise comparativa detalhada é relativamente longa, então você pode ler primeiro o resumo e a conclusão. Se estiver interessado, você pode acompanhar o resumo e procurar pistas nos artigos subsequentes.

O MySQL MGR não é recomendado para negócios e empresas em geral porque requer conhecimento técnico profissional e uma equipe de operação e manutenção para utilizá-lo bem. Este artigo também reproduz três "armadilhas ocultas" do MySQL MGR que circulam na indústria há muito tempo. :

• Dark Pit 1: Os protocolos MySQL MGR e XCOM adotam o modo de memória total. O padrão é não atender à garantia de consistência de dados de RPO = 0 (haverá um problema de falta de dados no caso de teste posteriormente neste artigo). exibir e configurar um parâmetro para garantir isso Atualmente O design do MGR não pode atingir desempenho e RPO.
• Armadilha 2: O desempenho do MySQL MGR é ruim quando há atraso na rede. O artigo testou uma comparação de cenários de rede de 4 minutos (incluindo três salas de computadores na mesma cidade e três centros em dois locais). parâmetros de desempenho da cidade, é apenas 1/5 disso na mesma cidade, se a garantia de dados de RPO=0 estiver ativada, o desempenho será ainda pior.Portanto, o MySQL MGR é mais adequado para uso no mesmo cenário de sala de computadores, mas não é adequado para recuperação de desastres entre salas de computadores.
• Armadilha 3: Na arquitetura multicópia do MySQL MGR, a falha do nó de espera fará com que o tráfego do nó mestre Líder caia para 0, o que não é consistente com o bom senso. O artigo se concentra em tentar habilitar o modo líder único do MGR (em comparação com a arquitetura de réplica mestre-escravo anterior do MySQL), simulando as duas ações de tempo de inatividade e recuperação da réplica escrava. As operações de operação e manutenção do nó escravo também causarão o mestre. nó (Líder) aparecesse O tráfego caiu para 0 (durando cerca de 10 segundos) e a operabilidade e capacidade de manutenção gerais eram relativamente ruins.Portanto, o MySQL MGR tem requisitos relativamente altos na operação e manutenção do host e requer uma equipe profissional de DBA.

Comparado ao MySQL MGR, o PolarDB-X Paxos não apresenta armadilhas semelhantes ao MGR em termos de consistência de dados, recuperação de desastres entre salas de computadores e operação e manutenção de nós. No entanto, também apresenta algumas pequenas deficiências e vantagens na recuperação de desastres:

• Em um cenário simples da mesma sala de computadores, o desempenho somente leitura sob baixa simultaneidade e o desempenho de gravação pura sob alta simultaneidade são ligeiramente inferiores ao MySQL MGR em cerca de 5%. há espaço para maior otimização no desempenho.
• Vantagens: 100% compatível com os recursos do MySQL 5.7/8.0 Ao mesmo tempo, otimizações mais simplificadas foram feitas na replicação do banco de dados em espera de múltiplas cópias e nos caminhos de failover de comutação de alta disponibilidade <= 8 segundos, um comum 4. cenário de recuperação de desastres de um minuto na indústria Todos têm bom desempenho e podem substituir semi-sincronização (semi-sincronização), MGR, etc.

1. Comparação de arquitetura

Glossário

Descrição da abreviatura MGR/DN:

1. MGR: A forma técnica do MySQL MGR, a abreviatura do conteúdo subsequente: MGR
2. DN: Alibaba Cloud PolarDB-X é um formulário técnico centralizado (versão padrão). O DN do nó de dados distribuído pode ser usado de forma independente como um formulário centralizado (versão padrão). como: DN

MGR

MGR suporta modos single-master e multi-master e reutiliza totalmente o sistema de replicação do MySQL, incluindo Event, Binlog & Relaylog, Apply, Binlog Apply Recovery e GTID. A principal diferença do DN é que o ponto de entrada para a maioria do log de transações do MGR chegar a um consenso é antes que a transação do banco de dados principal seja confirmada.

• Líder:

1. 1. Antes de a transação ser confirmada, a função de gancho before_commit group_replication_trans_before_commit é chamada para inserir a replicação majoritária do MGR.
   2. MGR usa o protocolo Paxos para sincronizar os eventos Binlog armazenados em cache no THD para todos os nós online
   3. Após receber a resposta da maioria, o MGR determina que a transação pode ser submetida
   4. THD entra no processo de envio do grupo de transações e começa a escrever a atualização do Binlog local Refazer resposta do cliente OK mensagem

• Seguidor:

1. 1. O Paxos Engine do MGR continua ouvindo mensagens de protocolo do Líder
   2. Após um processo completo de consenso de Paxos, é confirmado que este evento (lote) atingiu a maioria no cluster
   3. Grave o evento recebido no Relay Log, IO Thread Apply Relay Log
   4. O aplicativo Relay Log passa por um processo completo de envio de grupo e o banco de dados standby eventualmente gerará seu próprio arquivo binlog.

A razão pela qual o MGR adota o processo acima é porque o MGR está no modo multimestre por padrão e cada nó pode escrever. Portanto, o nó seguidor em um único Grupo Paxos precisa primeiro converter o log recebido em RelayLog e depois combiná-lo. com a transação de gravação recebida como líder a ser enviada, o arquivo Binlog é produzido para enviar a transação final no processo de envio de grupo de dois estágios.

DN

O DN reutiliza a estrutura de dados básica e o código de nível de função do MySQL, mas integra replicação de log, gerenciamento de log, reprodução de log e recuperação de falhas com o protocolo X-Paxos para formar seu próprio conjunto de replicação majoritária e mecanismo de máquina de status. A principal diferença do MGR é que o ponto de entrada para a maioria do log de transações do DN chegar a um consenso é durante o processo principal de envio de transações do banco de dados.

• Líder:

1. 1. Entre no processo de envio de grupo da transação. Na fase Flush do envio de grupo, os eventos em cada THD são gravados no arquivo Binlog e, em seguida, o log é transmitido de forma assíncrona para todos os seguidores por meio do X-Paxos.
   2. Na fase de sincronização do envio do grupo, o Binlog é persistido primeiro e depois o local de persistência do X-Paxos é atualizado.
   3. Na fase Commit do envio do grupo, você deve primeiro esperar que o X-Paxos receba a resposta majoritária, depois enviar o grupo de transações e, por fim, responder com uma mensagem OK do cliente.

• Seguidor:

1. 1. X-Paxos continua ouvindo mensagens de protocolo do Líder
   2. Receba eventos (de grupo), escreva no Binlog local e responda
   3. A próxima mensagem é recebida, que traz o índice Commit da posição onde a maioria foi alcançada.
   4. O thread SQL Apply continua a aplicar o log Binlog recebido em segundo plano e, no máximo, aplica-o apenas à posição majoritária.

A razão para esse design é que o DN atualmente suporta apenas o modo mestre único, portanto, o log no nível do protocolo X-Paxos é o próprio Binlog que também omite o Relay Log e o conteúdo dos dados de seu log persistente e do log do líder. são iguais ao mesmo preço.

2. Principais diferenças

2.1. Eficiência do protocolo Paxos

MGR

• O protocolo Paxos do MGR é implementado com base no protocolo Mencius, que pertence à teoria Multi-Paxos. A diferença é que Mencius fez melhorias de otimização na redução da carga do nó mestre e no aumento do rendimento.
• O protocolo Paxos do MGR é implementado por componentes XCOM e suporta implantação em modo multimestre e mestre único. No modo mestre único, o Binlog no Líder transmite atomicamente para o nó Seguidor. A transmissão de cada lote de mensagens (uma transação). um processo Multi-Paxos padrão.
• Para satisfazer a maior parte de uma transação, o XCOM precisa passar por pelo menos três interações de mensagens de Accept+AckAccept+Learn, ou seja,Pelo menos 1,5 RTT de sobrecarga.Requer no máximo três interações de mensagens: Prepare+AckPrepare+Accept+AckAccept+Learn.Ou seja, um máximo de 2,5 RTT de sobrecarga no total
• Como o protocolo Paxos é concluído com alta coesão no módulo XCOM e não tem conhecimento do sistema de replicação MySQL, o Líder deve aguardar a conclusão do processo Paxos completo antes de confirmar a transação localmente, incluindo persistência Binlog e envio de grupo.
• Depois que o Seguidor concluir o envio majoritário, ele persistirá de forma assíncrona os Eventos no Relay Log e, em seguida, o aplicativo e o grupo SQL Thread enviarão o Binlog de produção.
• Como o log sincronizado pelo Paxos é um Binlog que não é classificado antes de entrar no processo de envio do grupo, a ordem dos Eventos Binlog no Líder pode não ser a mesma que a ordem dos Eventos no Relay Log no nó Seguidor.

DN

• O protocolo Paxos da DN é implementado com base no protocolo Raft e também pertence à teoria Multi-Paoxs. A diferença é que o protocolo Raft tem garantia de liderança e estabilidade de engenharia mais fortes.
• O protocolo Paxos do DN é completado pelo componente X-Paoxs. O padrão é o modo mestre único. No modo mestre único, o Binlog no Líder transmite atomicamente para o nó Seguidor. .
• Para satisfazer a maior parte de uma transação, o X-Paoxs só precisa passar pelas duas interações de mensagens Append+AckAppend, e apenas1 sobrecarga de RTT
• Após o Líder enviar o log ao Seguidor, desde que a maioria esteja satisfeita, ele confirma a transação sem esperar pela transmissão do Commit Index na segunda etapa.
• Antes que o Seguidor possa concluir o envio da maioria, todos os logs de transações devem ser persistidos. Isso é significativamente diferente do MGR do MGR, que só precisa recebê-lo na memória XCOM.
• O Índice de Commit é trazido em mensagens subsequentes e mensagens de pulsação, e o Seguidor executa o Evento Apply depois que o CommitIndex é enviado.
• O conteúdo do Binlog do Líder e do Seguidor está na mesma ordem, os logs do Raft não têm falhas e o mecanismo Batching/Pipeline é usado para aumentar o rendimento da replicação do log.
• Comparado com o MGR, o Líder sempre tem apenas um atraso de ida e volta quando uma transação é confirmada., muito crítico para aplicações distribuídas sensíveis a atrasos

2.2. RPO

Teoricamente, tanto Paxos quanto Raft podem garantir a consistência dos dados e os logs que atingiram a maioria após o Crash Recovery não serão perdidos, mas ainda existem diferenças em projetos específicos.

MGR

O XCOM encapsula completamente o protocolo Paxos e todos os seus dados de protocolo são armazenados em cache primeiro na memória. Por padrão, a maioria das transações não requer persistência de log. No caso em que a maioria das tortas cair e o Líder falhar, haverá um sério problema de RPO! = 0.Suponha um cenário extremo:

1. O cluster MGR consiste em três nós ABC, dos quais AB é uma sala de computadores independente na mesma cidade e C é um nó entre cidades. A é líder, BC é nó seguidor
2. Inicia a transação 001 no nó Líder A O Líder A transmite o log da transação 001 para o nó BC. Se a maioria for satisfeita através do protocolo Paxos, a transação pode ser considerada enviada. A seção AB formou a maioria e o nó C não recebeu o log da transação 001 devido ao atraso na rede entre cidades.
3. No momento seguinte, o Líder A envia a transação 001 e retorna o sucesso do Cliente, o que significa que a transação 001 foi enviada ao banco de dados.
4. Neste momento, no Seguidor do nó B, o log da transação 001 ainda está no cache do XCOM e não teve tempo de ser liberado para o RelayLog, neste momento, o Seguidor do nó C ainda não recebeu a transação 001; log do líder do nó A.
5. Neste momento, o nó AB está inativo, o nó A falha e não pode ser recuperado por um longo tempo, o nó B reinicia e se recupera rapidamente e os nós BC continuam a fornecer serviços de leitura e gravação.
6. Como o log da transação 001 não foi persistido no RelayLog do nó B durante o tempo de inatividade, nem foi recebido pelo nó C, neste momento, o nó BC realmente perdeu a transação 001 e não pode recuperá-la.
7. Neste cenário em que o partido majoritário está em baixa, RPO!=0

Sob os parâmetros padrão da comunidade, a maioria das transações não requer persistência de log e não garante RPO=0. Isto pode ser considerado uma compensação pelo desempenho na implementação do projeto XCOM. Para garantir RPO=0 absoluto, você precisa configurar o parâmetro group_replication_consistency que controla a consistência de leitura e gravação para AFTER. No entanto, neste caso, além da sobrecarga de rede RTT de 1,5, a transação exigirá uma sobrecarga de E/S de log para atingir a maioria. e o desempenho será muito ruim.

DN

PolarDB-X DN usa X-Paxos para implementar um protocolo distribuído e está profundamente vinculado ao processo de Group Commit do MySQL. Quando uma transação é enviada, a maioria é obrigada a confirmar o posicionamento e a persistência antes que o envio real seja permitido. A maior parte do posicionamento do disco aqui se refere ao posicionamento do Binlog da biblioteca principal. O thread IO da biblioteca standby recebe o log da biblioteca principal e o grava em seu próprio Binlog para persistência. Portanto, mesmo que todos os nós falhem em cenários extremos, os dados não serão perdidos e o RPO=0 poderá ser garantido.

2.3. RTO

O tempo RTO está intimamente relacionado ao tempo de sobrecarga de reinicialização a frio do próprio sistema, o que se reflete nas funções básicas específicas:Mecanismo de detecção de falhas-> mecanismo de recuperação de falhas-> mecanismo de seleção mestre-> balanceamento de log

2.3.1. Detecção de falhas

MGR

• Cada nó envia periodicamente pacotes de pulsação para outros nós para verificar se outros nós estão íntegros. O período de pulsação é fixado em 1s e não pode ser ajustado.
• Se o nó atual descobrir que outros nós não responderam após group_replication_member_expel_timeout (padrão 5s), ele será considerado um nó com falha e será expulso do cluster.
• Para exceções como interrupção da rede ou reinicialização anormal, após a restauração da rede, um único nó com falha tentará ingressar automaticamente no cluster e, em seguida, vinculará o log.

DN

• O nó Líder envia periodicamente pacotes de pulsação para outros nós para verificar se outros nós estão íntegros. O período de pulsação é 1/5 do tempo limite da eleição. O tempo limite de eleição é controlado pelo parâmetro consenso_election_timeout. O padrão é 5s, portanto o período de pulsação do nó líder é padronizado como 1s.
• Se o Líder descobrir que outros nós estão offline, ele continuará a enviar periodicamente pacotes de pulsação para todos os outros nós para garantir que outros nós possam acessar a tempo após travarem e se recuperarem.No entanto, o nó Líder não envia mais logs de transações para o nó offline.
• Os nós não líderes não enviam pacotes de detecção de pulsação, mas se o nó não líder descobrir que não recebeu a pulsação do nó líder após consenso_election_timeout, uma reeleição será acionada.
• Para exceções como interrupção da rede ou reinicialização anormal, após a restauração da rede, o nó com defeito ingressará automaticamente no cluster.
• Portanto, em termos de detecção de falhas, o DN fornece mais interfaces de configuração de operação e manutenção, e a identificação de falhas em cenários de implantação entre cidades será mais precisa.

2.3.2. Recuperação de falhas

MGR

• • O protocolo Paxos implementado pelo XCOM está no estado de memória. A obtenção da maioria não requer persistência. O status do protocolo é baseado no status da memória do nó majoritário sobrevivente.Se todos os nós travarem, o protocolo não poderá ser restaurado. Depois que o cluster for reiniciado, será necessária uma intervenção manual para restaurá-lo.
  • Se apenas um único nó travar e for recuperado, mas o nó Seguidor ficar atrás do nó Líder com mais logs de transações, e os logs de transações em cache do XCOM no Líder tiverem sido apagados, a única opção é usar o processo de Recuperação Global ou Clone.
  • O tamanho do cache XCOM é controlado por group_replication_message_cache_size, o padrão é 1GB
  • Recuperação Global significa que quando um nó se ingressa novamente no cluster, ele recupera dados obtendo os logs de transações ausentes necessários (log binário) de outros nós.Este processo depende de pelo menos um nó no cluster que retém todos os logs de transações necessários
  • Clone depende do Clone Plugin, que é usado para recuperação quando a quantidade de dados é grande ou muitos logs estão faltando.Funciona copiando um instantâneo de todo o banco de dados para o nó travado, seguido por uma sincronização final com o log de transações mais recente
  • Os processos de Recuperação Global e Clone geralmente são automatizados, mas em alguns casos especiais, como problemas de rede ou o cache XCOM dos outros dois nós foi limpo, é necessária intervenção manual.

DN

• • O protocolo X-Paxos usa persistência Binlog. Ao se recuperar de uma falha, as transações enviadas serão totalmente restauradas primeiro. Para transações pendentes, você precisa esperar que a camada de protocolo XPaxos chegue a um acordo para determinar o relacionamento mestre-backup antes de confirmar ou reverter a transação. Todo o processo é totalmente automatizado.Mesmo que todos os nós estejam inativos, o cluster poderá se recuperar automaticamente após a reinicialização.
  • Para cenários em que o nó Seguidor fica atrás do nó Líder em muitos logs de transações, desde que o arquivo Binlog no Líder não seja excluído, o nó Seguidor definitivamente o alcançará.
  • Portanto, em termos de recuperação de falhas, o DN não requer nenhuma intervenção manual.

2.3.3. Escolha do líder

No modo single-master, o XCOM e o DN X-Paxos do MGR, um modo líder forte, seguem o mesmo princípio básico para selecionar o líder – os logs que foram acordados pelo cluster não podem ser revertidos. Mas quando se trata do registro de não consenso, existem diferenças

MGR

• A seleção do líder é mais sobre qual nó servirá como o próximo serviço do Líder.Este Líder não possui necessariamente o log de consenso mais recente quando é eleito, portanto, ele precisa sincronizar os logs mais recentes de outros nós do cluster e fornecer serviços de leitura e gravação após os logs serem vinculados.
• A vantagem disso é que a própria escolha do Líder é um produto estratégico, como peso e pedido. MGR controla o peso de cada nó por meio do parâmetro group_replication_member_weight
• A desvantagem é que o próprio Líder recém-eleito pode ter um grande atraso de replicação e precisar continuar a acompanhar o log, ou o atraso do aplicativo pode ser alto e precisar continuar a acompanhar o aplicativo de log antes que ele possa fornecer leitura e escrever serviços.Isso resulta em um tempo de RTO mais longo

DN

• A eleição do líder ocorre no sentido do protocolo. Qualquer nó que tenha os logs de todos os partidos majoritários no cluster pode ser eleito líder, portanto, esse nó pode ter sido um seguidor ou um registrador antes.
• O Logger não pode fornecer serviços de leitura e gravação. Depois de sincronizar os logs com outros nós, ele desistirá ativamente da função de Líder.
• Para garantir que o nó designado se torne o líder, o DN usa uma estratégia de peso otimista + uma estratégia de peso obrigatória para limitar a ordem de se tornar o líder e usa um mecanismo de maioria estratégica para garantir que o novo mestre possa fornecer imediatamente leitura e gravação serviços com atraso zero.
• Portanto, em termos de seleção de líderes, o DN não só apoia a mesma seleção estratégica que o MGR, mas também apoia estratégias de peso obrigatórias.

2.3.4. Correspondência de registros.

A equalização de log significa que há um atraso na replicação de log nos logs entre os bancos de dados primário e secundário, e o banco de dados secundário precisa equalizar os logs. Para nós que são reiniciados e restaurados, a recuperação geralmente é iniciada com o banco de dados de espera, e um atraso na replicação de log já ocorreu em comparação com o banco de dados principal, e os logs precisam ser atualizados com o banco de dados principal. Para aqueles nós que estão fisicamente distantes do Líder, atingir a maioria geralmente não tem nada a ver com eles. Eles sempre têm um atraso no log de replicação e estão constantemente atualizando o log. Essas situações exigem implementação de engenharia específica para garantir a resolução oportuna de atrasos na replicação de logs.

MGR

• Os logs de transações estão todos no cache XCOM, e o cache é de apenas 1G por padrão. Portanto, quando um nó seguidor que está muito atrasado na replicação de logs de solicitações, é fácil limpar o cache.
• Neste momento, o seguidor atrasado será automaticamente expulso do cluster e, em seguida, usará o processo de recuperação global ou clone mencionado acima para recuperação de falhas e, em seguida, ingressará automaticamente no cluster após a atualização.Se você encontrarPor exemplo, problemas de rede ou o cache XCOM dos outros dois nós é limpo, caso em que é necessária intervenção manual para resolver o problema.
• Por que devemos expulsar o cluster primeiro? Porque o nó defeituoso no modo multigravação afeta muito o desempenho e o cache do Líder não tem efeito sobre ele. Ele deve ser adicionado após a ligação assíncrona.
• Por que não podemos ler diretamente o arquivo Binlog local do Líder porque o protocolo XCOM mencionado anteriormente está com memória cheia e não há informações de protocolo sobre XCOM no Binlog e no Relay Log?

DN

• Os dados estão todos no arquivo Binlog. Desde que o Binlog não seja limpo, eles podem ser enviados sob demanda e não há possibilidade de serem expulsos do cluster.
• Para reduzir o jitter de IO causado pela leitura de logs de transações antigos da biblioteca principal do arquivo Binlog, o DN dá prioridade à leitura dos logs de transações armazenados em cache mais recentemente do cache FIFO. O cache FIFO é controlado pelo parâmetro consenso_log_cache_size e o padrão. é 64 milhões
• Se o log de transações antigo no cache FIFO tiver sido eliminado pelo log de transações atualizado, o DN tentará ler o log de transações armazenado anteriormente no cache de pré-busca. O cache de pré-busca é controlado pelo parâmetro consenso_prefetch_cache_size e o padrão é 64M.
• Se não houver nenhum log de transações antigo necessário no cache de pré-busca, o DN tentará iniciar uma tarefa de E/S assíncrona, lerá vários logs consecutivos antes e depois do log de transações especificado do arquivo Binlog em lotes, colocá-los no cache de pré-busca e aguardar para a próxima nova tentativa de leitura do DN.
• Portanto, o DN não requer nenhuma intervenção manual quando se trata de balancear logs.

2.4. Atraso na reprodução do banco de dados em espera

O atraso de reprodução do banco de dados standby é o atraso entre o momento em que a mesma transação é concluída no banco de dados principal e o momento em que a transação é aplicada no banco de dados standby. O que é testado aqui é o desempenho do log do aplicativo Apply do banco de dados standby. Afeta quanto tempo leva para o banco de dados standby concluir seu aplicativo de dados e fornecer serviços de leitura e gravação quando ocorre uma exceção.

MGR

• O banco de dados standby MGR recebe o arquivo RelayLog do banco de dados principal. Ao aplicar o aplicativo, ele precisa ler o RelayLog novamente, passar por um processo completo de envio de grupo em dois estágios e produzir os dados e arquivos Binlog correspondentes.
• A eficiência do aplicativo de transação aqui é a mesma que a eficiência de envio de transação no banco de dados principal. A configuração padrão duplo (innodb_flush_log_at_trx_commit, sync_binlog) fará com que a mesma sobrecarga de recursos do aplicativo de banco de dados em espera seja grande.

DN

• O banco de dados de backup DN recebe o arquivo Binlog do banco de dados principal. Ao aplicar, o Binlog precisa ser lido novamente. Basta passar pelo processo de envio do grupo de um estágio e produzir os dados correspondentes.
• Como o DN suporta Crash Recover completo, o aplicativo de banco de dados em espera não precisa ativar innodb_flush_log_at_trx_commit=1, portanto, não é realmente afetado pela configuração duplo-um.
• Portanto, em termos de atraso na reprodução do banco de dados em espera, a eficiência de reprodução do banco de dados em espera do DN será muito maior do que o MGR.

2.5. Impacto dos grandes eventos

Grandes transações não afetam apenas o envio de transações comuns, mas também afetam a estabilidade de todo o protocolo distribuído em um sistema distribuído. Em casos graves, uma grande transação fará com que todo o cluster fique indisponível por um longo período.

MGR

• O MGR não possui nenhuma otimização para suportar grandes transações. Apenas adiciona o parâmetro group_replication_transaction_size_limit para controlar o limite superior de grandes transações.
• Quando o log de transações exceder o limite de grandes transações, um erro será relatado diretamente e a transação não poderá ser enviada.

DN

• Para resolver o problema de instabilidade de sistemas distribuídos causado por grandes transações, o DN adota a solução de divisão de transações grandes + divisão de objetos grandes para resolver o problema. O log de transações de grandes transações será dividido logicamente + fisicamente. pequenos blocos, cada pequeno bloco do log de transações usa a garantia completa de commit do Paxos
• Com base na solução de divisão de grandes transações, o DN não impõe nenhuma restrição ao tamanho das grandes transações. Os usuários podem utilizá-las à vontade e também podem garantir RPO = 0.
• Para obter instruções detalhadas, consulte"Tecnologia central do mecanismo de armazenamento PolarDB-X | Otimização de grandes transações"
• Portanto, o DN pode lidar com assuntos de grande escala sem ser afetado por assuntos de grande escala.

2.6. Formulário de implantação

MGR

• MGR suporta modos de implantação único mestre e multimestre. No modo multimestre, cada nó pode ser lido e gravado. No modo mestre único, o banco de dados principal pode ser lido e gravado, e o banco de dados de espera só pode ser lido. apenas.
• A implantação de alta disponibilidade do MGR requer pelo menos três implantações de nós, ou seja, pelo menos três cópias de dados e logs. O modo Logger de cópia não é suportado.
• O MGR não suporta a expansão de nós somente leitura, mas suporta a combinação do modo de replicação MGR + mestre-escravo para obter expansão de topologia semelhante.

DN

• O DN oferece suporte à implantação no modo mestre único. No modo mestre único, o banco de dados principal pode ser lido e gravado, e o banco de dados de espera só pode ser somente leitura.
• A implantação de alta disponibilidade do DN requer pelo menos três nós, mas suporta o formato Logger de cópia de log, ou seja, Líder e Seguidor são cópias completas. Em comparação com o Logger, ele possui apenas logs e nenhum dado, e não tem o direito de ser. eleito. Nesse caso, a implantação de alta disponibilidade de três nós requer apenas a sobrecarga de armazenamento de 2 cópias de dados + 3 cópias de logs, tornando-se uma implantação de baixo custo.
• O DN suporta implantação de nó somente leitura e cópia somente leitura do formulário do aluno. Em comparação com cópias completas, ele apenas não possui direitos de voto. A cópia do aluno permite assinatura downstream e consumo da biblioteca principal.

2.7. Resumo dos recursos

3. Comparação de testes

O MGR foi introduzido no MySQL 5.7.17, mas mais recursos relacionados ao MGR estão disponíveis apenas no MySQL 8.0, e no MySQL 8.0.22 e versões posteriores, o desempenho geral será mais estável e confiável. Portanto, selecionamos a versão mais recente 8.0.32 de ambas as partes para testes comparativos.

Considerando que existem diferenças nos ambientes de teste, métodos de compilação, métodos de implantação, parâmetros operacionais e métodos de teste durante o teste comparativo de PolarDB-X DN e MySQL MGR, o que pode levar a dados de comparação de teste imprecisos, este artigo se concentrará em vários detalhes . Proceda da seguinte forma:

Observação:

• O MGR tem o controle de fluxo habilitado por padrão, enquanto o PolarDB-X DN tem o controle de fluxo desligado por padrão.Portanto, o group_replication_flow_control_mode do MGR é configurado separadamente para que o desempenho do MGR seja o melhor.
• O MGR tem um gargalo de leitura óbvio durante a enumeração, portanto, o replication_optimize_for_static_plugin_config do MGR é configurado e habilitado separadamente, para que o desempenho somente leitura do MGR seja o melhor.

3.1.

O teste de desempenho é a primeira coisa que todos prestam atenção ao selecionar um banco de dados. Aqui usamos a ferramenta oficial sysbench para construir 16 tabelas, cada uma com 10 milhões de dados, para realizar testes de desempenho em cenários OLTP e testar e comparar o desempenho dos dois sob diferentes condições de simultaneidade em diferentes cenários OLTP.Considerando as diferentes situações de implantação real, simulamos os quatro cenários de implantação a seguir, respectivamente:

1. Três nós são implantados na mesma sala de computadores. Há um atraso de rede de 0,1 ms quando as máquinas executam ping entre si.
2. Três centros na mesma cidade e três salas de computadores na mesma região implantam três nós. Há um atraso de rede de 1 ms no ping entre as salas de computadores (por exemplo: três salas de computadores em Xangai).
3. Três centros em dois locais, três nós implantados em três salas de computadores em dois locais, ping de rede de 1 ms entre salas de computadores na mesma cidade, atraso de rede de 30 ms entre a mesma cidade e outro local (por exemplo: Xangai/Xangai/Shenzhen)
4. Três centros em três locais, três nós implantados em três salas de computadores em três locais (por exemplo: Xangai/Hangzhou/Shenzhen), o atraso da rede entre Hangzhou e Xangai é de cerca de 5 ms e a distância mais distante de Hangzhou/Xangai a Shenzhen é de 30 ms .

ilustrar:

a. Considere a comparação horizontal do desempenho de quatro cenários de implantação. Três centros em dois locais e três centros em três locais adotam o modo de implantação de 3 cópias.

b. Considerando as restrições estritas de RPO=0 ao usar produtos de banco de dados de alta disponibilidade, o MGR é configurado com RPO<>0 por padrão. Aqui continuaremos a adicionar testes comparativos entre MGR RPO<>0 e RPO=0 em cada um. cenário de implantação.

• MGR_0 representa dados para o caso de MGR RPO = 0
• MGR_1 representa dados para o caso de MGR RPO <> 0
• DN representa os dados para o caso de DN RPO = 0

3.1.1. Mesma sala de informática

Isso pode ser visto nos resultados do teste:

• No cenário somente leitura, seja comparando MGR_1 (RPO<>0) ou MGR_0 (RPO=0), a diferença entre DN e MGR é estável entre -5% e 10%, o que pode ser considerado basicamente o mesmo. O fato de RPO ser igual a 0 não afeta transações somente leitura
• No cenário misto de transação de leitura-gravação e somente gravação, o desempenho do DN (RPO=0) é melhorado em 5% a 47% em comparação com MGR_1 (RPO<>0), e a vantagem de desempenho do DN é óbvia quando o a simultaneidade é baixa e a vantagem quando a simultaneidade é alta Recursos não óbvios. Isso ocorre porque a eficiência do protocolo do DN é maior quando a simultaneidade é baixa, mas os pontos críticos de desempenho do DN e do MGR sob alta simultaneidade estão todos em limpeza.
• Sob a mesma premissa de RPO = 0, em cenários mistos de transação de leitura-gravação e somente gravação, o desempenho do DN é melhorado de 2 a 46 vezes em comparação com MGR_0 e, à medida que a simultaneidade aumenta, a vantagem de desempenho do DN é aprimorada. Não é de admirar que o MGR também abandone RPO=0 para desempenho por padrão.

3.1.2. Três centros na mesma cidade

Isso pode ser visto nos resultados do teste:

• No cenário somente leitura, seja comparando MGR_1 (RPO<>0) ou MGR_0 (RPO=0), a diferença entre DN e MGR é estável entre -7% e 5%, o que pode ser considerado basicamente o mesmo. O fato de RPO ser igual a 0 não afeta transações somente leitura
• Em um cenário misto de transação de leitura-gravação e somente gravação, o desempenho do DN (RPO=0) é melhorado em 30% a 120% em comparação com MGR_1 (RPO<>0), e a vantagem de desempenho do DN é óbvia quando a simultaneidade é baixo e quando a simultaneidade é alta, o desempenho é melhor. Recursos não óbvios. Isso ocorre porque a eficiência do protocolo do DN é maior quando a simultaneidade é baixa, mas os pontos críticos de desempenho do DN e do MGR sob alta simultaneidade estão todos em limpeza.
• Sob a mesma premissa de RPO = 0, em cenários mistos de transação de leitura-gravação e somente gravação, o desempenho do DN é melhorado de 1 a 14 vezes em comparação com MGR_0 e, à medida que a simultaneidade aumenta, a vantagem de desempenho do DN é aprimorada. Não é de admirar que o MGR também abandone RPO=0 para desempenho por padrão.

3.1.3. Dois lugares e três centros.

Isso pode ser visto nos resultados do teste:

• No cenário somente leitura, seja comparando MGR_1 (RPO<>0) ou MGR_0 (RPO=0), a diferença entre DN e MGR é estável entre -4% e 7%, o que pode ser considerado basicamente o mesmo. O fato de RPO ser igual a 0 não afeta transações somente leitura
• No cenário misto de transação de leitura-gravação e somente gravação, o desempenho do DN (RPO=0) é melhorado de 2 a 16 vezes em comparação com MGR_1 (RPO<>0), e a vantagem de desempenho do DN é óbvia quando a simultaneidade é baixo e a vantagem quando a simultaneidade é alta Recursos não óbvios. Isso ocorre porque a eficiência do protocolo do DN é maior quando a simultaneidade é baixa, mas os pontos críticos de desempenho do DN e do MGR sob alta simultaneidade estão todos em limpeza.
• Sob a mesma premissa de RPO = 0, em cenários mistos de transação de leitura-gravação e somente gravação, o desempenho do DN é melhorado de 8 a 29 vezes em comparação com MGR_0 e, à medida que a simultaneidade aumenta, a vantagem de desempenho do DN é aprimorada. Não é de admirar que o MGR também abandone RPO=0 para desempenho por padrão.

3.1.4. Três lugares e três centros

Isso pode ser visto nos resultados do teste:

• No cenário somente leitura, seja comparando MGR_1 (RPO<>0) ou MGR_0 (RPO=0), a diferença entre DN e MGR é estável entre -5% e 0%, o que pode ser considerado basicamente o mesmo. O fato de RPO ser igual a 0 não afeta transações somente leitura
• No cenário misto de transação de leitura-gravação e somente gravação, o desempenho do DN (RPO=0) é melhorado de 2 a 5 vezes em comparação com MGR_1 (RPO<>0), e a vantagem de desempenho do DN é óbvia quando a simultaneidade é baixo e a vantagem quando a simultaneidade é alta Recursos não óbvios. Isso ocorre porque a eficiência do protocolo do DN é maior quando a simultaneidade é baixa, mas os pontos críticos de desempenho do DN e do MGR sob alta simultaneidade estão todos em limpeza.
• Sob a mesma premissa de RPO = 0, em cenários mistos de transação de leitura-gravação e somente gravação, o desempenho do DN é melhorado de 2 a 17 vezes em comparação com MGR_0 e, à medida que a simultaneidade aumenta, a vantagem de desempenho do DN é aprimorada. Não é de admirar que o MGR também abandone RPO=0 para desempenho por padrão.

3.1.5. Comparação de implantação.

Para comparar claramente as mudanças de desempenho sob diferentes métodos de implantação, selecionamos os dados TPS de MGR e DN sob diferentes métodos de implantação sob a simultaneidade do cenário 256 oltp_write_only no teste acima. Usando os dados de teste da sala de computadores como linha de base, calculamos e. comparou os dados TPS de diferentes métodos de implantação em comparação com a linha de base para perceber a diferença nas mudanças de desempenho durante a implantação entre cidades.

Isso pode ser visto nos resultados do teste:

• Com a expansão do método de implantação, o TPS de MGR_1 (RPO<>0) caiu significativamente. Em comparação com a implantação na mesma sala de computadores, o desempenho da implantação entre salas de computadores na mesma cidade caiu 27,5%. de implantação entre cidades (três centros em dois locais, três centros em três locais) Uma diminuição de 77%~82%, que se deve ao aumento na implantação de RT entre cidades.
• DN (RTO=0) é relativamente estável Em comparação com a implantação na mesma sala de informática, o desempenho da implantação de salas de informática cruzadas na mesma cidade e a implantação de três centros em dois locais caiu de 4% a 12%. . O desempenho da implantação de três centros em três locais caiu 37% sob alta latência de rede. Isto também se deve ao aumento da implantação de RT nas cidades.No entanto, graças ao mecanismo Batch&Pipeline da DN, o impacto entre cidades pode ser resolvido aumentando a simultaneidade. Por exemplo, sob a arquitetura de três locais e três centros, sob >= 512 simultaneidade, o rendimento de desempenho na mesma cidade e em dois. lugares e três centros podem ser basicamente alinhados.
• Pode-se observar que a implantação entre cidades tem um grande impacto em MGR_1 (RPO<>0)

3.1.6 Tremulação de desempenho

No uso real, não prestamos atenção apenas aos dados de desempenho, mas também precisamos prestar atenção ao jitter de desempenho. Afinal, se o tremor for como uma montanha-russa, a experiência real do usuário será muito ruim. Monitoramos e exibimos dados de saída do TPS em tempo real. Considerando que a própria ferramenta sysbenc não suporta dados de monitoramento de saída de jitter de desempenho, usamos o coeficiente matemático de variação como indicador de comparação:

• Coeficiente de Variação (CV): O coeficiente de variação é o desvio padrão dividido pela média. É frequentemente usado para comparar as flutuações de diferentes conjuntos de dados, especialmente quando as diferenças médias são grandes. Quanto maior o CV, maior será a flutuação dos dados em relação à média.

Tomando como exemplo o cenário oltp_read_write simultâneo de 256, analisamos estatisticamente o TPS de MGR_1 (RPO<>0) e DN (RPO=0) na mesma sala de informática, três centros na mesma cidade, três centros em dois locais, e três centros em três lugares. O gráfico de jitter real é o seguinte, e os dados reais do indicador de jitter para cada cenário são os seguintes:

Isso pode ser visto nos resultados do teste:

• O TPS do MGR está em um estado instável no cenário oltp_read_write e cai repentinamente sem motivo. Esse fenômeno foi encontrado em vários testes em vários cenários de implantação. Em comparação, o DN é muito estável.
• Calculando o coeficiente de variação CV, o CV do MGR é muito grande, 6% a 10%, e chega até a atingir o valor máximo de 10% quando o atraso na mesma sala de informática é mínimo, enquanto o CV do DN é relativamente estável, 2% a 4 %, e o desempenho do DN é mais estável do que o do MGR. O sexo é basicamente duas vezes maior.
• Pode-se ver que o jitter de desempenho de MGR_1 (RPO<>0) é relativamente grande

3.2. RTO

O principal recurso de um banco de dados distribuído é a alta disponibilidade. A falha de qualquer nó no cluster não afetará a disponibilidade geral. Para a forma típica de implantação de 3 nós com um mestre e dois backups implantados na mesma sala de computadores, tentamos realizar testes de usabilidade nos três cenários a seguir:

• Interrompa o banco de dados principal, reinicie-o e observe o tempo de RTO para o cluster restaurar a disponibilidade durante o processo.
• Interrompa qualquer banco de dados em espera e reinicie-o para observar o desempenho de disponibilidade do banco de dados primário durante o processo.

3.2.1 Tempo de inatividade do banco de dados principal + reinicialização.

Quando não há carga, mate o líder e monitore as mudanças de status de cada nó no cluster e se ele é gravável.

Pode-se observar pelos resultados dos testes que, sob nenhuma condição de pressão:

• O RTO do DN é de 8 a 15s, leva 8s para reduzir para 2 nós e 15s para restaurar 3 nós;
• O RTO do MGR é de 23 a 37 segundos. São necessários 23 segundos para fazer o downgrade para 2 nós e 37 segundos para restaurar 3 nós.
• O desempenho do RTO DN é geralmente melhor que o MGR

3.2.2 Tempo de inatividade do banco de dados em espera + reinicialização.

Use o sysbench para conduzir um teste de estresse simultâneo de 16 threads no cenário oltp_read_write No décimo segundo na figura, elimine manualmente um nó em espera e observe os dados TPS de saída em tempo real do sysbench.

Isso pode ser visto no gráfico de resultados do teste:

• Depois que o banco de dados de espera foi interrompido, o TPS do banco de dados principal do MGR caiu significativamente e durou cerca de 20 segundos antes de retornar aos níveis normais. De acordo com a análise de log, existem dois processos aqui: detectar que o nó defeituoso se tornou inacessível e expulsar o nó defeituoso do cluster MGR. Este teste confirmou uma falha que circula na comunidade MGR há muito tempo. Mesmo que apenas 1 nó entre 3 nós esteja indisponível,Todo o cluster sofreu fortes instabilidades por um período e ficou indisponível.
• Para resolver o problema de MGR de mestre único ter uma falha de nó único e toda a instância estar indisponível, a comunidade introduziu a função de líder único MGR paxos em 8.0.27 para resolver o problema, mas ela está desativada por padrão. Aqui ativamos group_replication_paxos_single_leader e continuamos a verificar. Após interromper o banco de dados standby desta vez, o desempenho do banco de dados principal permanece estável e ligeiramente melhorado.
• Para DN, após a interrupção do banco de dados standby, o TPS do banco de dados principal aumentou imediatamente cerca de 20% e permaneceu estável, e o cluster estava sempre disponível.Isso é o oposto do MGR. O motivo é que, após interromper um banco de dados em espera, o banco de dados principal só precisa enviar logs para o banco de dados em espera restante a cada vez. O processo de envio e recebimento de pacotes de rede é mais eficiente.

Continuando o teste, reiniciamos e restauramos o banco de dados standby e observamos as alterações nos dados TPS do banco de dados principal.

Isso pode ser visto no gráfico de resultados do teste:

• O MGR recuperou de 2 nós para 3 nós em 5 segundos.Mas também existe uma situação em que a biblioteca principal fica indisponível, o que dura cerca de 12 segundos.Embora o nó de espera finalmente tenha ingressado no cluster, o status MEMBER_STATE sempre foi RECOVERING, indicando que os dados estão sendo perseguidos neste momento.
• No cenário após group_replication_paxos_single_leader ser ativado, a reinicialização do banco de dados em espera também é verificada. Como resultado, o MGR recupera de 2 nós para 3 nós em 10 segundos.Mas ainda houve um tempo indisponível com duração de cerca de 7 segundos.Parece que este parâmetro não pode resolver completamente o problema do MGR de mestre único ter uma falha de nó único e toda a instância ficar indisponível.
• Para DN, o banco de dados standby se recupera de 2 nós para 3 nós em 10 segundos e o banco de dados principal permanece disponível. Haverá flutuações de curto prazo no TPS aqui. Isso se deve ao atraso na replicação do log ao reiniciar o banco de dados de espera. Ele precisa extrair os logs atrasados ​​do banco de dados principal, portanto, terá um pequeno impacto no banco de dados principal. a revisão do log, o desempenho geral será estável.

3.3. RPO

Para construir o cenário RPO<>0 de falha majoritária do MGR, usamos o método MTR Case da própria comunidade para realizar testes de injeção de falhas no MGR.

--echo
--echo ############################################################
--echo # 1. Deploy a 3 members group in single primary mode.
--source include/have_debug.inc
--source include/have_group_replication_plugin.inc
--let $group_replication_group_name= aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
--let $rpl_group_replication_single_primary_mode=1
--let $rpl_skip_group_replication_start= 1
--let $rpl_server_count= 3
--source include/group_replication.inc
 
--let $rpl_connection_name= server1
--source include/rpl_connection.inc
--let $server1_uuid= `SELECT @@server_uuid`
--source include/start_and_bootstrap_group_replication.inc
 
--let $rpl_connection_name= server2
--source include/rpl_connection.inc
--source include/start_group_replication.inc
 
--let $rpl_connection_name= server3
--source include/rpl_connection.inc
--source include/start_group_replication.inc
 
--echo
--echo ############################################################
--echo # 2. Init data
--let $rpl_connection_name = server1
--source include/rpl_connection.inc
CREATE TABLE t1 (c1 INT PRIMARY KEY);
INSERT INTO t1 VALUES(1);
 
--source include/rpl_sync.inc
SELECT * FROM t1;
 
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
SELECT * FROM t1;
 
--let $rpl_connection_name = server3
--source include/rpl_connection.inc
SELECT * FROM t1;
 
--echo
--echo ############################################################
--echo # 3. Mock crash majority members
 
--echo # server 2 wait before write relay log
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
 
--echo # server 3 wait before write relay log
--let $rpl_connection_name = server3
--source include/rpl_connection.inc
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
 
 
--echo # server 1 commit new transaction
--let $rpl_connection_name = server1
--source include/rpl_connection.inc
INSERT INTO t1 VALUES(2);
# server 1 commit t1(c1=2) record
SELECT * FROM t1;
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 1 crash
--source include/kill_mysqld.inc
 
--echo # sleep enough time for electing new leader
sleep 60;
 
--echo 
--echo # server 3 check
--let $rpl_connection_name = server3
--source include/rpl_connection.inc
SELECT * FROM t1;
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 3 crash and restart
--source include/kill_and_restart_mysqld.inc
 
--echo # sleep enough time for electing new leader
sleep 60;
 
--echo 
--echo # server 2 check
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
SELECT * FROM t1;
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 2 crash and restart
--source include/kill_and_restart_mysqld.inc
 
--echo # sleep enough time for electing new leader
sleep 60;
 
--echo
--echo ############################################################
--echo # 4. Check alive members, lost t1(c1=2) record
 
--echo # server 3 check
--let $rpl_connection_name= server3
--source include/rpl_connection.inc
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 3 lost t1(c1=2) record
SELECT * FROM t1;
 
--echo 
--echo # server 2 check
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 2 lost t1(c1=2) record
SELECT * FROM t1;

!include ../my.cnf
 
[mysqld.1]
loose-group_replication_member_weight=100
 
[mysqld.2]
loose-group_replication_member_weight=90
 
[mysqld.3]
loose-group_replication_member_weight=80
 
[ENV]
SERVER_MYPORT_3=		@mysqld.3.port
SERVER_MYSOCK_3=		@mysqld.3.socket

Os resultados da execução do caso são os seguintes:

 
############################################################
# 1. Deploy a 3 members group in single primary mode.
include/group_replication.inc [rpl_server_count=3]
Warnings:
Note	####	Sending passwords in plain text without SSL/TLS is extremely insecure.
Note	####	Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
[connection server1]
[connection server1]
include/start_and_bootstrap_group_replication.inc
[connection server2]
include/start_group_replication.inc
[connection server3]
include/start_group_replication.inc
 
############################################################
# 2. Init data
[connection server1]
CREATE TABLE t1 (c1 INT PRIMARY KEY);
INSERT INTO t1 VALUES(1);
include/rpl_sync.inc
SELECT * FROM t1;
c1
1
[connection server2]
SELECT * FROM t1;
c1
1
[connection server3]
SELECT * FROM t1;
c1
1
 
############################################################
# 3. Mock crash majority members
# server 2 wait before write relay log
[connection server2]
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
# server 3 wait before write relay log
[connection server3]
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
# server 1 commit new transaction
[connection server1]
INSERT INTO t1 VALUES(2);
SELECT * FROM t1;
c1
1
2
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier	127.0.0.1	13000	ONLINE	PRIMARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13002	ONLINE	SECONDARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13004	ONLINE	SECONDARY	8.0.32	XCom
# server 1 crash
# Kill the server
# sleep enough time for electing new leader
 
# server 3 check
[connection server3]
SELECT * FROM t1;
c1
1
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier	127.0.0.1	13002	ONLINE	PRIMARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13004	ONLINE	SECONDARY	8.0.32	XCom
# server 3 crash and restart
# Kill and restart
# sleep enough time for electing new leader
 
# server 2 check
[connection server2]
SELECT * FROM t1;
c1
1
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier	127.0.0.1	13002	ONLINE	PRIMARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13004	UNREACHABLE	SECONDARY	8.0.32	XCom
# server 2 crash and restart
# Kill and restart
# sleep enough time for electing new leader
 
############################################################
# 4. Check alive members, lost t1(c1=2) record
# server 3 check
[connection server3]
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier		NULL	OFFLINE			
# server 3 lost t1(c1=2) record
SELECT * FROM t1;
c1
1
 
# server 2 check
[connection server2]
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier		NULL	OFFLINE			
# server 2 lost t1(c1=2) record
SELECT * FROM t1;
c1
1

A lógica aproximada de um caso que reproduz números faltantes é a seguinte:

1. O MGR consiste em 3 nós em modo mestre único, Servidor 1/2/3, onde o Servidor 1 é o banco de dados principal e inicializa 1 registro c1=1
2. Injeção de falha O servidor 2/3 irá travar ao gravar o Relay Log
3. Conectado ao nó do Servidor 1, gravou o registro de c1=2, e o commit da transação também retornou sucesso.
4. Então o servidor Mock1 trava de forma anormal (falha da máquina, não pode ser restaurado e não pode ser acessado neste momento, o Servidor 2/3 é deixado para formar a maioria).
5. Reinicie o Servidor 2/3 normalmente (recuperação rápida), mas o Servidor 2/3 não pode restaurar o cluster para um estado utilizável.
6. Conecte-se ao nó do Servidor 2/3 e consulte os registros do banco de dados. Somente o registro de c1=1 é visto (o Servidor 2/3 perdeu c1=2).

De acordo com o caso acima, para MGR, quando a maioria dos servidores estiver inoperante e o banco de dados principal indisponível, e após a restauração do banco de dados standby, haverá perda de dados de RPO<>0, e o registro de commit bem-sucedido que foi originalmente devolvido ao cliente é perdido.

Para DN, o alcance da maioria requer que os logs sejam persistidos na maioria, portanto, mesmo no cenário acima, os dados não serão perdidos e o RPO=0 poderá ser garantido.

3.4. Atraso na reprodução do banco de dados em espera

No modo de espera ativo tradicional do MySQL, o banco de dados de espera geralmente contém threads de IO e threads de aplicação. Após a introdução do protocolo Paxos, o thread de IO sincroniza o log binário dos bancos de dados ativos e de espera principalmente. depende da sobrecarga da reprodução do Apply do banco de dados de espera, aqui nos tornamos o atraso de reprodução do banco de dados de espera.

Usamos o sysbench para testar o cenário oltp_write_only e testar a duração do atraso na reprodução do banco de dados standby em 100 simultaneidades e diferentes números de eventos.O tempo de atraso de reprodução do banco de dados de espera pode ser determinado monitorando a coluna APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP da tabela performance_schema.replication_applier_status_by_worker para ver se cada trabalhador está trabalhando em tempo real para determinar se a replicação foi finalizada.
 

Isso pode ser visto no gráfico de resultados do teste:

• Sob a mesma quantidade de dados gravados, o tempo de conclusão da reprodução do banco de dados em espera do DN de todos os logs é muito melhor do que o consumo de tempo do MGR DN, que é de apenas 3% a 4% do MGR. Isto é fundamental para a oportunidade da transição ativo/em espera.
• À medida que o número de gravações aumenta, a vantagem de latência de reprodução do banco de dados em espera do DN sobre o MGR continua a ser mantida e é muito estável.
• Analisando os motivos do atraso na reprodução do banco de dados standby, a estratégia de reprodução do banco de dados standby do MGR adota group_replication_consistency com o valor padrão de EVENTUAL, ou seja, as transações RO e RW não aguardam a aplicação das transações anteriores antes da execução. Isso pode garantir o desempenho máximo de gravação do banco de dados principal, mas o atraso do banco de dados em espera será relativamente grande (sacrificando o atraso do banco de dados em espera e RPO = 0 em troca da gravação de alto desempenho do banco de dados principal, ativando a função de limitação de corrente do MGR pode equilibrar o desempenho e o banco de dados standby está atrasado, mas o desempenho do banco de dados principal será comprometido)

3.5. Resumo do teste

4. Resumo

Após análise técnica aprofundada e comparação de desempenho,PolarDB-X Com seu protocolo X-Paxos autodesenvolvido e uma série de designs otimizados, o DN demonstrou muitas vantagens sobre o MySQL MGR em termos de desempenho, correção, disponibilidade e sobrecarga de recursos. No entanto, o MGR também ocupa uma posição importante no ecossistema MySQL. , várias situações, como jitter de interrupção do banco de dados em espera, flutuações de desempenho de recuperação de desastres entre salas de máquinas e estabilidade, precisam ser consideradas. Portanto, se você deseja fazer bom uso do MGR, deve estar equipado com uma equipe técnica e de operação e manutenção profissional. apoiar.

Quando confrontado com requisitos de grande escala, alta simultaneidade e alta disponibilidade, o mecanismo de armazenamento PolarDB-X tem vantagens técnicas exclusivas e excelente desempenho em comparação com o MGR em cenários prontos para uso.PolarDB-XO centralizado baseado em DN (versão padrão) possui um bom equilíbrio entre funções e desempenho, tornando-o uma solução de banco de dados altamente competitiva.