Mysqldump incompleto

Estou tentando executar o mysqldump para criar um instantâneo de banco de dados e estou descobrindo 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 como:

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

Verificando o código de saída informa 0.

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

Vi algumas postagens semelhantes e até um relatório oficial de erros , mas nenhuma solução parece se aplicar.

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

EDIT: Atualmente, meu banco de dados reside no RDS da Amazon.

Pode ter sido um problema max_allowed_packetnão ter sido definido alto o suficiente no cliente (por exemplo, mysqldump) e no servidor (por exemplo, Amazon RDS). Defino isso para 500M em ambos e isso parece ter corrigido o problema.

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

Você tentou?

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

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

Tanto quanto eu entendo os documentos do mysql - Única transação falhará se uma leitura for executada na tabela enquanto você estiver despejando. Qual é o resultado ao executar sem "--force - única transação - rápida"?

É perfeitamente 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 paralelo ao mysqldumped vários bancos de dados. A execução do 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 corri SHOW CREATE TABLE tblname\Gsobre a mesa no escravo, recebi o erro "Tabela não encontrada". Quando eu corri SHOW CREATE TABLE tblname\Gno Master, a descrição da tabela é exibida conforme o esperado.

O que aconteceu foi um pouco louco: um cliente solicitou uma restauração da tabela e um engenheiro restaurou o arquivo .ibd da tabela InnoDB a partir de um backup em disco. O ID do espaço de tabela do arquivo .ibd (que era 25) não correspondia ao ID do espaço de tabela registrado no ibdata1 (que era 28).

Corrigi o problema com a mangueira do escravo, o mysqldumping o mestre e a configuração da replicação do zero. Felizmente, os dados e o índice totalizaram 7 GB. Portanto, o processo rstore não era grande coisa.

MORAL DA HISTÓRIA

O problema básico é que o mysqldump não relata um erro no InnoDB quando o ID do espaço de tabela está incorreto. Quando um mysqldump termina e não despeja todas as tabelas em ordem alfabética, isso indica que ele terminou com um erro e o fez sem imprimir uma mensagem de erro.

Verifique para ter certeza

• você pode exibir a estrutura da tabela usando SHOW CREATE TABLE
• você pode consultar tudo sobre uma tabela em INFORMATION_SCHEMA.TABLES

A seguir, são apresentados alguns brainstorming no mysqldump e InnoDB:

Por favor, pense sobre o comportamento do mysqldump em uma tabela do InnoDB. Se houver páginas sujas no InnoDB Buffer Pool pertencentes a uma tabela que você está descartando, as páginas sujas dessa tabela deverão ser liberadas para o disco antes que uma SELECT /* SQL_NO_CACHE */possa ser executada.

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 declaração, se eu estiver simplificando demais). Outros bancos de dados podem estar usando um InnoDB Buffer Pool compartilhado, um arquivo de metadados compartilhados (ibdata1) e um espaço de tabela compartilhado (ibdata1 se innodb_file_per_table estiver desativado).

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

Você pode aumentar innodb_lock_wait_timeout (padrão 50 segundos) na sua sessão mysqldump para ver se isso tem algum efeito no Amazon RDS (ou a Amazon aumenta esse limite). Além disso, experimente despejar tabelas individuais.

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

Tente executar isso dentro da sua sessão de banco de dados (define para dois minutos):

SET innodb_lock_wait_timeout = 120;