Arquivo

Archive for fevereiro \21\UTC 2012

XtraBackup: backup no MySQL “no quente”, sem read lock

fevereiro 21, 2012 6 comentários

O MySQL tem um utilitário muito utilizado para backups, sendo bastante versátil para bases pequenas, que é o mysqldump. Mas quando se tem uma base grande e de alta criticidade, ou seja, não pode parar de maneira alguma, aí aparecem os problemas com o utilitário mysqldump. Podemos contar alguns de seus principais problemas:

  • Lento para fazer backup de grandes bases;
  • Lento para efetuar restore, principalmente quando se usa InnoDB;
  • O conteúdo do backup, como o próprio nome da ferramenta sugere, é um DUMP, é todo em texto ASCII, o que o torna inseguro e pesado, já que a leitura e gravação de dados em ASCII é bem mais lenta do que em binários;
  • E o principal: trava as tabelas durante o backup, tornando partes do banco temporariamente indisponíveis.

Existe uma ferramenta paga, conhecida como MySQL Enterprise Backup, que realiza os backups “no quente”, sem travamentos e garante sua consistência. O grande problema, é que essa ferramenta é paga e cara, nem todo mundo está disposto a pagar.

Mas, para a felicidade de todos, existe um clone Open Source do MySQL Enterprise Backup chamado de XtraBackup desenvolvido pela Percona, uma empresa especializada em consultoria  de banco de dados MySQL. O mesmo está disponível para uma variedade de distribuições Linux, bastando acessar o site do produto para obter informações de instalação.

Neste artigo não irei abordar a instalação do produto, pois a mesma pode variar de acordo com sua plataforma.

Mãos à Obra

Uma vez instalado, tomaremos como base o comando abaixo para a realização do backup:

# innobackupex –stream=tar –defaults-file=/etc/my.cnf –user=usuario –password=senha ./ | gzip -c -9 > $BDIR/backup.`date +%m%d%Y%H%M%S`.tar.gz

Agora aguarde o resultado, se tudo ocorrer bem, seu backup será executado como previsto.

Abaixo, um pequeno script para ajudar a automatizar as coisas, podendo ser inclusive agendado no crontab para sua execução automática:

#!/bin/bash

# 19022012 – Written by Ramon Gadelha
# This script uses xtrabackup utility to hot backup mysql databases in a non-halt mode

BDIR=”/home/backup/mysql”
USER=”xtrabackup”
PASSWORD=”xtrabackup”
CONFIG=”/etc/my.cnf” 

# Run backup

innobackupex –stream=tar –defaults-file=$CONFIG –user=$USER –password=$PASSWORD ./ | gzip -c -9 > $BDIR/backup.`date +%m%d%Y%H%M%S`.tar.gz

# Remove backups older than 7 days
find $BDIR -name backup.\* -ctime +7 -exec rm {} \;

Espero que esse artigo tenha lhe sido útil.

Anúncios
Categorias:Uncategorized

Migração de grande quantidade de dados em storage bloco-a-bloco de forma rápida com Linux e DD

fevereiro 12, 2012 Deixe um comentário

Salve, após um certo tempo de hiato, estou de volta para postar coisas interessantes e úteis (no meu ponto de vista) para quem se interessar.

Migração de grandes quantidades de dados pode ser algo cansativo e traumático dependendo das condições e prazos que se tenha para fazê-la. Num senário como este, nem sempre se dispõe de soluções apropriadas para tal tipo de tarefa, então torna-se necessário improvisar de maneira coesa e simples. Passei por uma situação parecida tempos atrás e pensando nisso, peguei parte da documentação que criei para tais procedimentos e preparei esse pequeno e simples artigo, do qual espero que lhe seja útil.

O Cenário

A sua estrutura dispõe de dois storages, um que já está em produção, e outro novo, que irá substituir o atual e você tem apenas parte do final de semana para migrar aproximadamente 4TB de dados de um para o outro.

Equipamentos envolvidos:

2 Storages;
1 Servidor com duas HBA FC a 8gbit/s;
2 Pares de fibra ligando cada HBA do servidor a dos storages a 8gbit/s.

Software:

Linux (o cara!);
DD (o salvador!);
iostat (para monitorar a entrada e saída de dados).

Aprovisionamento

Primeiro deve-se provisionar o novo storage, de acordo com o antigo, mesma quantidade de LUNs e tamanhos, quanto mais identicos eles forem entre si, mais fácil será identificá-los no Linux.

Estratégia

A estratégia a ser utilizada, vai ser apresentar LUN a LUN. Por exemplo, no storage atual, existe a LUN VMW_R5_DADOS, então apresentamos a LUN ao Linux, e verificamos com o comando ‘fdisk -l’. O mesmo irá mostrar o novo dispositivo (que é a LUN do storage atual) e suas partições. Nesse exemplo, o dispositivo será o /dev/hdb. Logo após, repita o mesmo passo no storage de destino, e agora o comando ‘fdisk -l’ irá listar os dois storages, vamos assumir para este artigo que o dispositivo de destino será /dev/hdc.

Plano de ação

Após apresentar as LUNs pro host, podemos iniciar o trabalho:

dd if=/dev/hdb of=/dev/hdc

Observe que a migração começou, mas está indo de forma bastante lenta. Por que? O DD migra dados por padrão em blocos de 512 bytes, para alguns dispositivos comuns, essa velocidade é o bastante, mas como estamos falando de dispositivos de Enterprise Level, com HDs SAS 15K RPM e FC a 8Gbit/s podemos “esticar” um pouco, e colocá-lo para migrar em blocos de 8 a 16k.

dd if=/dev/hdb of=/dev/hdc bs=8k

Após isso, devemos observar a taxa de I/O com o comando ‘iostat’, caso seja satisfatória, podemos deixar como estar, ou ir incrementando até 16k, que é um nível que não causa muito enfileiramento nessa velocidade. No caso, eu consegui copiar cerca de 1TB a cada 1h. O DD simplesmente copia, ele não sabe o que é filesystem ou arquivos, sua cópia é totalmente baixo nível, com acesso direto aos dispositivos.

Atenção: quanto maior o block size, mais memória RAM consumirá do host. Se seu host tem acima de 16GB de RAM, pode ficar despreocupado, caso contrário, é recomendável monitorar para ficar entre o ideal e o responsável.

Vale observar que: o ‘dd’ não faz tarefas de compressão de dados, muito menos checagem de erros de I/O, então tome o cuidado de fazer backup antes e verificar a consistência dos dados após cada migração.

Categorias:Uncategorized