Posso ler com segurança um arquivo anexado por outro processo?

Question

Se o processo A copia arquivos para algum local loc e o processo B copia regularmente os arquivos de loc para algum outro local, B pode ler um arquivo que está atualmente no processo de ser copiado para loc por A?

Estou usando o Ubuntu Linux 12.04, se isso for importante.

Informações básicas: desejo fazer um backup contínuo de um cluster do PostgreSQL. O PostgreSQL fornece o arquivamento do WAL para isso. Ele funciona fazendo com que o banco de dados chame um script que copia um arquivo WAL completo para algum local de backup.

Eu quero outro processo para copiar regularmente os arquivos WAL de backup para outro servidor. Se um arquivo WAL estiver sendo copiado no momento pelo banco de dados, o segundo processo ainda poderá ler o arquivo sem entrar em alguma condição de EOF antes que o arquivo seja copiado como um todo?

Em outras palavras: Posso fazer o seguinte sem sincronização entre A e B?

A                                   B
cp pg_xlog/some_wal_file /backup/   scp /backup/* user@remote-machine:/backups/

    

Answer 1

Acho que a melhor coisa é garantir que o processo B copie apenas arquivos que foram totalmente transferidos pelo processo A. Uma maneira de fazer isso seria usar uma combinação de cp e mv no processo A, já que o processo mv usa a chamada de sistema rename (desde que os arquivos estejam no mesmo sistema de arquivos) que é atômico. Isso significa que, da perspectiva do processo B, os arquivos aparecem em seu estado totalmente formado.

Uma maneira de implementar isso seria ter um diretório partial dentro do diretório /backup , que é ignorado pelo processo B. Para o processo A, você poderia fazer algo como:

file="some_wal_file"
cp pg_xlog/"$file" /backup/partial
mv /backup/partial/"$file" /backup

E para o processo B (usando bash ):

shopt -s extglob
scp /backup/!(partial) user@remote-machine:/backups/

Embora o programa que você provavelmente deseja examinar, tanto para o processo A como para o processo B, seja rsync . rsync cria arquivos parciais e atua atomicamente por padrão (embora geralmente os arquivos parciais sejam arquivos ocultos em vez de estarem em um diretório específico). O Rsync também evita a transferência de arquivos que não é necessário e possui um algoritmo delta especial para transferir apenas partes relevantes dos arquivos que precisam ser atualizados pela rede ( rsync deve ser instalado em ambos os locais, embora as transferências ainda sejam acima de ssh por padrão). Usando rsync para o processo A:

rsync -a --partial-dir=/backup/partial pg_xlog/some_wal_file /backup/

Para o processo B:

rsync -a --exclude=/partial/ /backup/ user@remote-machine:/backups/

    

Answer 2

Nesse cenário, a única garantia que você tem é que B não copiará o arquivo nem copiará um prefixo do arquivo. B não tem como saber que o arquivo está sendo gravado, então ele irá ler para o final (atual) do arquivo, então pare.

A maneira comum de evitar essa armadilha é copiar o arquivo com um nome temporário e depois renomeá-lo:

dest=$(TMPDIR=/backup mktemp)
trap 'rm -f "$dest"' INT HUP ERR
cp -p pg_xlog/some_wal_file "$dest"
mv "$dest" "/backup/some_wal_file"

No consumidor, organize para não copiar arquivos temporários. Em seu cenário, você pode fazer isso criando um arquivo de ponto - use dest=$(TMPDIR=/backup mktemp .XXXXXXXXXX) acima. Uma maneira mais simples é chamar rsync em vez de cp , já que rsync usa essa estratégia por padrão:

rsync -a pg_xlog/some_wal_file /backup/

No passo B, certifique-se de excluir esses arquivos temporários, por exemplo:

rsync -a --exclude='/.*' /backup/ user@remote-machine:/backups/

Se você não quiser confiar nos arquivos de ponto, poderá usar um diretório temporário. Mover um arquivo de um diretório para outro é atômico, desde que os dois diretórios estejam no mesmo sistema de arquivos.

mkdir -p /backup/incoming
cp -p pg_xlog/some_wal_file /backup/incoming/
mv /backup/incoming/some_wal_file /backup/

rsync -a --exclude=/staging  /backup/ user@remote-machine:/backups/