Início / dba / Perguntas / 7785
Accepted
Cerin
Asked: 2011-11-12 15:12:05 +0800 CST

mysqldump incompleto

  • 772

Estou tentando executar o mysqldump para criar um instantâneo do banco de dados e descobri que ele irá parar aleatoriamente no meio do caminho, sem relatar nenhum erro. Meu banco de dados é relativamente pequeno (cerca de 100 MB) e está usando o InnoDB.

Estou executando assim:

mysqldump --force --single-transaction --quick --user myuser --password=mypass -h mydatabasehost mydb > /tmp/snapshot.sql

Verificar os relatórios de código de saída 0.

Minha versão é: mysqldump Ver 10.13 Distrib 5.1.52, para redhat-linux-gnu (i386)

Eu vi algumas postagens semelhantes e até um relatório de bug oficial , mas nenhuma das soluções parece se aplicar.

Como faço para que o mysqldump tire um instantâneo completo do banco de dados?

EDIT: Meu banco de dados atualmente reside no RDS da Amazon.

mysql backup

5 respostas

  1. Best Answer

    Pode ter sido um problema max_allowed_packetnão ter sido definido alto o suficiente no cliente (ou seja, mysqldump) e no servidor (ou seja, Amazon RDS). Eu configurei isso para 500M em ambos e isso parece ter resolvido o problema.

    Como as tabelas de esquema de informações do InnoDB fornecem apenas estimativas de contagem de linhas, é difícil dizer se meu instantâneo realmente inclui tudo do RDS. Todas as tabelas estão lá, mas as contagens de linhas são diferentes. Atualizarei com uma resposta mais definitiva quando tiver algum tempo para escrever uma análise mais completa.

    • 6

  2. Você tentou?

    mysqldump --compress --add-drop-table data --routines --events  --comments --extended-insert -h {host} -u {user} -p {database} > dbdump.sql

    Isso é simples do jeito que eu sempre faço sem problemas. Basicamente, fazendo o dump dessa forma, você obtém tudo o que possui (dados, objetos e às vezes comentários preciosos) em um determinado momento, ignorando as transações não confirmadas.

    • 4

  3. Pelo que entendi, o mysql docs --single-transaction falhará se uma leitura for executada na tabela enquanto você estiver despejando. Qual é o resultado ao executar sem "--force --single-transaction --quick"?

    • 1

  4. É inteiramente possível que a tabela esteja corrompida. Não quero dizer que os dados e/ou páginas de índice estejam danificados. Pode haver algo muito simples que está quebrado.

    Recentemente, experimentei um problema com um script de backup em um Servidor Escravo quando eu paralelo mysqldump vários bancos de dados. Executar mysqldump em um dos bancos de dados resultou em um mysqldump muito pequeno. O banco de dados tinha mais de 80 tabelas. No entanto, o mysqldump parou na quinta tabela no banco de dados. Quando eu rodava SHOW CREATE TABLE tblname\Gna mesa no Slave, dava o erro "Table Not Found". Quando executei SHOW CREATE TABLE tblname\Gno Master, a descrição da tabela foi exibida conforme o esperado.

    O que aconteceu foi meio maluco: um cliente pediu a restauração da tabela e um engenheiro restaurou o arquivo .ibd da tabela InnoDB a partir de um backup em disco. O id do tablespace do arquivo .ibd (que era 25) não correspondia ao id do tablespace registrado em ibdata1 (que era 28).

    Corrigi o problema hospedando o escravo, mysqldumping o mestre e configurando a replicação do zero. Felizmente, o spave de dados e índice totalizou 7 GB. Portanto, o processo rstore não era grande coisa.

    MORAL DA HISTÓRIA

    O problema básico é que o mysqldump não reporta um erro em um InnoDB quando o id do tablespace está incorreto. Quando um mysqldump termina e não despeja todas as tabelas em ordem alfabética, isso indica que ele foi encerrado por um erro e o fez sem imprimir uma mensagem de erro.

    Verifique para ter certeza

    • você pode exibir a estrutura da tabela usandoSHOW CREATE TABLE
    • você pode consultar tudo sobre uma tabela de INFORMAÇÃO_SCHEMA.TABLES
    • 1

  5. O seguinte é apenas um brainstorming sobre mysqldump e InnoDB:

    Por favor, pense sobre o comportamento do mysqldump em relação a uma tabela InnoDB. Se houver alguma página suja no InnoDB Buffer Pool pertencente a uma tabela que você está descarregando, as páginas sujas dessa tabela devem ser descarregadas no disco antes que um SELECT /* SQL_NO_CACHE */possa ser executado nela.

    Como você está usando o Amazon RDS, meu pressentimento é que seu banco de dados está em uma infraestrutura multitenant (sinta-se à vontade para corrigir esta afirmação se eu estiver simplificando demais). Outros bancos de dados podem estar usando um InnoDB Buffer Pool compartilhado, um arquivo de metadados compartilhado (ibdata1) e um tablespace compartilhado (ibdata1 se innodb_file_per_table estiver desabilitado).

    Também pode haver alguma redundância do banco de dados, o que pode afetar o MVCC no banco de dados, mesmo que seja um conjunto de dados pequeno.

    Você pode querer aumentar innodb_lock_wait_timeout (padrão 50 segundos) em sua sessão mysqldump para ver se isso tem algum efeito no Amazon RDS (ou fazer com que a Amazon aumente esse limite). Além disso, tente fazer o dump de tabelas individuais.

    ATUALIZAÇÃO 2011-11-14 17:58 EDT

    Tente executar isso em sua sessão de banco de dados (defina para dois minutos):

    SET innodb_lock_wait_timeout = 120;
    • 0

relate perguntas