Início / server / Perguntas / 1162978
Accepted
Patrick Teng
Asked: 2024-07-24 16:03:32 +0800 CST

Gerando MySQL Dump via instância iniciada na AMI

  • 772

Eu tenho uma instância de servidor ec2 ativa em execução com MySQL instalado localmente (sem usar RDS) e outro servidor de backup que executa a replicação MySQL como escravo do servidor ativo.

Agora estou tentando gerar dumps SQL automatizados diariamente e até agora tenho pesquisado na AWS CLI para automatizar todo o processo,

  1. iniciar uma instância com snapshot AMI do servidor ativo (backup feito diariamente)
  2. execute o comando de despejo mysql
  3. encerre a instância e exclua o volume.

Eu fiz funcionar totalmente (os comandos e assim por diante), mas percebi que um problema é que o MySQL na instância iniciada via AMI é muito lento, leva 2-3x mais tempo para gerar um backup completo (em comparação com fazê-lo no servidor ativo).

Tentei não fazer isso no servidor de backup/escravo, pois queremos que os dados do servidor de backup estejam sempre prontos, mas gerar um mysqldump exigirá temporariamente a pausa do escravo e a retomada mais tarde (ou seja, haverá um atraso para xx período de tempo, em que xx é o tempo necessário para que o dump do mysql seja gerado).

Existe alguma solução melhor para isso? Não estamos usando RDS principalmente devido ao custo, por isso estamos fazendo tudo manualmente.

Meu objetivo é criar vários arquivos de backup sql, por tabela, em certo sentido, 1 arquivo para 1 tabela, mas cada um dos arquivos deve ter as mesmas datas limite em termos de dados.

amazon-web-services

2 respostas

  1. É muito fácil saber por que o backup está demorando muito mais.

    Embora o instantâneo exista assim que a AWS informar que existe, neste ponto ele é apenas um conjunto de ponteiros para os dados originais. Em segundo plano, a AWS está executando um trabalho de cópia para preencher os dados. Se você tentar ler algo do snapshot que ainda não foi preenchido, sua chamada de leitura será bloqueada, a AWS colocará a solicitação no topo da lista de replicação e você precisará aguardar até que os dados sejam preenchidos. Esta população de dados é chamada de “ hidratação ”.

    A única maneira de contornar isso é ter outra réplica em execução o tempo todo.

    iniciar uma instância com snapshot AMI do servidor ativo

    Portanto, a menos que você esteja parando o servidor ativo para criar o snapshot, isso também significa que há uma longa pausa na inicialização da nova instância para que o MySQL execute a recuperação de falhas. Você pode considerar usar um instantâneo da réplica temporariamente interrompida que você já possui para evitar isso.

    Depois de ter uma réplica com dados totalmente preenchidos, ela será usada apenas para executar o mysqlbackup (ou seja, simultaneidade MUITO baixa), então você poderá fazer o backup mais rápido aumentando o readahead (até 8x o padrão).

    Alternativamente (ou sujeito a testes, em combinação), você pode considerar usar o Percona Xtrabackup - isso fará backup usando vários threads.

    ou seja, as razões pelas quais sua lentidão (na ordem estimada de impacto) são:

      1=) snapshot hydration
  1=) Crash recovery
  3) IO latency
  4) CPU

    Uma abordagem alternativa seria criar um instantâneo do sistema de arquivos no host, em vez de um instantâneo AWS do dispositivo de bloco (sem necessidade de cópia). Então você pode montá-lo no host e usar os arquivos de dados brutos para o backup ou ativar uma segunda instância do mysql no mesmo host para acessar o instantâneo e executar o mysqlbackup.

    Ou apenas trate o instantâneo da AWS como backup.

    • 2
  2. Best Answer

    É difícil dizer por que exatamente a execução do backup em uma nova instância leva de 2 a 3 vezes mais tempo, mas aqui estão algumas coisas a serem verificadas/consideradas:

    • A classe da instância é igual à instância de produção? Menos CPU/memória na instância de backup certamente pode contribuir para o tempo necessário para realizar um backup completo.
    • Se for uma instância apoiada por EBS, o volume anexado tem a mesma classe e tamanho de armazenamento que a instância de produção, ou seja, número de IOPS provisionado?
    • Se o snapshot da AMI for obtido durante uma instância em execução enquanto o MySQL estiver em execução, alguns dados poderão não ser descarregados no disco e alguns arquivos do MySQL poderão permanecer em um estado sujo. Ao inicializar a nova instância, pode levar mais tempo para executar algumas verificações e procedimentos de recuperação para deixar o servidor em um estado limpo.

    Existe alguma solução melhor para isso? Não estamos usando RDS principalmente devido ao custo, por isso estamos fazendo tudo manualmente. mas gerar um mysqldump exigirá temporariamente a pausa do escravo e a retomada mais tarde

    Você pode criar um dump do banco de dados a partir da réplica (ou primária) sem bloquear as tabelas ou pausá-las de qualquer forma. Veja --single-transactionse você está usando InnoDB, alguma explicação sobre isso aqui .

    Atualização : se você deseja criar arquivos separados para tabelas separadas em uma única transação, sem precisar bloquear as tabelas individuais, há um --tabargumento que você pode usar mysqldump: https://dev.mysql.com/doc/refman/8.4 /en/mysqldump-delimited-text.html

    • 1

relate perguntas