Início / dba / Perguntas / 13614
Accepted
Abdul Manaf
Asked: 2012-02-22 20:44:29 +0800 CST

Uso e recomendações do Ibdata?

  • 772

Eu tenho um servidor de produção

Em 5 de novembro de 2011, o tamanho do ibdata era de 100 G. Em aproximadamente 3 meses, ele é aumentado para 200G. Portanto, acaba de dobrar de tamanho.

Tenho aproximadamente todas as tabelas com Innodb. Não estou usando innodb por tabela. Eu tenho meu idbata no lvm. Então, quanto devo aumentá-lo para uso futuro ..?

Ou qualquer outra maneira de lidar com o cenário.

mysql innodb

2 respostas

  1. Best Answer

    Você precisa parar de usar InnoDB (com innodb_file_per_table desativado) e instantâneos LVM o mais rápido possível. Aqui está o porquê:

    Eu tenho um sistema de monitoramento que usa o MySQL como banco de dados. Ele também tem innodb_file_per_table desativado. Em um espaço de 6 meses, cresceu para 1,3 TB.

    A empresa do meu empregador não pode ter tempo de inatividade para este sistema de monitoramento.

    Eu tentei criar um Slave para este banco de dados de monstros. Executei um rsync de /var/lib/mysql para o servidor Slave. Sua primeira passagem levou 42 horas (isso não é um erro de digitação, 1 dia 18 horas). A segunda passagem levou 84 horas (3 dias 12 horas) e foi concluída em apenas 15% (220 GB copiados). Como você pode ver, abandonei o segundo rsync.

    O problema decorreu de ibdata1 sendo 1,3 TB.

    O que há dentro de ibdata1 quando innodb_file_per_table está OFF?

    • Páginas de dados da tabela
    • Tabela Páginas Índice
    • Metadados da Tabela (Gerenciamento de ID do Tablespace)
    • Dados MVCC (para Isolamento de Transação, Conformidade ACID)

    Em um ambiente de gravação intensa, todos os registros desses quatro tipos estão sendo lidos e/ou gravados. O rsync experimentou um pesadelo tentando obter o ibdata1 aglutinado o suficiente para gravar alterações no servidor Slave. De acordo com meus colegas engenheiros seniores de Linux, um instantâneo LVM não se sairia melhor.

    Seu único recurso é começar a usar innodb_file_per_table.

    Para você ver melhor essa necessidade, execute esta consulta (deve levar de 5 a 10 minutos para você)

    SELECT IFNULL(B.engine,'Total') "Storage Engine",
CONCAT(LPAD(REPLACE(FORMAT(B.DSize/POWER(1024,pw),3),',',''),17,' '),' ',
SUBSTR(' KMGTP',pw+1,1),'B') "Data Size", CONCAT(LPAD(REPLACE(
FORMAT(B.ISize/POWER(1024,pw),3),',',''),17,' '),' ',
SUBSTR(' KMGTP',pw+1,1),'B') "Index Size", CONCAT(LPAD(REPLACE(
FORMAT(B.TSize/POWER(1024,pw),3),',',''),17,' '),' ',
SUBSTR(' KMGTP',pw+1,1),'B') "Table Size" FROM
(SELECT engine,SUM(data_length) DSize,SUM(index_length) ISize,
SUM(data_length+index_length) TSize FROM
information_schema.tables WHERE table_schema NOT IN
('mysql','information_schema','performance_schema') AND
engine IS NOT NULL GROUP BY engine WITH ROLLUP) B,
(SELECT 3 pw) A ORDER BY TSize;

    Usando os totais para InnoDB, compare-os com o tamanho de ibdata1. Você descobrirá que pode haver uma diferença de 30 GB ou menos. Executei uma consulta em ibdata1 em meu sistema de monitoramento e tinha apenas 27 GB para metadados de tabela e novas informações de MVCC. O crescimento constante sempre ocorreria neste arquivo.

    Aqui está o que você pode fazer: Converta todo o seu InnoDB para usar innodb_file_per_table. Escrevi um post no StackOverflow sobre como fazer isso . Você não apenas poderá ter cada tabela existente em um arquivo separado, como também poderá manter a taxa de crescimento de ibdata1 no mínimo.

    ATUALIZAÇÃO 2012-02-22 13:00 EST

    Ao executar o CleanUp do InnoDB, certifique-se de eliminar a criação de vários arquivos ibdata. sua configuração deve ser o padrão:

    [mysqld]
innodb_data_file_path=ibdata1:10M:autoextend
    • 6

  2. Além do que Rolando disse, mudar para a configuração por arquivo pode permitir que você recupere algum espaço em disco por meio de manutenção periódica.

    A tabela de otimização não faz muito por você com tudo em um único arquivo ibdata. No entanto, em uma configuração por arquivo, você pode recuperar algum espaço em disco fazendo isso. A tabela otimizada reconstruirá efetivamente a tabela inteira, eliminando o espaço não utilizado restante da fragmentação durante as exclusões.

    Você pode ver quais tabelas se beneficiarão disso executando show table status. Como alternativa executar

    select table_name, data_length, data_free from information_schema.tables
where engine='innodb' order by 3

    A otimização de tabelas com mais data_free proporcionará a maior economia de espaço em disco.

    No entanto, existem algumas ressalvas:

    • Cada tabela será totalmente bloqueada durante a otimização. Se uma mesa individual tiver de 10 a 100 shows, isso não será rápido
    • Você não deve esperar que o data_free caia completamente para 0 após uma otimização. Ainda haverá algum espaço não utilizado devido à maneira como o innodb aloca espaço em páginas de 16k.
    • 2

relate perguntas