Melhorando a velocidade de replicação do MySql

Question

Estou procurando ponteiros sobre como melhorar a velocidade de replicação de um escravo mysql. É rápido o suficiente para a produção normal, mas precisa de muito tempo para recuperar o atraso se ficar para trás por algum motivo. (Se o servidor foi desligado ou a replicação parou por algumas horas, etc.)

Alguns dados:

• O banco de dados é de cerca de 2 TB e os binlogs escritos diariamente estão em torno de 500 GB.
• Para uso normal de produção, o atraso do escravo fica em 0 ou 1 segundo
• Ao tentar alcançá-lo, aproxime-se do master em torno de 1 segundo por segundo. (Então, pegando 10 horas leva 10 horas)
• O escravo está REPREENDENDO APENAS os dados como uma máquina de failover, não há seleções em execução e deve ser capaz de substituir o mestre se ele morrer (tudo é lento, mas isso é ok)
• Os servidores estão na mesma rede física

O que pode ser feito para melhorar essa velocidade?

(Sim, melhorar o hardware é uma opção, mas queremos garantir que verificamos outras opções antes de gastar muito dinheiro)

Editar:

Alguns dados em resposta a @ 3molo pergunta:

• Uso do Bandwith durante a recuperação: ~ 2MB / s a 10MB / s, não há problema, eu acho.
• O uso da CPU é baixo, a espera do io é alta (o escravo tem apenas 2 CPUs, cerca de 70 a 85% do percentual de espera enquanto recupera o atraso. Isso significa que o gargalo está nos discos?
• O uso de RAM é de 1,5 GB usado para 4 GB (o restante é 'armazenado em cache'). Então eu não vejo tanto potencial lá? (Como é só gravar a carga de qualquer maneira (?))

Se o afunilamento for os discos (configuração do 6 disk raid 10), há alguma opção além de aumentar o raid ou temos que ir com isso?

    

Answer 1

Isso seria interessante para anotar ao mesmo tempo:

• quanta largura de banda é usada

• quanta utilização de cpu (especialmente espera de i / o)

• uso de RAM

Em resposta às novas informações sobre o i / o, espere ser alto; Para innodb muito pode ser feito, dê uma olhada. Eu aprendi muitas coisas do mysqlperformanceblog. Aqui estão algumas dicas:

innodb_flush_method = O_DIRECT

"Evite buffer duplo e reduza a pressão de troca, na maioria dos casos essa configuração melhora o desempenho. No entanto, tenha cuidado se você não tiver o cache RAID de backup da bateria como quando o IO de gravação pode sofrer."

innodb_flush_log_at_trx_commit = 2

"Se você não estiver preocupado com o ACID e perder transações por último segundo ou dois em caso de falha total no sistema operacional, defina esse valor. Isso pode ter um efeito dramático, especialmente em várias transações de gravação curtas".

Aqueles fizeram WONDERS para nós, mas a desvantagem é que você pode perder um segundo de dados escritos. Isso ocorre porque, em vez de gravar (liberar para o disco) todos os registros, você flui a cada segundo.

Você pode ler mais em: link

    

Answer 2

A replicação do MySQL é rápida, muito rápida. Sua principal limitação é a camada de link e o restante do hardware.

No seu caso, a continuação da replicação provavelmente mostrará os logs binários ou o IO escravo se recuperando rapidamente. Se não, melhore primeiro o seu link. Caso contrário, se for o SQL, você terá as limitações físicas do servidor, que variará entre E / S do disco, RAM e CPU, dependendo do tipo de carga.

    

Answer 3

eu. Adicione pequenas, mas simples, otimizações de E / S para arquivos de informações

sync_relay_log_info = 5000000

sync_master_info = 5000000

II. Use multi-threading (pode ser pior resultado)

slave_parallel_workers = 10

log_slave_updates = 1

slave_preserve_commit_order = 1

slave_parallel_type = LOGICAL_CLOCK

slave_pending_jobs_size_max = 1047527424 # não deve ser menor que seu max_allowed_packet

• Para ativação - reinicie

III. Se você tiver problemas de largura de banda, tente usar a compactação

slave_compressed_protocol = 1

• Para ativação "STOP SLAVE; START SLAVE;"

IV. Para alguns ambientes, o ponto principal é - há um grande IO em arquivos de relay-log.

Ele cria um problema até mesmo para algumas unidades SSD e faz com que seja um problema para o HDD.

Então, apenas movemos tudo para a RAM e conseguimos aumentar o desempenho em alguns momentos.

1. Crie uma unidade de RAM

Por exemplo, no diretório / tmp

Edite o / etc / fstab para ter algo como:

tmpfs / tmp tmpfs padrões, noatime, nodiratime, nosuid, nodev, modo = 1777, tamanho = 1500M 0 0

E inicie-o

mount -o remount / tmp

2. Adicionar a /etc/mysql/my.cnf

relay_log_space_limit = Limite de tamanho de 500 M # para todos os arquivos de log salvarem sua pequena unidade tmpfs

max_relay_log_size = 100M; # precisa ser pelo menos duas vezes menor que o limite de espaço

relay-log = / tmp / YOUR_HOSTNAME-relay-bin

master-info-file = /tmp/master.info

relay-log-info-file = /tmp/relay-log.info

Limpar \ redimensionar o log de retransmissão atual se for muito grande antes de adicionar novas instruções de caminho

3. Escravo de desligamento

4. Mova YOUR_HOSTNAME-relay-bin, master.info, relay-log.info da localização atual (padrão / var / lib / mysql) para / tmp

   • Não se esqueça de "chown mysql: mysql" que arquivos

Você pode, mas possivelmente, não querer usar este caminho por um longo tempo devido a rescaldo de novas reinicializações e métodos rudes para evitar erros após eles (como slave-skip-errors = 1062,1032,1396)

Mas

• é uma maneira de recuperar rapidamente casos em conflito

• às vezes é o único caminho devido à falta de recursos