Retalhos e lentidão recorrentes em um cluster do Percona XtraDB

Question

Eu tenho 5 servidores dedicados (máquinas idênticas: 32 núcleos, 96GB de RAM, drives SSD em RAID e link gigabit ethernet) configurados com o Percona XtraDB Cluster.

Há um problema recorrente que causa uma grave desaceleração do cluster por cerca de 30 a 60 segundos, mas às vezes fica preso por até 5-10 minutos.

O sistema é usado para uma rede ocupada de sites e eu uso o mysql-proxy em cada servidor para balancear o tráfego para o banco de dados.

O problema não está presente se apenas um nó estiver ativado. Com cada nó adicionado, em vez disso, o problema aumenta em intensidade (quantidade de tempo que as consultas são desaceleradas / travadas) até se tornar insuportável com 4 nós ativos (o cluster neste ponto não é mais capaz de se recuperar automaticamente).

Aqui estão os sintomas detalhados:

1. A cada 5 a 15 minutos, todas as consultas de gravação (INSERTs / UPDATEs) ficam presas na fila de todos os nós. Algumas das consultas são enviadas após 45 a 50 segundos, enquanto outras são completamente interrompidas.
2. Na maioria das vezes, depois de 30 a 60 segundos, o cluster é capaz de recuperar o atraso e rapidamente envia as consultas em um intervalo de 1-2 segundos.
3. Às vezes, o cluster não é capaz de lidar automaticamente com essas consultas bloqueadas e eu preciso desabilitar manualmente os sites mais ocupados, para que a carga seja reduzida e após 30 segundos de ter quase nenhuma carga, o cluster pode enviar novamente todas as consultas .

4. Os logs de erro geralmente são limpos, sem mensagens de erro antes ou depois da ocorrência da lentidão. Raramente eu recebo algo assim (talvez 1 vez em 10):

   130906 9:53:27 [Nota] WSREP: (3f3abd42-15bc-11e3-b38b-2e049b972e3b, 'tcp: //0.0.0.0: 4567') ativando a retransmissão de mensagens solicitando pares não-vivos: tcp: // IPOFONEOFENSENDO

   130906 9:53:27 [Nota] WSREP: (3f3abd42-15bc-11e3-b38b-2e049b972e3b, 'tcp: //0.0.0.0: 4567') ativando a retransmissão de mensagens solicitando desativação

5. Eu geralmente tenho uma wsrep_cert_deps_distance de aproximadamente 400 sob carga normal. Assim que a lentidão começa, o wsrep_cert_deps_distance aumenta lentamente até o intervalo de 2k-3k (quando atinge a marca de 3k, eu preciso desabilitar manualmente o aplicativo ou o cluster não pode se recuperar sozinho)

6. Monitorando com mytop e no topo Eu não vejo alta carga no servidor ou no processo mysql. O uso da CPU é sempre razoavelmente baixo (cerca de 25% do máximo), tanto durante a operação normal quanto durante as lentidões. Uso de E / S é bom, muito RAM livre, vmcom sob o limite.

Eu uso myq_status para monitorar o cluster em todos os nós em tempo real e é isso que acontece:

• A variável wsrep_flow_control_paused está sempre em 0.0, mesmo quando as lentidões ocorrem.
• Não ocorrem wsrep_local_bf_aborts ou wsrep_local_cert_failures.
• Em todos os nós, a replicação de saída geralmente é 0 e aumenta para 200 a 300 quando a lentidão ocorre.
• A replicação de entrada é sempre 0 em cada nó (raramente 1, mas acontece mesmo sob carga normal). Isso me intriga, pois aparentemente não há um nó lento no cluster.
• Após 10 a 15 segundos do início da desaceleração, os ops e bytes enviados e recebidos se tornam 0 em cada nó. Eles permanecem em 0 por um ou dois segundos, então uma quantidade maior de operações e bytes ocorre no segundo seguinte, juntamente com um alto número de operações "oooe" (execução fora de ordem) Isso se repete a cada poucos segundos até o servidor voltar ao normal.

Aqui estão os detalhes dos testes que realizei para tentar solucionar o problema (sem qualquer sorte ...):

1. Eu verifiquei a rede primeiro: os servidores estão no mesmo rack com uma rede gigabit dedicada e tudo parece estar funcionando bem, sem perda de pacotes ou outros problemas de rede aparentes.
2. Eu verifiquei o uso da largura de banda: cada nó usa uma média de 30 a 100mbps (megabit) de largura de banda. Eu check-in em tempo real com "iftop" e enquanto o problema está ocorrendo o uso de largura de banda é geralmente menor que a média (15 a 30mbps). Enquanto a sincronização de uma largura de banda do nó sobe para 800-900mbps (como deveria ser), então eu não acho que a rede esteja saturada.
3. Eu tentei uma combinação de todos os nós para garantir que um nó em particular estivesse afetando todo o resto: o problema está sempre presente, não importa qual nó eu desative ou use. O problema está sempre relacionado ao número de nós ativos ao mesmo tempo.

Alguém já encontrou um problema semelhante? Obrigado antecipadamente!