WordPress E Os Dois Hifens

Revisando o meu último post, notei que havia algo diferente do que eu havia escrito originalmente nos meus comandos. Antes da maior parte dos parâmetros havia um travessão em vez de dois hifens, o que não condiz com a sintaxe aceita do comando rsync (e nem mesmo condiz com o que eu escrevi).

Acabei descobrindo que o WordPress tem um “feature” inconveniente, que é transformar automaticamente dois hifens (--) em um travessão (–) e que não há opção clara para desabilitar essa transformação. Excelente, especialmente para quem rodar os comandos do post passado com apenas um hífen e receber as seguintes mensagens:

rsync: link_stat “/hd-backup/\#226partial” failed: No such file or directory (2)
rsync: link_stat “/hd-backup/\#226append” failed: No such file or directory (2)
rsync: link_stat “/hd-backup/\#226progress” failed: No such file or directory (2)
rsync: link_stat “/hd-backup/\#226bwlimit=20480” failed: No such file or directory (2)
rsync: link_stat “/hd-backup/\#226no-whole-file” failed: No such file or directory (2)
delta-transmission disabled for local transfer or --whole-file

Obrigado, WordPress, por não ser Linux-friendly.

Agora, como corrigir isso nos posts do WordPress:

Ir para a opção de entrada Text (em contrapartida a Visual), e lá substitua os seus -- por:

&#45 ; &#45 ;

Atenção, sem os espaços antes e depois dos ponto-e-vírgula.

E voilá:

rsync -vv --partial --append --progress --bwlimit=20480 --no-whole-file arquivo.tar.gz /mnt/servidorbackup/

OBS: o primeiro hífen antes de vv é realmente simples e não foi um erro.

É isso. Até!

SCP vs RSYNC

Eu tinha a seguinte situação: eu tinha que transferir, diariamente, um arquivo de backup .tar.gz de 140+Gb de um servidor para o outro. Era um Linux transferindo de uma localização para um ponto de montagem que na verdade era um outro servidor Windows. Acontece que, durante a longa transferência, o servidor primário ficava sobrecarregado (até porque é onde roda o Oracle de produção), e congelava diversos sistemas da empresa, o que gerava uma série de razoáveis reclamações. Sempre que acontecia isso, eu tinha que cancelar a cópia e recomeçar algum tempo depois, quando o banco estivesse com uma utilização reduzida – correndo o risco de novamente ter um pico de utilização, gerar mais congelamento e ter que parar novamente.

O comando que eu utilizava era o:

scp arquivo.tar.gz /mnt/servidorbackup/

Então pesquisei alternativas, e cheguei ao rsync. Um comando bem parrudo, com diversas utilidades. Então comecei a testar os parâmetros e observar o impacto no banco. Comecei com as seguintes opções:

rsync -vv --partial --progress arquivo.tar.gz /mnt/servidorbackup/

No caso -vv é verbose (o v duplo é para mais informações de verbose), --partial é para manter o arquivo parcialmente transferido caso o rsync tenha que ser interrompido e --progress é para imprimir o progresso da transferência.

Mas, com esse comando, eu notei que quando eu retomava a transferência após interrupção, o rsync criava um outro arquivo e recomeçava a transferência. Tinha algo errado. Pesquisei mais e descobri que quando ocorre a transferência dentro do mesmo sistema local (mesmo que o destino fosse um servidor remoto, ele estava sendo tratado como local por ser um ponto de montagem), o delta-transmission é desligado por padrão – isso quer dizer que a transferência não pode ser resumida de onde parou, só começada do zero. A solução vem do parâmetro --no-whole-file que força o delta-transmission mesmo para transferências locais. E o meu comando ficou assim:

rsync -vv --partial --progress --no-whole-file arquivo.tar.gz /mnt/servidorbackup/

Mesmo com o rsync sendo mais lento que o scp e o cp, a transferência impactava no banco em pouco tempo. Pesquisando um pouco mais, vi que podia limitar a taxa de transferência do arquivo com o parâmetro --bwlimit, sendo este definido em Kb/s. Então limitei a transferência em 20Mb/s, como pode ser visto no comando abaixo:

rsync -vv --partial --append --progress --bwlimit=20480 --no-whole-file arquivo.tar.gz /mnt/servidorbackup/

No caso, o --append é para que o rsync não verifique todo o arquivo temporário já presente no servidor remoto e simplesmente retome a transferência a partir de onde parou. Só utilizo isso por saber que o arquivo de origem não sofreu alterações desde que comecei a primeira transferência.

A saída desse comando é:

[root@quaseparando]# rsync -vv --partial --append --progress --bwlimit=20480 --no-whole-file arquivo.tar.gz /mnt/servidorbackup/
sending incremental file list
delta-transmission enabled
arquivo.tar.gz
53696366592 97% 10.69MB/s 0:06:40

Agora só acompanho com o top para ver se preciso parar o rsync com ctrl+c e não preciso mais passar pelo perrengue de recomeçar do zero duas ou três vezes por dia.

É isso. Até!

Bobby Tables

Abençoando o blog com um pouco de XKCD antes de começar realmente.

Introdução

Acho que, antes de mais nada, devo me apresentar.

Meu nome é Daniel. Sou estudante da UNIRIO de Sistemas de Informação, atualmente no 1254º período. Trabalho numa empresa de segurança da informação.

Antes disso, trabalhei na Retis do Brasil com uma plataforma da Aptilo em um projeto para a TIM Brasil, projeto esse que envolve o serviço de WiFi prestado em aeroportos e locais públicos em geral (veja mais aqui).

Antes  eu trabalhei na Oracle por um ano, em dois grandes projetos para a Vale e a B2W, período que me ensinou muito, tanto sobre banco como aplicações (eBusiness Suite, SOA, etc), além de realmente me introduzir ao mundo Oracle.

E, finalmente, logo antes da Oracle eu trabalhei na Orange Business Services por dois anos. Eu era suporte nível 2 dedicado à BHP Billiton, tratando de sua rede WAN que envolvia dezenas de equipamentos Cisco.

Agora então eu vejo uma nova oportunidade de estudar e me aprofundar em Oracle, e dessa vez eu não vou parar. E vou relatar aqui as minhas experiências e aprendizados. :)

Até!