otimizar a saída do mysqldump para o zfs dedup

1

Meu desafio é armazenar o maior número possível de dumps do mysql em um determinado pool do ZFS.

O próprio pool tem dedup e compactação ativada . Para armazenar várias versões dos dumps, são usados instantâneos (a cada 15 minutos, a cada hora, a cada dia, a cada semana e a cada mês).

A maioria das tabelas nos vários bancos de dados no servidor MySQL estão crescendo e não mudam com muita frequência. Meu pensamento era fazer um dump por tabela em vez de por banco de dados para dar ao zfs uma chance de deduzir no nível de bloco.

O script de backup usa a saída do mysqldump e o canaliza para um arquivo (com mysqldmup -u$user -p$pass $db $table > $outputfile.sql

  • A dedução do ZFS pode deduzir um fluxo do stdout a uma boa taxa?
  • O tamanho do bloco do destino deve ser configurado manualmente? (e se sim - qual tamanho?)
  • É necessário aplicar algum tipo de buffer de saída (além do buffer de linha)?
  • As gravações de uma sincronização de redirecionamento ou assíncrona?

EDIT para acertar: O que é necessário para fazer um arquivo escrito linha por linha como um arquivo que foi copiado se o conteúdo for (quase [por exemplo, somente a última linha difere]) o mesmo?

    
por Martin Seitl 22.05.2017 / 18:09

1 resposta

1

A desduplicação está sempre no nível do bloco (assim como os instantâneos e a copressão), a estrutura dos dados acima não importa. Portanto, você poderia ter um único arquivo em vez de mil arquivos pequenos e isso não faria diferença em relação à desduplicação.

Por outro lado, o tamanho do seu bloco faz diferença, devido a vários motivos:

  • Quanto maiores são os seus blocos, mais desperdício pode ocorrer porque alguns bytes de um arquivo muito pequeno podem reservar o tamanho de um bloco grande (o tamanho do bloco é a menor e não pode ser mais dividido)
  • Quanto menores os seus blocos, mais lento será seu desempenho, porque para ler o mesmo arquivo, você precisa ler muitos blocos (cada leitura tem uma pequena sobrecarga e cada bloco pode estar completamente posição diferente em todo o disco)
  • A desduplicação funciona em blocos, portanto, um tamanho pequeno poderia obter melhores resultados
  • Por outro lado, isso aumenta o número de blocos que devem ser referenciados na memória e podem prejudicar seu desempenho. Para os cálculos de compensação e exemplo, consulte este post do blog - o essencial é que você precisa de uma grande quantidade de memória e depende dos seus dados

O dimensionamento é, portanto, importante, mas também não tão fácil . Parece que você já tem dados suficientes, então eu apenas testaria: crie dois sistemas de arquivos (se possível depois e não simultaneamente para minimizar o efeito um no outro), um com um tamanho de bloco muito pequeno (4K), um com um tamanho muito grande (128K) e copie seus dados e compare os resultados. Você também pode simular o desempenho de desduplicação com zdb -b poolname comparando as contagens de bloco e, em seguida, calculando suas economias. Se nenhum desses resultados parecer bom para você, experimente tamanhos diferentes, como 16K, 32K ou 64K.

    
por 23.05.2017 / 09:36