Backup incremental do MySQL usando o Subversion

Question

Nossos servidores de banco de dados MySQL hospedam várias dezenas de bancos de dados, com tamanho de arquivo de dump variando de 1 a ~ 100 MB.

Atualmente, nossa abordagem de backup é mysqldump , agrupada em um script de shell e executada em um crontab. Isso funcionou muito bem para nós. A única desvantagem principal é o grande requisito de armazenamento para armazenar os arquivos de despejo.

Como o despejo de banco de dados MySQL é um arquivo de texto, naturalmente considero armazená-lo em um sistema de controle de versão, como o Subversion. Eu me lembro que o Subversion armazena apenas o delta de um arquivo em cada commit.

Esta abordagem é recomendada? Existem algumas dicas que devemos saber?

    

Answer 1

binlog mencionado pelo SirStan é uma boa abordagem.

alternativamente você pode executar mysqldumps e então usar rdiff-backup para criar backup de dumpfile. O rdiff manterá os últimos backups [você decide quantos], e será bastante eficiente em termos de espaço, já que mantém apenas um instantâneo completo da versão mais recente do arquivo + conjunto de diferenças, permitindo que ele reconstrua versões anteriores.

o que você colocar no svn, fica no svn. o repositório só cresce - por isso é um bom lugar para manter seus esquemas sql, código fonte e talvez docs; mas não dados reais do sql.

    

Answer 2

A documentação do MySQL pode ter exatamente o que você precisa. Backups incrementais binários! (Também é ótimo para um servidor escravo pobre em mans em rsync / ftp / etc).

MySQL supports incremental backups:

You must start the server with the --log-bin option to enable binary logging; see Section 5.2.4, “The Binary Log”. The binary log files provide you with the information you need to replicate changes to the database that are made subsequent to the point at which you performed a backup. At the moment you want to make an incremental backup (containing all changes that happened since the last full or incremental backup), you should rotate the binary log by using FLUSH LOGS. This done, you need to copy to the backup location all binary logs which range from the one of the moment of the last full or incremental backup to the last but one. These binary logs are the incremental backup; at restore time, you apply them as explained in Section 6.3, “Point-in-Time Recovery”. The next time you do a full backup, you should also rotate the binary log using FLUSH LOGS, mysqldump --flush-logs, or mysqlhotcopy --flushlog. See Section 4.5.4, “mysqldump — A Database Backup Program”, and Section 4.6.9, “mysqlhotcopy — A Database Backup Program”.

    

Answer 3

usando o svn ocuparia uma quantidade enorme de espaço.

digamos que você envia um arquivo de 100MB e o svn se torna a versão 1 então se você adicionar um novo arquivo de 200mb, a versão será 2.

Seu repositório svn terá 300mb.

se você quiser o seu arquivo na versão 1, você teria que svn co-r 1 svnrepourl

    

Answer 4

Eu sei que esta pergunta é um pouco datada, mas na minha empresa estamos experimentando algo semelhante. Temos puxado backups formatados em xml (não do MySQL, mas ainda simplesmente arquivos de texto) que têm ~ 300 MB de tamanho e são enviados para um repositório SVN, todas as noites por pouco mais de uma semana. O primeiro commit colocou o repositório em 41 MB, mas cada commit desde então foi menor. Estamos agora na revisão 8 e o tamanho total do repositório é de 57 MB. Isso é cerca de 2,5% do tamanho de todo o histórico que ele contém!

Acabei de experimentar o rdiff-backup usando os mesmos dados; abaixo está uma comparação (todos os tamanhos em MB):

Backup #    Backup Size    repo size    delta    rdiff size    delta
0           0              0.03         0.03     0             0
1           286.05         41.49        41.46    286.05        286.05
2           285.93         45.97        4.49     322.13        36.08
3           286.23         50.52        4.54     323.27        1.14
4           286.63         50.79        0.27     324.54        1.26
5           287.46         55.52        4.73     326.54        2.00
6           287.76         55.77        0.25     327.72        1.19
7           288.15         56.14        0.37     328.98        1.26
8           288.41         56.63        0.50     330.36        1.38

Parece que os deltas são praticamente os mesmos (às vezes o svn é melhor, às vezes o rdiff-backup é), então no tamanho geral, o SVN ganha. Uma vantagem do rdiff é que é fácil remover backups antigos, onde com o SVN você teria que fazer um svnadmin dump e svnadmin load para se livrar de revisões antigas . Eu acho que é uma questão de preferência, mas o SVN é fácil de usar e tem uma tonelada de ferramentas para suportá-lo.

    

Answer 5

Confira este script que automatiza o processo, permitindo a seleção específica de bancos de dados e a exclusão de tabelas [disclaimer eu sou o autor] - link

    

Answer 6

O Percona XtraBackup suporta backups quentes incrementais de bancos de dados MySQL.