Como despejar eficientemente um enorme banco de dados MySQL innodb?

Eu tenho um servidor de banco de dados MySQL de produção Ubuntu 10.04, onde o tamanho total do banco de dados é de 260 GB, enquanto o tamanho da partição raiz é de 300 GB onde o banco de dados é armazenado, basicamente significa que cerca de 96% de / está cheio e não há espaço para armazenar dump / backup etc. Nenhum outro disco está conectado ao servidor a partir de agora.

Minha tarefa é migrar esse banco de dados para outro servidor em outro datacenter. A questão é como fazer isso de forma eficiente com o mínimo de inatividade?

Estou pensando na linha de:

• Solicite anexar uma unidade extra ao servidor e faça um despejo nessa unidade. [EDIT: não é possível agora.]
• Transfira o dump para o novo servidor, restaure-o e torne o novo servidor escravo do existente para manter os dados sincronizados
• Quando a migração for necessária, interrompa a replicação, atualize a configuração do slave para aceitar solicitações de leitura / gravação e torne o servidor antigo somente leitura, para que não receba nenhuma solicitação de gravação e peça aos desenvolvedores de aplicativos que atualizem a configuração com o novo endereço IP para db.

Quais são as suas sugestões para melhorar essa ou qualquer outra abordagem alternativa melhor para esta tarefa?

Se você está pensando em migrar para outro DB Server com exatamente a mesma versão do MySQL, você pode querer rsynca datadirpartir do servidor antigo para o novo servidor.

Isso funcionará independentemente do layout do arquivo InnoDB ou mesmo da presença de tabelas MyISAM.

1. instale a mesma versão do mysql no ServerB que o ServerA possui
2. No ServerA, execute RESET MASTER;para apagar todos os logs binários antes do processo rsycn. Se o log binário não estiver ativado, você poderá pular esta etapa.
3. No ServerA, execute a SET GLOBAL innodb_max_dirty_pages_pct = 0;partir do mysql e aproximadamente 10 minutos (Isso remove páginas sujas do InnoDB Buffer Pool. Também ajuda a executar um desligamento do mysql mais rapidamente) Se o seu banco de dados for todo o MyISAM, você poderá pular esta etapa.
4. rsync / var / lib / mysql do ServerA para / var / lib / mysql no ServerB
5. Repita a Etapa 3 até que um rsync leve menos de 1 minuto
6. service mysql stop no ServerA
7. Execute mais um rsync
8. scp ServerA: /etc/my.cnf para ServerB: / etc /.
9. service mysql start no ServerB
10. service mysql start no ServerA (opcional)

Basicamente, aqui está o que esse script gostaria

mysql -u... -p... -e"RESET MASTER;"
mysql -u... -p... -e"SET GLOBAL innodb_max_dirty_pages_pct = 0;"
RSYNCSTOTRY=10
cd /var/lib/mysql
X=0
while [ ${X} -lt ${RSYNCSTOTRY} ]
do
    X=`echo ${X}+1|bc`
    rsync -r * targetserver:/var/lib/mysql/.
    sleep 60
done
service mysql stop
rsync -r * targetserver:/var/lib/mysql/.
service mysql start

Um membro do DBA StackExchange disse que eu deveria me afastar com FLUSH TABLES WITH READ LOCK;base em algo no mysqlperformanceblog.com

Eu li e aprendi que os SELECTs nas tabelas do InnoDB no meio de um FLUSH TABLES WITH READ LOCK;ainda podem permitir que as gravações ocorram de alguma maneira. Como apontado no comentário de Arlukin , o LVM trabalharia FLUSH TABLES WITH READ LOCKmuito bem no InnoDB (+1 no seu comentário).

• http://www.mysqlperformanceblog.com/2012/03/23/how-flush-tables-with-read-lock-works-with-innodb-tables/
• http://forums.mysql.com/read.php?22,184590,184610

Para todos os usuários que não são LVM, você concorda com um banco de dados all-MyISAM FLUSH TABLES WITH READ LOCK;. Para o InnoDB, --single-tranactionuse o mysqldumps, por favor.

Um despejo e restauração de um banco de dados desse tamanho levaria horas. Dependendo das versões do mysql, desde que o número da versão aumente e não haja saltos no número da revisão principal. Você deve poder pegar os arquivos de banco de dados brutos em / var / lib / mysql e colocá-los no novo servidor, definir as permissões e iniciar o servidor com a opção --skip-grant-tables. Adicione as concessões necessárias para os usuários que refletem o novo endereço IP e reinicie normalmente.

Eu abordaria o tamanho do seu banco de dados, pois ele é grande demais para ser eficiente.

Você pode seguir estas etapas para migrar esse enorme banco de dados do InnoDB.

• Instale o SSHFS e monte a partição relevante do servidor remoto no servidor de produção
• Use o Percona XtraBackup para obter um hotcopy do banco de dados InnoDB e salvá-lo diretamente no diretório montado SSHFS

• Esta tarefa levará várias horas. Para minimizar o efeito do script hotcopy no servidor ativo, defina baixa prioridade usando renice

  $ renice -n 5 -p <SCRIPT-PID>

• Verifique se os dois servidores estão executando a mesma versão do servidor MySQL.
• Depois que o hotcopy estiver concluído, você poderá restaurá-lo no novo servidor, iniciar o processo de replicação

Você pode experimentar lentidão durante esse processo, mas definitivamente sem tempo de inatividade. O Percona XtraBackup criará um hotcopy que é mais rápido e consome menos recursos em comparação com o mysqldump. Isso é ideal para um enorme banco de dados InnoDB.

Dependendo dos padrões e estatísticas de uso, você pode executar esse processo quando houver tráfego mínimo no servidor. Talvez fazer isso no fim de semana seja uma boa ideia? O exposto acima é apenas um esboço do processo. Pode ser necessário consultar a documentação do Percona XtraBackup e SSHFS.

Você pode simplesmente despejar o banco de dados diretamente no servidor remoto ...

$ mysqldump | ssh user@server 'cat - > dumpfile.sql.gz'

... O SQL deve compactar bem, portanto, você deve fazer isso muito mais rapidamente com uma dessas opções, embora também dependa da quantidade de RAM que você possui na caixa ...

$ mysqldump | ssh -C user@server 'cat - > dumpfile.sql.gz'
$ mysqldump | gzip -c | ssh user@server 'cat - > dumpfile.sql.gz'