Início / dba / Perguntas / 43503
Accepted
Petr
Asked: 2013-06-01 00:15:16 +0800 CST

`ERRO 1114 (HY000) a tabela ... está cheia` com innodb_file_per_table definido como autoextend

  • 772

Eu tenho um banco de dados MySQL que contém uma grande quantidade de dados (100-200 GB - um monte de medições científicas). A grande maioria dos dados é armazenada em uma tabela Sample. Agora estou criando uma réplica escrava do banco de dados e queria aproveitar as vantagens innodb_file_per_tabledurante o processo. Então configurei innodb_file_per_tablena minha configuração slave e importei o dump do banco de dados. Para minha surpresa, falhou com

ERRO 1114 (HY000) na linha 5602: A tabela 'Sample' está cheia

Atualmente, o arquivo Sample.ibdtem cerca de 93 GB, com mais de 600 GB de espaço livre disponível na partição, portanto, não é um problema de espaço livre em disco. Nem parece estar atingindo qualquer tipo de limite do sistema de arquivos (estou usando ext4).

Eu ficaria grato por qualquer idéia do que poderia ser a causa, ou o que investigar.

Atualização: estou usando mysql Ver 14.14 Distrib 5.1.66, for debian-linux-gnu (x86_64).

SELECT @@datadir; -- returns `/home/var/lib/mysql/`
SHOW VARIABLES LIKE '%innodb_data_file_path%'; -- ibdata1:10M:autoextend 

df -h /home/var/lib/mysql/
768G   31G  699G   5% /home
mysql innodb

2 respostas

  1. Best Answer

    FATOS

    Você disse que está usando ext4. O limite de tamanho do arquivo é 16 TB. Assim, Sample.ibdnão deve ser cheio.

    Você disse que o seu innodb_data_file_pathé ibdata1:10M:autoextend. Assim, o próprio arquivo ibdata1 não tem limite de tamanho, exceto do sistema operacional.

    Por que esta mensagem está chegando? Observe que a mensagem é "A tabela ... está cheia", não "O disco ... está cheio". Esta condição de tabela cheia é do ponto de vista lógico . Pense no InnoDB. Que interações estão acontecendo?

    Meu palpite é que o InnoDB está tentando carregar 93 GB de dados como uma única transação. De onde Table is Fullemanaria a mensagem? Eu olharia para o ibdata1, não em termos de seu tamanho físico (que você já descartou), mas em termos de quais limites de transação estão sendo atingidos.

    O que está dentro de ibdata1 quando innodb_file_per_table está habilitado e você carrega novos dados no MySQL?

    • Dicionário de dados
    • Buffer de gravação dupla
      • Rede de segurança para prevenir a corrupção de dados
      • Ajuda a ignorar o SO para armazenamento em cache
    • Inserir Buffer (Simplifica as Alterações nos Índices Secundários)
    • Segmentos de reversão
    • Desfazer registros
    • Clique aqui para ver uma representação pictórica deibdata1

    Minhas suspeitas me dizem que os Undo Logs e/ou Redo Logs são os culpados.

    O que são esses registros? De acordo com o livro

    sxs

    Capítulo 10: "Motores de armazenamento" Página 203 Os parágrafos 3,4 dizem o seguinte:

    O mecanismo InnoDB mantém dois tipos de logs: um log de undo e um log de redo. A finalidade de um log de desfazer é reverter transações, bem como exibir as versões mais antigas dos dados para consultas executadas no nível de isolamento de transação que o exige. O código que trata do log de undo pode ser encontrado em storage/innobase/buf/log/log0log.c .

    O objetivo do redo log é armazenar as informações a serem usadas na recuperação de falhas. Ele permite que o processo de recuperação execute novamente as transações que podem ou não ter sido concluídas antes da falha. Depois de reexecutar essas transações, o banco de dados é levado a um estado consistente. O código que lida com o redo log pode ser encontrado em storage/innobase/log/log0recv.c .

    ANÁLISE

    Existem 1023 logs de desfazer dentro de ibdata1 (consulte Segmentos de reversão e espaço de desfazer) . Como os logs de desfazer mantêm cópias dos dados como eles apareceram antes do recarregamento, todos os 1.023 logs de desfazer atingiram seu limite. De outra perspectiva, todos os 1023 Undo Logs podem ser dedicados à única transação que carrega a Sampletabela.

    MAS ESPERE...

    Você provavelmente está dizendo "Estou carregando uma Sampletabela vazia". Como os logs de desfazer estão envolvidos? Antes de a Sampletabela ser carregada com 93 GB de dados, ela estava vazia. A representação de cada linha que não existia deve ocupar algum espaço de limpeza nos logs de desfazer. Preencher 1.023 logs de desfazer parece trivial, dada a quantidade de dados despejados em arquivos ibdata1. Não sou a primeira pessoa a suspeitar disso:

    Na documentação do MySQL 4.1, observe Posted by Chris Calender on September 4 2009 4:25pm:

    Observe que na versão 5.0 (pré-5.0.85) e na 5.1 (pré-5.1.38), você pode receber o erro "table is full" para uma tabela InnoDB se o InnoDB ficar sem slots de desfazer (bug #18828).

    Aqui está o relatório de bug para MySQL 5.0: http://bugs.mysql.com/bug.php?id=18828

    SUGESTÕES

    Quando você cria o mysqldump da Sampletabela, por favor use --no-autocommit

    mysqldump --no-autocommit ... mydb Sample > Sample.sql

    Isso colocará um explícito COMMIT;após cada arquivo INSERT. Em seguida, recarregue a tabela.

    Se isso não funcionar ( você não vai gostar disso ), faça isso

    mysqldump --no-autocommit --skip-extended-insert ... mydb Sample > Sample.sql

    Isso fará com que cada INSERT tenha apenas uma linha. O mysqldump será muito maior (10+ vezes maior) e pode levar de 10 a 100 vezes mais para recarregar.

    Em ambos os casos, isso evitará que os logs de desfazer sejam inundados.

    De uma chance !!!

    ATUALIZAÇÃO 2013-06-03 13:05 EDT

    SUGESTÃO ADICIONAL

    Se a tabela do sistema InnoDB (também conhecida como ibdata1) atingir um limite de tamanho de arquivo e os logs de desfazer não puderem ser usados, você poderá simplesmente adicionar outro tablespace do sistema (ibdata2).

    Acabei de encontrar esta situação há apenas dois dias. Atualizei meu post antigo com o que fiz: Veja Design de banco de dados - Criando vários bancos de dados para evitar a dor de cabeça do limite no tamanho da tabela

    Em essência, você precisa alterar innodb_data_file_path para acomodar um novo arquivo de tablespace do sistema. Deixe-me explicar como:

    CENÁRIO

    No disco (ext3), o servidor do meu cliente tinha o seguinte:

    [root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql     362807296 Jun  2 00:15 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun  2 00:15 ibdata2

    A configuração foi

    innodb_data_file_path=ibdata1:346M;ibdata2:500M:autoextend:max:10240000M

    Observe que ibdata2cresceu para 2196875759616, que é 2145386484M.

    Eu tive que incorporar o tamanho do arquivo ibdata2no innodb_data_file_path e adicionaribdata3

    innodb_data_file_path=ibdata1:346M;ibdata2:2196875759616;ibdata3:10M:autoextend

    Quando reiniciei o mysqld, funcionou:

    [root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql     362807296 Jun  3 17:02 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun  3 17:02 ibdata2
-rw-rw---- 1 s-em7-mysql s-em7-mysql   32315015168 Jun  3 17:02 ibdata3

    Em 40 horas, ibdata3cresceu para 31G. MySQL estava mais uma vez funcionando.

    • 33

  2. Eu tive o mesmo problema e fiz apenas uma coisa e funcionou.

    Você parece ter um tamanho máximo muito baixo para o innodb_data_file_pathseu my.cnfarquivo de configuração. Basta alterar o código abaixo -

    innodb_data_file_path = ibdata1:10M:autoextend:max:512M

    Observação importante Você não pode hospedar mais 512MBde dados em todas as InnoDB tabelas combinadas.

    Você também pode alternar para um esquema innodb por tabela usando innodb_file_per_table.

    • 3

relate perguntas