Tenho 5 servidores dedicados (máquinas idênticas: 32 núcleos, 96GB de RAM, drives SSD em RAID e link gigabit ethernet) configurados com Percona XtraDB Cluster.
Há um problema recorrente que causa uma grave desaceleração do cluster geralmente por cerca de 30 a 60 segundos, mas às vezes ele fica travado por até 5 a 10 minutos.
O sistema é usado para uma rede movimentada de sites e eu uso o mysql-proxy em cada servidor web para balancear a carga do tráfego para o banco de dados.
O problema não está presente se apenas um nó estiver ativado. Com cada nó adicionado, o problema aumenta de intensidade (quantidade de tempo que as consultas ficam lentas/travadas) até se tornar muito 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:
- A cada 5 a 15 minutos, todas as consultas de gravação (INSERTs/UPDATEs) ficam presas na fila de cada nó. Algumas das consultas são despachadas após 45 a 50 segundos, enquanto outras ficam completamente paralisadas.
- Na maioria das vezes, após 30 a 60 segundos, o cluster consegue de alguma forma se atualizar e despacha rapidamente as consultas em questão de 1 a 2 segundos.
- Às vezes, o cluster não é capaz de lidar com essas consultas travadas automaticamente e preciso desabilitar manualmente os sites mais movimentados para que a carga seja reduzida e após 30 segundos sem quase nenhuma carga, o cluster seja novamente capaz de despachar todas as consultas.
Os logs de erros geralmente são limpos, sem mensagens de erro antes ou depois da ocorrência da lentidão. Raramente 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 solicitação de retransmissão de mensagens, peers não ativos: tcp://IPOFONEOFTHENODES
130906 9:53:27 [Nota] WSREP: (3f3abd42-15bc-11e3-b38b-2e049b972e3b, 'tcp://0.0.0.0:4567') desativando solicitação de retransmissão de mensagem
Normalmente tenho um wsrep_cert_deps_distance de cerca de 400 sob carga normal. Assim que a desaceleração começa, wsrep_cert_deps_distance aumenta lentamente até a faixa de 2k-3k (quando atinge a marca de 3k, preciso desabilitar manualmente o aplicativo ou o cluster não consegue se recuperar sozinho)
Monitorando com mytop e atop não noto nenhuma carga alta 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 lentidão. O uso de E/S é bom, bastante RAM livre, vmcom abaixo do limite.
Eu uso myq_status para monitorar o cluster em cada nó em tempo real e é isso que acontece:
- A variável wsrep_flow_control_paused está sempre em 0,0, mesmo quando ocorrem lentidão.
- Não ocorre nenhum wsrep_local_bf_aborts ou wsrep_local_cert_failures.
- Em cada nó, a replicação de saída geralmente é 0 e aumenta para 200-300 quando ocorre a lentidão.
- 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á nenhum nó lento no cluster.
- Após 10 a 15 segundos do início da desaceleração, as operações e bytes enviados e recebidos tornam-se 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 grande número de operações "ooooe" (execução fora de ordem). Isso se repete a cada poucos segundos até que o servidor volte para normal.
Aqui estão os detalhes dos testes que realizei para tentar solucionar o problema (sem sorte...):
- Verifiquei primeiro a rede: 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 aparentes de rede.
- Verifiquei o uso da largura de banda: cada nó usa em média 30 a 100mbps (megabit) de largura de banda. Eu verifico em tempo real com "iftop" e enquanto o problema ocorre, o uso da largura de banda geralmente é menor que a média (15 a 30mbps). Durante a sincronização, a largura de banda de um nó sobe para 800-900mbps (como deveria ser), então não acho que a rede esteja saturada.
- Tentei uma combinação de todos os nós para ter certeza de que um nó específico estava 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? Desde já, obrigado!