Backups incrementais e replicação de banco de dados MySQL

1

Temos alguns servidores que executam um aplicativo do tomcat com um banco de dados MySQL. Esses servidores estão em cidades diferentes e o aplicativo da web é usado localmente por nossos clientes.

Nesses servidores, um trabalho do crontab é executado duas vezes por dia e faz um backup completo dos bancos de dados e envia (SCP) esse despejo para o servidor da nossa central. Em seguida, pegamos esses lixões e aplicamos a um banco de dados local, para que, caso ocorra uma emergência, nossos clientes possam continuar usando o aplicativo pela Internet.

O problema é que todos os dias os dumps estão ficando maiores e a transferência dessa quantidade de dados não é simples, então estamos procurando por algumas soluções de backups incrementais e um método de replicação com este incremental.

Você pode dar algumas idéias sobre como fazer isso? Existe outra solução melhor do que o que queremos fazer?

Obrigado.

    
por Juan 07.01.2012 / 02:50

3 respostas

4

Mantenha o despejo anterior e use rsync ou até melhor, rdiff-backup ( link ) por meio do ssh de simples scp.

    
por 07.01.2012 / 02:55
4

Outra opção além de usar o rsync é configurar a replicação do mysql com cada um dos bancos de dados normais como mestres, e os do seu escritório como um escravo para cada mestre. Você pode ler a documentação do mysql aqui. . Se você quiser manter o backup do estilo scp / rsync, talvez seja possível adicionar compactação ao backup com bzip ou outro método. Há também zmanda que permitirá backups sem a necessidade de executar um escravo para cada sistema que você deseja fazer backup.

    
por 07.01.2012 / 03:09
2

Outra possível opção é usar o log binário, mas não qualquer replicação real, pelas razões que o syneticon-dj listou. Mantenha alguns dias de registros binários (eles podem ser grandes) e use a ferramenta mysqlbinlog para obter períodos de tempo específicos e para reproduzir as alterações no servidor central durante o dia.

Existem algumas limitações de desempenho e outras, como transações, mas podem funcionar para sua configuração. Você também terá uma boa trilha de auditoria para ver exatamente quando uma menção "DELETE FROM", como syneticon-dj, aconteceu e pode removê-la do seu replay, encontrar a pessoa responsável, etc.

Você obviamente deseja manter os backups completos, mas se sua preocupação é manter a central atualizada, uma sincronização de backup completa noturna w / binary entre provavelmente seria a menos intensiva, e você ainda pode usar o rdiff-backup do S19N recomendação para o noturno.

    
por 09.01.2012 / 16:29