Fazendo backup de um banco de dados MySQL de 22 GB diariamente

No momento, sou capaz de fazer o backup usando o mysqldump. Mas eu tenho que derrubar o servidor web e leva cerca de 5 minutos para fazer o backup. Se eu não derrubar o servidor da Web, levará uma eternidade e nunca terminará + o site ficará inacessível durante o backup.

Existe uma maneira mais rápida / melhor de fazer backup dos meus 22 GB e aumentar o banco de dados?

Todas as tabelas são MyISAM.

Sim.

Configure a replicação para uma segunda máquina. Quando você precisar fazer um backup, poderá bloquear a máquina secundária, executar mysqlhotcopy ou mysqldump e desbloqueá-la. Ele alcançará seu mestre e você nunca precisará colocá-lo offline.

Você pode até fazer isso na mesma máquina, se não se importar em duplicar a E / S de gravação, mas o ideal é fazer backup em tempo real para um segundo servidor físico e fazer os backups de captura instantânea sempre que necessário sem perturbar o servidor de produção.

Também é teoricamente possível restaurar um banco de dados usando um estado conhecido e binlogs. Eu nunca fiz isso; portanto, investigue primeiro, mas você pode fazer backup de um estado conhecido do seu banco de dados, depois apenas fazer backup de todos os novos binlogs e reproduzi-los se precisar restaurar. Como os binlogs são gravados linearmente, a sincronização de novos binlogs em um computador remoto seria muito rápida.

Edit: De fato, parece que o uso de binlogs para backup está documentado.

Esta questão está altamente relacionada

Perdoe-me por assumir que o sistema operacional é Linux. Se você não estiver usando LVM, você deveria estar. Se você estiver, aqui está uma maneira muito simples de fazer backups via instantâneo.

# Define these vars to meet your needs. These meet mine.
lvol="/dev/VolGroup03/lvol0"
snap_name="nightly_snapshot"
snap_vol="$(dirname $lvol)/$snap_name"
snap_path="/mnt/$snap_name"
snap_size="10g" # Not the size of your data, anticipated data changes during the backup
backup_path="/backups/$snap_name"

/usr/bin/time -f 'Databases were locked for %E' -- \
mysql <<- MYSQL
# based on http://pointyhair.com/tiki-view_blog_post.php?blogId=1&postId=5
FLUSH TABLES WITH READ LOCK;
\! lvcreate --size $snap_size --snapshot --name $snap_name $lvol
UNLOCK TABLES;
MYSQL
mount $snap_vol $snap_path
rsync -av --delete $snap_path/mysql $backup_path/
umount $snap_path
lvremove -f $snap_vol

Isso permitirá que você faça backups noturnos sem precisar adicionar um servidor escravo. Sou a favor de ter um servidor escravo para alta disponibilidade, mas não quero que você pense que está preso até poder criar esse escravo.

TABELAS DE LAVAGEM COM BLOQUEIO DE LEITURA não é algo que você deseja fazer regularmente (ou mesmo semi-regularmente) em um sistema de produção. Deve ser apenas um último recurso.

Configure pelo menos dois escravos de replicação (isso exigirá um FLUSH TABLES WITH READ LOCK, é claro). Depois de configurados, você pode fazer um backup de um enquanto o outro permanece sincronizado como mestre sobressalente.

Além disso, se um de seus escravos falhar, você poderá usar um instantâneo para reconstruir um segundo (ou terceiro) escravo. Se todos os seus escravos falharem, você estará de volta a FLUSH TABLES WITH READ LOCK.

Lembre-se de sempre ter um processo que verifique regularmente se os dados estão sincronizados - use algo como mk-table-checksum para fazer isso (isso não é trivial de configurar, consulte a documentação do Maatkit para obter detalhes).

Como 22 GB é relativamente pequeno, você não terá problemas para fazer isso. Fazer isso com um banco de dados grande pode ser mais problemático.

A solução aqui é dupla, como descrito acima:

1. Configure a replicação do seu servidor para um escravo que você pode colocar offline. A melhor maneira de fazer isso é despejar o banco de dados usando o mysqldump e o parâmetro --master-data.
2. Configure backups noturnos no escravo. Você pode usar o mysqldump com os sinalizadores --master-data --flush-logs e --single-transaction, ou pode parar o servidor mysql, copiar os arquivos de dados no disco e reiniciá-lo (a replicação continuará onde parou).
3. Execute um script no escravo a cada (por exemplo, 5, 10, 20 minutos) para verificar e garantir que o mysql ainda esteja se replicando. Eu escrevi um script python simples para fazer isso, que você pode usar.

Observe que, se você estiver usando o InnoDB para suas tabelas, poderá usar o sinalizador --single-transaction para evitar a necessidade de bloquear qualquer tabela e ainda obter um despejo consistente do banco de dados, mesmo no mestre, e assim fazer seus backups sem derrubando o servidor. A solução acima, no entanto, é melhor.

Além disso, se você estiver usando o LVM no Linux, poderá tirar um instantâneo do LVM da partição e fazer o backup. Os snapshots do LVM são atômicos, portanto, se você 'esvaziar tabelas com bloqueio de leitura' e, em seguida, tirar o snapshot e desbloquear, obterá um snapshot consistente.

Se você está preocupado com a contenção de E / S que faz com que o despejo demore muito, você pode adicionar uma terceira máquina e executar o mysqldump na rede para evitar que seus discos sejam danificados.

Dependendo do seu ambiente, os instantâneos geralmente são um excelente caminho a percorrer. Especialmente se você precisar fazer backup do mestre por algum motivo. Executamos pares mestre e escravo e usamos backups de captura instantânea em ambos.

1. FLUSH TABLES WITH READ LOCK;
2. Puxe uma captura instantânea no banco de dados e registre os sistemas de arquivos.
3. UNLOCK TABLES;
4. Copie seus arquivos de dados do instantâneo à vontade.

Com as tabelas do InnoDB, você desejará executar SET AUTOCOMMIT=0;antes de executar o bloqueio de leitura.

Veja " Práticas recomendadas para fazer backup de um banco de dados MySQL de produção? ". É um post semelhante no Stack Overflow.

Você pode fazer um backup gradual. Faça backup de 1/24 dos registros a cada hora. O único problema com essa abordagem é que, se ocorrer uma falha durante as primeiras horas do dia, você perderá algo desse momento até a hora da falha. De qualquer forma, são menos de 24 horas de registros perdidos (não sei o quanto isso é importante para você).