Taxa de ressincronização extremamente baixa de DRBD em gigabits dedicados

Question

Eu configurei o DRBD em dois nós e comecei a usá-lo ontem. Após cerca de uma hora, ele havia ressincronizado 50% da partição. Outras 12 horas se passaram, e é de até 79%, e se movendo MUITO devagar.

Veja o que cat / proc / drbd mostra:

 1: cs:SyncTarget ro:Primary/Secondary ds:Inconsistent/UpToDate C r-----
    ns:464931976 nr:191087032 dw:656013660 dr:214780588 al:100703 bm:21100 lo:7 pe:0 ua:0 ap:7 ep:1 wo:f oos:92241852
        [==============>.....] sync'ed: 79.2% (90076/431396)M
        finish: 76:13:38 speed: 332 (8,680) want: 19,480 K/sec

Eu olhei para o tráfego de rede e estou usando entre 1M e 20M na interface 1G. Tentei executar o iperf enquanto tudo isso está acontecendo, e recebo uma leitura de 930M. Tentei ajustar a taxa de sincronia para 10M, 50M, 500M sem sucesso. Tweaked tamanho do pacote sem sorte também.

Agora, a ressalva, como você pode ver no status, é que meu nó primário é inconsistente. Então eu suponho que o sistema operacional está trabalhando essencialmente com um nó secundário enquanto o ressincronizador está funcionando. Mas, como a taxa de transferência é muito baixa, não entendo por que a sincronização não é mais rápida.

Alguma idéia do que eu posso tentar em seguida? Acabamento estimado de 76 horas não é algo que estou ansioso para :( Especialmente não sabendo o motivo, então vem uma espécie de interrupção, eu não sei como trazer a matriz a consistência rápida.

Obrigado!

EDIT: Eu tentei as seguintes configurações na seção de rede sem sucesso:

sndbuf-size       512k;
max-buffers      20480;
max-epoch-size   16384;
unplug-watermark 20480;

EDIT 2: Por nenhuma razão aparente, a velocidade saltou para 10 ~ 30M, depois que parei de ajustar todas as configurações. Ficou até 98,8% sincronizado e caiu de volta para ~ 300K. Nenhuma mensagem nos logs em nenhum dos servidores. Coincidentemente, vejo um aumento na atividade INSERT no banco de dados MySQL que é executado nesta partição. Alguma idéia?

EDIT 3: Versão: 8.4.2 (api: 1 / proto: 86-101)

    

Answer 1

Após o comentário @Nils, comecei a investigar como os discos são utilizados. E notei que estou recebendo muito mais leituras do que antes da reconfiguração do sistema para o DRBD. Pesquisas posteriores mostraram a utilização do disco em quase 100% e a lentidão dos processos em lote que estavam sendo executados naquele momento. Corrigir a configuração do MySQL para aumentar o tamanho do buffer pool para eliminar a maioria das leituras parece corrigir o problema.

Então o problema era que as unidades estavam tão ocupadas, que não podiam lidar com muito trabalho de ressincronização que o DRBD queria lançar nelas.

    

Answer 2

Tente forçar uma taxa de sincronização

drbdsetup /dev/drbd0 syncer -r 100M

Você também pode configurar isso após a reinicialização por meio do syncer {} na configuração

    

Answer 3

Você já encontrou a origem do problema - heavy read-io. Tweaking the sndbuf-size ajuda no pesado write-io (mas aumenta a asyncness no modo A do protocolo), rcvbuf-size pode ter ajudado no seu caso.

Mas a melhor solução foi remover a raiz do seu problema.

Mais leituras também podem estar relacionadas ao DRBD-meta-device (embora eu também espere mais em situações de escrita).