Despejando RAPIDAMENTE um banco de dados desativado:
Usar a opção "-T" com mysqldump resulta em muitos arquivos .sql e .txt no diretório especificado. Isso é ~50% mais rápido para despejar tabelas grandes do que um único arquivo .sql com instruções INSERT (leva 1/3 a menos do tempo do relógio de parede).
Além disso, há um grande benefício ao restaurar se você puder carregar várias tabelas em paralelo e saturar vários núcleos. Em uma caixa de 8 núcleos, isso pode ser uma diferença de até 8X no tempo do relógio de parede para restaurar o despejo, além das melhorias de eficiência fornecidas por "-T". Como "-T" faz com que cada tabela seja armazenada em um arquivo separado, carregá-las em paralelo é mais fácil do que dividir um arquivo .sql enorme.
Levando as estratégias acima ao seu extremo lógico, pode-se criar um script para despejar um banco de dados amplamente em paralelo. Bem, é exatamente isso que o Maakit mk-parallel-dump (veja http:/ /www.maatkit.org/doc/mk-parallel-dump.html ) e as ferramentas mk-parallel-restore são; scripts perl que fazem várias chamadas para o programa mysqldump subjacente. No entanto, quando tentei usá-los, tive problemas para concluir a restauração sem erros de chave duplicada que não ocorreram com despejos de baunilha, portanto, lembre-se de que sua milhagem pode variar.
Dumping de dados de um banco de dados LIVE (sem interrupção do serviço):
A opção --single-transaction é muito útil para fazer um dump de um banco de dados ativo sem ter que desativá-lo ou fazer um dump de um banco de dados escravo sem ter que parar o slave.
Infelizmente, -T não é compatível com --single-transaction, então você só tem um.
Normalmente, fazer o dump é muito mais rápido do que restaurá-lo. Ainda há espaço para uma ferramenta que pegue o arquivo de despejo monolítico de entrada e o divida em várias partes para serem carregadas em paralelo. Que eu saiba, tal ferramenta ainda não existe.
Transferir o dump pela rede geralmente é uma vitória
Para escutar um dump de entrada em um host, execute:
nc -l 7878 > mysql-dump.sql
Em seguida, em seu host de banco de dados, execute
mysqldump $OPTS | nc myhost.mydomain.com 7878
Isso reduz a contenção para que os eixos de disco no mestre gravem o despejo em disco, acelerando um pouco o despejo (supondo que a rede seja rápida o suficiente para acompanhar, uma suposição bastante segura para dois hosts no mesmo datacenter). Além disso, se você estiver construindo um novo escravo, isso economiza a etapa de transferir o arquivo de despejo após a conclusão.
Advertências - obviamente, você precisa ter largura de banda de rede suficiente para não desacelerar insuportavelmente, e se a sessão TCP quebrar, você terá que começar tudo de novo, mas para a maioria dos despejos isso não é uma grande preocupação.
Por último, quero esclarecer um ponto de confusão comum.
Apesar da frequência com que você vê esses sinalizadores nos exemplos e tutoriais do mysqldump, eles são supérfluos porque são ativados por padrão:
--opt--add-drop-table--add-locks--create-options--disable-keys--extended-insert--lock-tables--quick--set-charset.
De http://dev.mysql.com/doc/refman/ 5.1/pt/mysqldump.html :
Desses comportamentos, "--quick" é um dos mais importantes (ignora o cache de todo o conjunto de resultados no mysqld antes de transmitir a primeira linha), e pode ser com "mysql" (que NÃO liga --quick por padrão) para acelerar drasticamente as consultas que retornam um grande conjunto de resultados (por exemplo, despejando todas as linhas de uma tabela grande).
