rsync --inplace não está lendo o arquivo de destino?

2

Estou tentando otimizar o backup diário de um instantâneo LVM de um grande banco de dados MySQL. Funciona muito bem quando eu apenas cp os arquivos (RAID local para outro RAID local), com uma velocidade média de ~ 100MB / s. Mas como os arquivos de banco de dados (600GB, a maioria em dois arquivos de 350GB e 250GB) não mudam muito ao longo de um dia, achei que seria mais eficiente copiar apenas os blocos alterados.

Estou usando

rsync --safe-links --inplace -crptogx -B 8388608 /source/ /destination/

Funcionou, foi mais lento que a cópia simples e não vi nenhuma atividade de leitura no disco de destino. Meu pensamento era que o rsync leria (8MB) blocos da origem e do destino, compararia suas somas de verificação e copiaria apenas o bloco de origem para o arquivo de destino se ele fosse alterado. Estou me enganando aqui? Por que não estou vendo o rsync lido do alvo para determinar se os blocos foram alterados?

Aqui estão alguns gráficos:

Uso de disco : você vê que rsync --inplace (feito somente para o arquivo maior no último dia) reduziu o "dent" no uso do disco de / mnt / backup, o que significa que realmente atualizou o arquivo existente.

IOstats:obackupéfeitodesdaparasdb.Dealgumaforma,háumenormepiconasleiturasdafonte,seguidopelaatividade"normal" de leitura (origem) + gravação (destino). Eu estava esperando leituras simultâneas de ambos os dispositivos com pouca atividade de gravação no destino.

    
por Stefan Seidel 22.01.2013 / 08:51

2 respostas

2

O que você provavelmente está vendo é devido à maneira como seus arquivos são alterados e como o rsync está calculando as somas de verificação. A página do manual do rsync sobre --inplace tem uma explicação básica:

          o      The efficiency of rsync's delta-transfer algorithm may be
                 reduced if some data in the destination file is overwrit-
                 ten  before  it  can be copied to a position later in the
                 file.  This does not apply if  you  use  '--backup',  since
                 rsync is smart enough to use the backup file as the basis
                 file for the transfer.

Portanto, você provavelmente não deve usar --inplace ou use --backup para preservar a cópia antiga do arquivo. Dito isto, o rsync parece lidar com arquivos grandes de forma bastante ineficiente, por isso pode não ser a melhor ferramenta para o trabalho.

Se você estiver usando o LVM e realmente quiser transferir dados de snapshots, talvez não queira executar o rsync, que requer bastante cálculo e E / S nos dois lados, mas copie os dados do CoW do snapshot para a máquina de destino usando lvmsync em vez disso - isso pouparia os ciclos de E / S e da CPU ao preço de um tamanho de transferência presumivelmente maior.

Outra abordagem para o problema seria fazer checksums de dispositivos de bloco "burros" (por exemplo, com MD5) e transferir blocos de diferenciação como esta resposta aqui no ServerFault ou no script blocksync.py (associei o último fork ativo dele). Ele não dependeria de instantâneos, mas obviamente você desejaria criar um para o tempo da cópia para garantir que a consistência de seus dados seja mantida.

Se você estiver preocupado com o desempenho de gravação do seu banco de dados com instantâneos ativos, também poderá dar uma olhada em ddsnap que contém várias otimizações para snapshot e replicação de volume, trabalhando efetivamente em torno de suas preocupações.

    
por 22.01.2013 / 09:15
0

Eu acredito que você queira --inplace --no-whole-file . Observe que, para sistemas de arquivos locais, --whole-file é assumido (consulte a página do manual rsync). Veja um pequeno teste no unix.SE . Observe os comentários.

    
por 10.12.2017 / 05:12