XOOPS Brasil

 

4.5. Prevenção de Disastres e Recuperação

4.5.1. Backups dos Bancos de Dados

Como as tabelas do MySQL são armazenadas como arquivos, é mais fácil realizar um backup. Para obter um backup consistente, faça um LOCK TABLES nas tabelas relevantes seguido por FLUSH TABLES para as tabelas. Veja mais informações sobre isto na Seção 6.7.5, “Sintaxe LOCK TABLES e UNLOCK TABLES. Veja mais informações sobre isto na Seção 4.6.4, “Sintaxe de FLUSH. Você só precisa de um bloqueio de leitura; isto possibilita outras threads a continuarem a pesquisar nas tabelas enquanto você copia os arquivos no diretório do banco de dados. O FLUSH TABLE é necessário para garantir que todas as páginas ativas de índices serão escritas em disco antes de iniciar o backup.

A partir das versões 3.23.56 e 4.0.12 BACKUP TABLE não permitirá que você sobrescreva arquivos exixtentes já que isso colocaria em risco a segurança.

Se você desejar realizar um backup ao nível da linguagem SQL de um tabela, você pode utilizar SELECT INTO OUTFILE ou BACKUP TABLE. Veja mais informações sobre isto na Seção 6.4.1, “Sintaxe SELECT.Veja mais informações sobre isto na Seção 4.5.2, “Sintaxe de BACKUP TABLE.

Outra maneira de efetuar um backup de um banco de dados é utilizar o programa mysqldump ou o script mysqlhotcopy. Veja mais informações sobre isto na Seção 4.9.7, “mysqldump, Descarregando a Estrutura de Tabelas e Dados”. Veja mais informações sobre isto na Seção 4.9.8, “mysqlhotcopy, Copiando Bancos de Dados e Tabelas do MySQL”.

  1. Fazer um backup completo do seu banco de dados:

    shell> mysqldump --tab=/path/to/some/dir --opt db_name
    ou
    shell> mysqlhotcopy db_name /path/to/some/dir
    

    Você também pode simplesmente copiar os arquivos das tabelas (*.frm, *.MYD) e os arquivos *.MYI) quando o servidor não estiver atualizando nada. O script mysqlhotcopy utiliza este método. (Mas nopte que estes métodos não funcionarão se seu banco de dados contém tabelas InnoDB. InnoDB não armazena o conteúdo das tabelas em diretórios de banco de dados, e o mysqlhotcopy funciona apenas para tabelas MyISAM e ISAM.)

  2. Interrompa o mysqld caso ele esteja em execução, depois inicie-o com a opção --log-bin[=nome_arquivo]. Veja mais informações sobre isto na Seção 4.10.4, “O Log Binário”. Os arquivos de log binário fornecem a informação necessária para replicar alterações ao banco de dados que forem feitas depois do ponto em que você executou mysqldump.

Se o seu servidor MySQL é um slave, seja qual for o método de backup que você escolha, quando você faz backup dos dados do slave, você deve também fazer backup dos arquivos master.info e relay-log.info que são necessários para continuar a replicação depois que você restaurar os dados do slave. Se seu slave está sujeito a replicação de comandos LOAD DATA INFILE, você também deve fazer backup dos arquivos SQL_LOAD-* que podem existir no diretório especificado pela opção slave-load-tmpdir. (A localização padrão desta opção é o valor da variável tmpdirse não especificado.) O slave precisará destes arquivos para continuar a replicação de qualquer LOAD DATA INFILE interrompido.

Se você necessita restaurar alguma coisa, tente primeiro recuperar suas tabelas utilizando REPAIR TABLE ou myisamchk -r. Isto deve funcionar em 99.9% de todos os caso, Se o myisamchk falhar, tente o seguinte procedimento: (Isto só irá funcionar se você iniciou o MySQL com --log-update, veja Seção 4.10.4, “O Log Binário”,):

  1. Restaure o backup original feito com o mysqldump ou backup binário.

  2. Execute o seguinte comando para re-executar as atualizações armazenadas no log binário:

    shell> mysqlbinlog hostname-bin.[0-9]* | mysql
    

    Em seu caso você pode querer re-executar apenas alguns log binários, a partir de certas posiçõs (normalmente você quer re-executar todos os log binários a partir da data de restauração do backup, co exceção de algumas consultas erradas). Veja Seção 4.9.5, “mysqlbinlog, Executando as Consultas a Partir de um Log Binário” fpara mais informações sobre o utilitário mysqlbinlog e como usá-lo.

    Se você estiver utilizando o log atualizado, você pode executar o conteúdo do log de atualização desta forma:

    shell> ls -1 -t -r hostname.[0-9]* | xargs cat | mysql
    

O comando ls é usado para obter todos os arquivos de log na ordem correta.

Você pode também fazer backups seletivos com SELECT * INTO OUTFILE 'nome_arquivo' FROM nome_tabela e restaurar com LOAD DATA INFILE 'nome_arquivo' REPLACE.... Para evitar registros duplicados, você precisará de um chave PRIMARY KEY ou uma UNIQUE na tabela. A palavra chave REPLACE substitui os antigos registros com os novos quando um novo registro duplica um antigo registro em uma chave de valores únicos.

Se você tiver problemas de performance realizando backups no seu sistema, você pode resolver isto configurando uma replicação e fazendo os backups na máquina slave no lugar da master. Veja mais informações sobre isto na Seção 4.11.1, “Introdução”.

Se você estiver utilizando um sistema de arquivos Veritas, você pode fazer:

  1. Executar em um cliente (perl ?) FLUSH TABLES WITH READ LOCK

  2. Bifurcar uma shell ou executar em outro cliente mount vfxs snapshot.

  3. Executar no primeiro cliente UNLOCK TABLES

  4. Copiar arquivos do snapshot

  5. Desmontar snapshot

4.5.2. Sintaxe de BACKUP TABLE

BACKUP TABLE nome_tabela[,nome_tabela...] TO '/caminho/para/diretório/backup'

Faz uma cópia de todos os arquivos de tabela para o diretório de backup que é o mínimo necessário para restaurá-lo. Atualmente só funciona para tabelas MyISAM. Para tabela MyISAM, copia os arquivos .frm (definições) e .MYD (dados). O arquivo de índice pode ser reconstruído a partir destes dois.

Antes de utilizar este comando, por favor veja Veja mais informações sobre isto na Seção 4.5.1, “Backups dos Bancos de Dados”.

Durante o backup, o bloqueio de leitura (read lock) será usado para cada tabela, uma de cada vez, à medida que o backup é realizado. Se você deseja fazer backup de diversas tabelas como um snapshot, você deve primeiro usar LOCK TABLES obtendo um bloqueio de leitura para cada tabela no grupo.

O comando retorna uma tabela com as seguintes colunas:

ColunaValor
TableNome da Tabela
OpSempre backup
Msg_typeUm dos seguintes: status, error, info ou warning.
Msg_textA mensagem

Note que o comando BACKUP TABLE está disponível somente no MySQL versão 3.23.25 e posterior.

4.5.3. Sintaxe de RESTORE TABLE

RESTORE TABLE nome_tabela[,nome_tabela...] FROM '/caminho/para/diretório/backup'

Restaura a tabela ou tabelas utilizando o backup feito com BACKUP TABLE. Tabelas existentes não serão reescritas - se você tentar restaurar sobre uma tabela existente, obterá um erro. A restauração demora mais tempo do que o backup pois é necessário reconstruir o índice. Quanto mais chaves tiver, mais demorado será. Como no comando BACKUP TABLE, atualmente só funciona com tabelas MyISAM.

O comando retorna uma tabela com as seguintes colunas:

ColunaValor
TableNome da Tabela
OpSempre restore
Msg_typeUm dos seguintes: status, error, info ou warning
Msg_textA mensagem

4.5.4. Sintaxe de CHECK TABLE

CHECK TABLE nome_tabela[,nome_tabela...] [opção [opção...]]
opção = QUICK | FAST | MEDIUM | EXTENDED | CHANGED

CHECK TABLE funciona somente em tabelas MyISAM. Em tabelas MyISAM é a mesma coisa que executar myisamchk --medium-check nome_tabela na tabela.

Se você não especificar nenhuma opção, MEDIUM é usado.

Verifica se existem erros na(s) tabela(s). Para as tabelas MyISAM as estatísticas das chaves são atualizadas. O comando retorna uma tabela com as seguintes colunas:

ColunaValor
TableNome da Tabela.
OpSempre check
Msg_typeUm dos seguintes: status, error, info, or warning
Msg_textA mensagem

Note que a instrução pode produzir várias linhas de informações para cada tabela conferida. A última linha irá ser do tipo Msg_type status e normalmente deve estar OK. Se você não obteve OK ou Not checked, deve ser executado, normalmente, um reparo da tabela. Veja mais informações sobre isto na Seção 4.5.6, “Utilizando myisamchk para Manutenção de Tabelas e Recuperação em Caso de Falhas”. Table is already up to date significa que o gerenciador de armazenamento para a tabela indica que não há necessidade de verificar a tabela.

Os diferentes tipos de consistências são as seguintes:

TipoSignificado
QUICKNão busca os registros verificando ligações incorretas.
FASTSó confere tabelas que não foram fechadas corretamente.
CHANGEDSó verifica as tabelas que foram alteradas desde a última conferência ou que não foram fechadas corretamente.
MEDIUMBusca os registros para verificanado que ligações removidas estão ok. Isto também calcula uma chave de conferência para os registros e verifica isto com um checksum calculado para as chaves.
EXTENDEDFaz uma busca completa nas chaves para todas as chaves em cada registro. Isto assegura que a tabela está 100% consistente, mas pode demorar muito tempo para executar!

Para tabelas MyISAM de tamanho dinâmico, uma verificação iniciada sempre fará uma verificação MEDIUM. Para registros de tamanho estático nós saltamos a busca de registros para QUICK e FAST já que os registros estão raramente corrompidos.

Você pode combinar opções de consistência como no exemplo a seguir que faz uma verificação rápida na tabela para ve se ela foi fechada corretamente:

CHECK TABLE test_table FAST QUICK;

NOTA: em alguns casos CHECK TABLE irá alterar a tabela! Isto acontece se a tabela estiver marcada como 'corrupted' (corrompida) ou 'not closed properly' (não foi fechada corretamente) mas o CHECK TABLE não encontrar não encontrar nenhum problema na tabela. Neste caso, CHECK TABLE irá marcar a tabela como ok.

Se uma tabela estiver corrompida, é preferível que seja um problema nos índices e não na parte de dados. Todos os tipos de consistência acima sempre confere os índices e deve então encontrar a maioria dos erros.

Se você só quiser conferir uma tabela que acredita estar ok, você não deve utilizar nenhuma opção para o comando check ou utilizar a opção QUICK. O último deve ser utilizado quando você estiver com pressa e o rísco do QUICK não encontrar um erro no arquivo de dados for mínimo (Na maioria dos casos o MySQL pode encontrar, sob utilização normal, qualquer erro no arquivo de dados. Se isto ocorrer, então a tabela será marcada como 'corrupted', neste caso a tabela não poderá ser utilizada até ser reparada).

FAST e CHANGED são normalmente chamados a partir de um script (um exemplo é ser executado a partir do cron) Se você desejar conferir suas tabelas de tempos em tempos. Na maioria dos casos, o FAT é uma opção melhor que CHANGED. (O único caso em que isto não acontece é quando você suspeita que encontrou um bug no código do MyISAM.).

EXTENDED deve ser utilizado somente depois de ter executado um check normalmente, mas continuar obtendo erros de uma tabela quando o MySQL tenta atualizar um registro ou encontrar um registro pela chave (isto seria muito difícil ocorrer caso uma conferência normal tenha executado com sucesso!).

Alguns problemas relatados por CHECK TABLE, não podem ser corrigidas automaticamente:

  • Found row where the auto_increment column has the value 0.

    Isto significa que você possui um registro na tabela onde o campo índice que utiliza o recurso auto_increment contem o valor 0. (É possível criar um registro onde a coluna de auto incremento seja 0 definindo explicitamente 0 em uma instrução UPDATE).

    Isto não é exatamente um erro, mas pode causar problemas se você decidir descarregar a tabela e restaurá-la ou executar um ALTER TABLE na tabela. Neste caso a coluna de auto incremento irá alterar seu valor, de acordo com as regras das colunas de auto incremento, que pode causar problemas como um erro de chave duplicada.

    Para se livrar do alerta, basta executar uma instrução UPDATE para configurar a coluna para algum outro valor diferente de 0.

4.5.5. Sintaxe do REPAIR TABLE

REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name[,tbl_name...] [QUICK] [EXTENDED] [USE_FRM]

REPAIR TABLE funciona somente em tabelas MyISAM e é a mesma coisa que executar myisamchk -r nome_tabela na tabela.

Normalmente você nunca deve executar este comando, mas se um disastre ocorrer você vai precisar recuperar seus dados de uma tabela MyISAM utilizando REPAIR TABLE. Se as suas tabelas estiverem muito corrompidas, você deve encontrar a razão, para eleiminar a necessidade de se usar REPAIR TABLE! Veja mais informações sobre isto na Seção A.4.1, “O Que Fazer Se o MySQL Continua Falhando”. Veja mais informações sobre isto na Seção 7.1.3, “Problemas com Tabelas MyISAM.

REPAIR TABLE repara uma tabela possivelmente corrompida. O comando retorna uma tabela com as seguintes colunas:

ColunaValor
TableNome da Tabela
OpSempre repair
Msg_typeUm dos seguintes: status, error, info ou warning
Msg_textA mensagem

Note que a instrução pode produzir várias linhas de informações para cada tabela recuperada. A ultima linha será de Msg_type status e normalmente deve exibir OK. Se o retorno não for OK, você pode tentar reparar a tabela com myisamchk -o, já que REPAIR TABLE ainda não implementa todas as opções de myisamchk. Futuramente iremos torná-lo mais flexível.

Se o parâmetro QUICK for especificado, REPAIR tenta reparar somente a árvore de índices.

Se você utilizar EXTENTED, o MySQL criará o índice, registro a registro em vez de criar um índice de uma vez com ordenação; Isto pode ser melhor que a ordenação em chaves de tamanho fixo se você tiver grandes chaves do tipo char() que compactam muito bem.

No MySQL 4.0.2, existe um modo USE_FRM para REPAIR. Use-o se o arquivo .MYI estiver faltando ou o seu cabeçalho estiver corrompido. Neste modo o MySQL recriará a tabela, usando a informação do arquivo .frm. Este tipo de reparo não pode ser feito com myisamchk.

Aviso: Se o mysqld morre durante um REPAIR TABLE, é essencial que você faça imediatamente outro REPAIR na tabela antes de executar qualquer outro comando nela. (Claro que é sempre bom inciar com um backup). No pior caso você pode ter um novo arquivo de índice limpo sem informação sobre o arquivo de dados e quando você executar o próximo comando o arquivo de dados pode ser sobreescrito. Isto não é um cenário desejável, mas possível.

Antes do MySQL 4.1.1, o comando REPAIR não era gravado no log binário. Desde o MySQL 4.1.1. eles são escritos no log binário a menos que a palavra chave opcional NO_WRITE_TO_BINLOG (ou seu alias LOCAL) seja usada.

4.5.6. Utilizando myisamchk para Manutenção de Tabelas e Recuperação em Caso de Falhas

A partir do MySQL versão 3.23.13 você pode mandar verificar as tabelas MyISAM com o comando CHECK TABLE. Veja mais informações sobre isto na Seção 4.5.4, “Sintaxe de CHECK TABLE. Pode-se reparar tabelas com o comando REPAIR TABLE. Veja mais informações sobre isto na Seção 4.5.5, “Sintaxe do REPAIR TABLE.

Para verificar/reparar tabelas MyISAM (.MYI e .MYD) você deve utilizar o utilitário myisamchk. Para consistir/reparar tabelas ISAM (.ISM e .ISD) você deve usar o utilitário isamchk. Veja mais informações sobre isto na Capítulo 7, Tipos de Tabela do MySQL.

No texto a seguir iremos comentar sobre o myisamchk, mas tudo também se aplica ao antigo isamchk.

Você pode utilizar o utilitário myisamchk para obter informações sobre suas tabelas de bancos de dados, verficá-las, repará-las ou otimizá-las. As seguintes seções descrevem como executar myisamchk (incluindo uma descrição de suas opções), como montar um calendário de manutenção, e como utilizar o myisamchk para executar suas várias funções.

Você pode, na maioria dos casos, utilizar o comando OPTIMIZE TABLES para otimizar e reparar tabelas, mas não é tão rápido e confiável (no caso real de erros fatais) como o mysisamchk. Por outro lado, OPTIMIZE TABLE é mais fácil de usar e você não tem que se preocupar com a recarrega das tabelas. Veja mais informações sobre isto na Seção 4.6.1, “Sintaxe de OPTIMIZE TABLE.

Embora os reparos realizados pelo myisamchk sejam bastante seguros, porém é sempre uma boa idéia fazer um backup dos dados ANTES de realizar um reparo (ou qualquer coisa que fará grandes alterações em alguma tabela)

4.5.6.1. Sintaxe do myisamchk

myisamchk é chamado desta forma:

shell> myisamchk [opções] nome_tabela

As opções especificam o que você deseja que o myisamchk faça. Elas são descritas abaixo. (Você também pode obter a lista das opções com myisamchk --help.) Sem opções, o myisamchk simplesmente checa sua tabela. Para obter maiores informações ou dizer ao myisamchk para tomar ações corretivas, especifique as opções descritas abaixo e nas seções seguintes.

nome_tabela é o nome da tabela do banco de dados que você deseja verificar/reparar. Se você executar o myisamchk em algum lugar diferente do diretório do banco de dados, você deve especificar o caminho para o arquivo, porque myisamchk não faz idéia de onde seu banco de dados se encontra. Na verdade, myisamchk não se importa se os arquivos estão localizados em um diretório de banco de dado; você pode copiar os arquivos que correspondem a uma tabela de banco de dados em outra localização e realizar neste outro lugar as operações corretivas.

Você pode nomear várias tabelas na linha de comando do myisamchk se você desejar. Você também pode especificar um nome como um arquivo de índice (com o sufixo .MYI), que lhe permite especificar todas tabelas em um diretório utilizando o padrão *.MYI. Por exemplo, se você está em um diretório de banco de dados, você pode checar todas as tabelas no diretório desta forma:

shell> myisamchk *.MYI

Se você não estiver no diretório do banco de dados, você pode verificar todas as tabelas existentes especificando o caminho para o diretório:

shell> myisamchk /caminho/para/banco_de_dados/*.MYI

Você pode verificar todas as tabelas em todos os bancos de dados especificando um meta caracter com o caminho para o diretório de banco de dados do MySQL:

shell> myisamchk /caminho/para/diretório_dados/*/*.MYI

A maneira recomendada para conferir todas as tabelas rapidamente é:

myisamchk --silent --fast /caminho/para/diretório_dados/*/*.MYI
isamchk --silent /caminho/para/diretório_dados/*/*.ISM

Se você quiser conferir todas as tabelas e reparar todas que estiverem corrompidas, pode utilizar linha a seguir:

myisamchk --silent --force --fast --update-state -O key_buffer=64M \
-O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M \
/caminho/para/diretório_dados/*/*.MYI
isamchk --silent --force -O key_buffer=64M -O sort_buffer=64M \
-O read_buffer=1M -O write_buffer=1M /caminho/para/diretório_dados/*/*.ISM

A linha acima assume que você tem mais de 64 MB de memória livre.

Perceba que se você obter um erro do tipo:

myisamchk: warning: 1 clients is using or hasn't closed the table properly

Isto significa que você está tentando verificar uma tabela que está sendo atualizada por outro programa (como o servidor mysqld) que ainda não fechou o arquivo ou que finalizou sem fechar o arquivo corretamente.

Se o mysqld está em execução, você deve forçar o sincronimo e fechamento de todas tabelas com FLUSH TABLES e assegurar que ninguém mais esteja utilizando as tabelas quando for executar o myisamchk. No MySQL versão 3.23 a forma mais simples de evitar este problema é utilizar CHECK TABLE no lugar de myisamchk para verificar as tabelas.

4.5.6.2. Opções Gerais do myisamchk

myisamchk suporta as seguintes opções.

  • -# ou --debug=debug_options

    Saída do log de depuração. A string debug_options geralmente é 'd:t:o,nomearquivo'.

  • -? ou --help

    Exibe uma mensagem de ajuda e sai.

  • -O nome=opção, --set-variable=nome=opção

    Configura o valor de uma variável. Por favor note que as sintaxes --set-variable=nome=valor e -O name=value estão obsoletas desde o MySQL 4.0. Use --nome=valor. As variáveis possíveis e seus valores padrões para o myisamchk podem ser examinados com myisamchk --help

    VariávelValor
    key_buffer_size523264
    read_buffer_size262136
    write_buffer_size262136
    sort_buffer_size2097144
    sort_key_blocks16
    decode_bits9

    sort_buffer_size é utilizado quando as chaves são reparadas pela ordenação das chaves, que é o caso normal quando você utiliza --recover.

    key_buffer_size é utilizando quando você estiver conferindo a tabela com --extended-check ou quando as chaves são reparadas inserindo-as registro a registro na tabela (como com inserts normais). O reparo através de buffer de chaves (key buffer) é utilizado nos seguintes casos:

    • Se você utilizar --safe-recover.

    • Se os arquivos temporários necessários para ordenar as chaves forem maior que o dobro do tamanho de quando se criasse o arquivo de chaves diretamente. Isto é o caso quando se tem chaves CHAR, VARCHAR ou TEXT tao grandes quanto necessário pela ordenação para armazenar todas as chaves durante o processo. Se você tiver muito espaço temporário e puder forçar o myisamchk a reparar por ordenação você pode utilizar a opção --sort-recover.

    Reparação através do buffer de chaves (key buffer) economiza muito mais espaço em disco do que utilizando ordenação, mas é muito mais lenta.

    Se você deseja uma reparação mais rápida, configure as variáveis acima para cerca de 1/4 da sua memória disponível. Você pode configurar as variáveis para valores altos, pois somente um dos buffers acima será utilizado a cada vez.

  • -s ou --silent

    Modo discreto ou silencioso. Escreve a saída somente quando um erro ocorre. Você pode utilizar -s duas vezes (-ss) para deixar o mysisamchk mais silencioso.

  • -v ou --verbose

    Modo prolixo. Gera mais informação de saída. Ele pode ser utilizado com -d e -e. Utilize -v múltiplas vezes -vv, -vvv) para gerar mais saída!

  • -V ou --version

    Exibe a versão do myisamchk e sai.

  • -w ou, --wait

    No lugar de gerar um erro se a tabela estiver bloqueada, espere até que a tabela fique livre antes de continuar. Perceba que se você estiver utilizando mysqld na tabela com --skip-external-locking, a tabela só pode ser trancada por outro comadno myisamchk.

4.5.6.3. Opções de Verificação do myisamchk

  • -c ou --check

    Confere por erros na tabela. Esta é a operação padrão se você não estiver utilizando opções que a anulam.

  • -e ou --extend-check

    Verifica a tabela de forma completa (que é bastante lento se você tiver vários índices). Esta opção deve ser usada somente em casos extremos. Normalmente, myisamchk ou myisamchk --medium-check deve, na maioria dos casos, estar apto a encontrar quaisquer erros na tabela.

    Se você estiver utilizando --extended-check e tiver muita memória, você deve aumentar um pouco o valor de key_buffer_size!

  • -F ou --fast

    Verifica apenas tabelas que não foram fechadas corretamente.

  • -C ou --check-only-changed

    Verifica apenas tabelas que foram alteradas desde a última verificação.

  • -f ou --force

    Reinicia o myisamchk com -r (reparos) na tabela, se myisamchk encontrar quaisquer erros na tabela.

  • -i ou --information

    Exibe informações e estatísticas sobre a tabela que estiver sendo verificada.

  • -m ou --medium-check

    Mais rápido que extended-check, mas encontra somente 99.99% de todos os erros. Deve, entretando, ser bom o bastante para a maioria dos casos.

  • -U ou --update-state

    Armazena no arquivo .MYI quando a tabela foi verificada e se a tabela falhou. Isto deve ser utilizado para obter o benefício integral da opção --check-only-changed, mas você não deve utilizar esta opção se o servidor mysqld esta usando a tabela e o mysqld esta sendo executado com --skip-external-locking.

  • -T ou --read-only

    Não marca as tabelas como verificadas. Isto é útil se você utiliza o myisamchk para verificar uma tabela que esteja em uso por alguma outra aplicação que não utiliza bloqueios (como no mysqld --skip-external-locking).

4.5.6.4. Opções de Reparos do myisamchk

As seguintes opções são usadas se você iniciar o myisamchk com -r ou -o:

  • -B or --backup

    Faz um backup dos arquivos .MYD como filename-time.BAK

  • --correct-checksum

    Correct checksum information for table.

  • -D # ou --data-file-length=#

    Tamanho máximo do arquivo de dados (ao recriar arquivos de dados quando eles estão 'cheios').

  • -e ou --extend-check

    Tenta recuperar todos registros possíveis do arquivo de dados. Normalmente isto irá encontrar também várias linhas com lixo. Não utiliza esta opção a menos que esteja em desespero total.

  • -f ou --force

    Sobrescreve antigos arquivos temporários (nome_tabela,TMD) em vez de abortar.

  • -k # ou --keys-used=#

    Se você estiver utilizando ISAM, diz ao manipulador de tabelas do ISAM para atualizar somente os primeiros # índices. Se você estiver utilizando MyISAM, informa quais chaves usar, onde cada bit seleciona uma chave (a primeira chave possui o bit 0). Isto pode ser utilizado para inserções mais rápidas! Índices desativados podem ser reativados utilizando myisamchk -r.

  • -l ou --no-symlinks

    Não segue links simbólicos. Normalmente o myisamchk repara a tabela para qual um link simbólico aponta. Esta opção não existe no MySQL 4.0 pois o MySQL 4.0 não irá remover links simbólicos durante os reparos.

  • -p or --parallel-recover

    Usa a mesma técnica que -r e -n, mas cria todas as chaves em paralelo, em threads diferentes. A opção foi adicionada no MySQL 4.0.2. Este código é alfa. Use por sua conta e risco!

  • -r ou --recover

    Pode concertar quase tudo excetos chaves únicas que não são únicas (Que é um erro extremamente indesejável com tabelas ISAM/MyISAM). Se você deseja recuperar uma tabela, esta é primeira opção a ser tentada. Somente se o myisamchk relatar que a tabela não pode ser recuperada pelo -r você deve tentar então a opção -o. (Perceba que no caso indesejável de -r falhar, o arquivo de dados continuará intacto.) Se você possui muita memória, você deve aumentar o tamanho de sort_buffer_size!

  • -o ou --safe-recover

    Utiliza um antigo método de recuperação (le através de todos registros na ordem e atualiza todas as árvores de índices baseado nos registros encontrados); esta opção é muito mais lenta que -r, mas pode tratar vários casos indesejáveis que o -r não consegue tratar. Este método de recuperação também utiliza muito menos espaço em disco que -r. Normalmente sempre se deve tentar, primeiro, um reparo com -r, e somente se ele falhar, usar -o.

    Se você possuir muita memória, você deve aumentar o tamanho de sort_buffer_size!

  • -n ou --sort-recover

    Força o uso de ordenação do myisamchk para resolver as chaves mesmo se os arquivos temporários forem muito grandes.

  • --character-sets-dir=...

    Diretório onde conjuntos de caracteres são armazenados.

  • --set-character-set=name

    Altere o conjunto de caracteres usado pelo índice

  • .t ou --tmpdir=path

    Caminho para armazenar arquivos temporários. Se isto não for configurado, myisamchk irá usar a variável de ambiente TMPDIR para isto. A partir do MySQL 4.1, tmpdir pode ser configurado com uma lista de caminhos separados por dois pontos : (ponto e virgula ; no Windows). Eles serão usado da forma robin-round.

  • -q ou --quick

    Reparo rápido sem modificar o arquivo de dados. Pode ser fornecido um segundo -q para forçar o myisamchk para modificar o arquivo de dados original no caso de chaves duplicadas.

  • -u ou --unpack

    Descompacta arquivo empacotado com o myisampack.

4.5.6.5. Outras Opções do myisamchk

Outras ações que o myisamchk pode fazer, alem de reparar e verificar tabelas:

  • -a or --analyze

    Analiza a distribuição das chaves. Isto aumenta o desempenho de join habilitando o otimizador de joins para melhor escolher em qual ordem ele deve unir as tabelas e quais chaves ele deve usar: myisamchk --describe --verbose table_name' ou usar SHOW KEYS no MySQL.

  • -d or --description

    Exibe alguma informação sobre tabela.

  • -A or --set-auto-increment[=value]

    Força que AUTO_INCREMENT com um valor maior ou igual a este. Se nenhum valor é dado, então define o próximo valor AUTO_INCREMENT com o maior valor usado para a chave automatica + 1.

  • -S or --sort-index

    Ordene o bloco da árvore índice do mais alto para o mais baixo. Isto otimizará as buscas e tornará a pesquisa em tabela através da chave mais rápida.

  • -R or --sort-records=#

    Ordena o registro de acordo com um índice. Isto faz com que seus dados estejam muito mais localizados e pode aumentar a velocidade das operações SELECT e ORDER BY neste índice. (Pode ser bem lento na primeira ordenação!) Para encontrar um número de índices da tabela, use SHOW INDEX, que mostra os índices de um tabela na mesma ordem que o myisamchk os vê. Índices são números que se iniciam com 1.

4.5.6.6. Uso de Memória do myisamchk

Alocação de memória é importante quando você executa o myisamchk. myisamchk não utiliza mais memória do que você especifica com a opção -O. Se você irá utilizar o myisamchk em grandes arquivos, você deve decidir primeiro quanta memória deseja usar. O valor padrão é utilizar somente 3MB para correções. Utilizando valores maiores, o myisamchk pode operar mais rapidamente. Por exemplo, se você tiver mais que 32M de memória RAM, você pode utilizar opções tais como esta (em adição às várias outras que podem ser especificadas):

shell> myisamchk -O sort=16M -O key=16M -O read=1M -O write=1M ...

Utilizando -O sort=16M provavelmente é suficiente para a maioria dos casos.

Certiffique-se que o myisamchk utiliza arquivos temporários em TMPDIR. Se TMPDIR aponta para um sistema de arquivos em memória, você pode facilmente obter erros de memória. Se isto acontecer, configure TMPDIR para apontar para algum diretório com mais espaço e reinicie o myisamchk.

Quando reparando, o myisamchk também precisará de bastante espaço em disco:

  • Dobra-se o tamanho do arquivo de registros (o original e uma cópia). Este espaço não é necessário se for feito um reparo com --quick, já que neste caso somente o arquivo de índices será recriado. Este espaço é necessário no mesmo disco que se encontra o arquivo de registros original!

  • Espaço para o novo arquivo de índice que substitui o antigo. O arquivo de índices antigo é truncando no início, portanto, normalmente este espaço é ignorado. Este espaço é necessário no mesmo disco que o arquivo de índice original!

  • Quando utilizando --recover ou --sort-recover (mas não quando usando --safe-recover, será necessário espaço para um buffer de ordenação de: (maior_chave + tamanho_do_ponteiro_de_registro)*número_de_registros * 2. Você pode conferir o tamanho das chaves e o tamanho_do_ponteiro_de_registro com myisamchk -dv tabela. Este espaço é alocado no disco temporário (especificado por TMPDIR ou --tmpdir=#).

Se você tiver um problema com espaço em disco durante o reparo, pode-se tentar usar --safe-recover em vez de --recover.

4.5.6.7. Uso do myisamchk para Recuperação em Caso de Falhas

Se você executa o mysqld com a opção --skip-external-locking (que é o padrão em alguns sistemas, como o Linux), você não pode utilizar com segurança o myisamchk para conferir uma tabela se o mysqld estiver utilizando a mesma tabela. Se você pode ter certeza que ninguém está acessando as tabelas através do mysqld enquanto você executa o myisamchk, você só tem que executar o mysqladmin flush-tables antes de iniciar a verificação das tabelas. Se você não tem certeza, então você deve desligar o mysqld enquanto verifica as tabelas. Se você executa o myisamchk enquanto o mysqld estiver atualizando as tabelas, você pode obter um altera que a tabela está corrompida mesmo se não estiver.

Se você não estiver utilizando --skip-external-locking, pode usar o myisamchk para conferir as tabelas a qualquer hora. Enquanto você faz isto, todos os clientes que tentarem atualizar a tabela irão esperar até que o myisamchk esteja pronto, antes de continuar.

Se você utilizar o myisamchk para reparar ou otimizar tabelas, você DEVE sempre assegurar que o servidor mysqld não esteja utilizando a tabela (Isto também aplica se você utiliza --skip-external-locking). Se você não desligar o mysql, você deve, pelo menos, fazer um mysqladmin flush-tables antes de executar o myisamchk. Suas tabelas podem estar corrompidos se o servidor e o myisamchk acessarem a tabela simultaneamente.

Este capítulo descreve como checar e lidar com dados corrompidos nos bancos de dados MySQL. Se suas tabelas corromperem com frequência deve ser encontrada a razão para isto! Veja mais informações sobre isto na Seção A.4.1, “O Que Fazer Se o MySQL Continua Falhando”.

A seção de tabelas MyISAM contêm motivos do porque uma tabela pode estar corrompida. Veja mais informações sobre isto na Seção 7.1.3, “Problemas com Tabelas MyISAM.

Quando se realizar recuperação devido a falhas, é importante entender que cada tabela nome_tabela em um banco de dados corresponde a tres arquivos no diretório do banco de dados:

ArquivoPropósito
nome_tabela.frmArquivo com definições da tabela (form)
nome_tabela.MYDArquivo de dados
nome_tabela.MYIArquivo de índices

Cada um destes três tipos de arquivos está sujeito a corrupção de várias formas, mas problemas ocorrem mais frequentemente em arquivos de dados e índices.

O myisamchk trabalha criando uma cópia do arquivo de dados .MYD linha a linha. Ele termina o estágio de reparos removendo o antigo arquivo .MYD e renomeando o novo arquivo com nome original. Se for utilizada a opção --quick, myisamchk não cria um arquivo .MYD temporário, mas assume que o arquivo .MYD está correto e somente gera um novo arquivo índice sem mexer no arquivo de dados. Isto é seguro, pois o myisamchk detecta automaticamente se o arquivo .MYD está corrompido e aborda o reparo neste caso. Você pode também fornecer duas opções --quick para o myisamchk. Neste caso, o myisamchk não aborta em alguns erros (como chaves duplicadas) mas tenta resolvê-los modificando o arquivo .MYD. Normalmente o uso de duas opções --quick é útil somente se você tiver muito pouco espaço em disco para realizer um reparo normal. Neste caso você deve pelo menos fazer um backup antes de executar o myisamchk.

4.5.6.8. Como Verificar Erros em Tabelas

Para conferir uma tabela MyISAM, utilize os seguintes comandos:

  • myisamchk nome_tabela

    Encontra 99.99% de todos os erros. O que ele não pode encontrar é corrompimento que envolva SOMENTE o arquivo de dados (que não é comum). Se você desejar conferir uma tabela, você deve executar normalmente o myisamchk sem opções ou com as opções -s ou --silent.

  • myisamchk -m nome_tabela

    Encontra 99.999% de todos os erros. Ele verifica primeiramente erros em todas as entradas do índice e então le todos os registros. Ele calcula um checksum para todas as chaves nos registros e verifica se o checksum é o mesmo que o checksum das chaves na árvore de índices.

  • myisamchk -e nome_tabela

    Realiza a verificação completa de todos os dados (-e significa ``conferência extendida''). Ele faz uma conferência lendo todas as chaves de cada registro para verificar se eles realmente apontam para o registro correto. Isto pode demorar MUITO tempo em uma tabela grande com várias chaves. myisamchk normalmente irá parar depois do primeiro erro que encontrar. Se você deseja obter mais informações, pode adicionar a opção --verbose (-v). Isto faz o myisamchk continuar a percorrer a tabela até um máximo de 20 erros. Em utilização normal, um simples myisamchk (sem argumentos além do nome da tabela) é suficiente.

  • myisamchk -e -i nome_tabela

    Como o comando anterior, mas a opção -i diz ao myisamchk para exibir algumas informações estatísticas também.

4.5.6.9. Como Reparar Tabelas

Na seção seguinte nós só falaremos do uso do myiasmchk em tabelas MyISAM (extensões .MYI e .MYD). Se você estiver usando tabelas ISAM (extensões .ISM e .ISD), você deve usar a ferramenta isamchk.

A partir do MySQL versão 3.23.14, você pode reparar tabelas MyISAM com o comando REPAIR TABLE. Veja mais informações sobre isto na Seção 4.5.5, “Sintaxe do REPAIR TABLE.

Os sintomas de uma tabela corrompida incluem pesquisas que abortam inesperadamente e erros como estes:

  • nome_tabela.frm is locked against change

  • Can't find file nome_tabela.MYI (Errcode: ###)

  • Unexpected end of file

  • Record file is crashed

  • Got error ### from table handler

    Para obter mais informações sobre o erro você pode executar perror ###. Aqui estão os erros mais comuns que indicam um problema com a tabela:

    shell> perror 126 127 132 134 135 136 141 144 145
    126 = Index file is crashed / Wrong file format
    127 = Record-file is crashed
    132 = Old database file
    134 = Record was already deleted (or record file crashed)
    135 = No more room in record file
    136 = No more room in index file
    141 = Duplicate unique key or constraint on write or update
    144 = Table is crashed and last repair failed
    145 = Table was marked as crashed and should be repaired
    

    Note que o erro 135 (não mais no arquivo de registro), não é um erro que pode ser corrigido por um simples reparo. Neste caso você deve fazer:

    ALTER TABLE tabela MAX_ROWS=xxx AVG_ROW_LENGTH=yyy;
    

    Você também pode usar esta técnica para o erro 136 (não mais no arquivo de índice).

Em outros casos, você deve reparar suas tabelas. myisamchk pode normalmente detectar a maioria dos problemas que ocorrem.

O processo de reparo involve até quatro estágios, descritos abaixo. Antes de começar, você deve mudar para o diretório do banco de dados e conferir as permissões dos arquivos de tabelas. Tenha certeza que eles possam ser lidos pelo utilizador do Unix com o qual mysqld é executado (e para você, porque você precisa acessar os arquivos que está conferindo). Se não estiverem, você precisa alterar os arquivos, eles também devem ter a permissão de escrita para você.

Se você estiver utilizando o MySQL versão 3.23.16 e superior, você pode (e deve) usar os comandos CHECK e REPAIR para conferir e corrigir tabelas MyISAM. Veja mais informações sobre isto na Seção 4.5.4, “Sintaxe de CHECK TABLE. Veja mais informações sobre isto na Seção 4.5.5, “Sintaxe do REPAIR TABLE.

A seção do manual sobre manutenção de tabelas inclui as opções para isamchk/myisamchk. Veja mais informações sobre isto na Seção 4.5.6, “Utilizando myisamchk para Manutenção de Tabelas e Recuperação em Caso de Falhas”.

A seguinte seção são para os casos onde o comando acima falhar ou se você desejar usar os recursos extendidos que o isamchk e myisamchk fornecem.

Se você for reparar uma tabela da linha de comandos, deve primeiro desligar o servidor mysqld. Perceba que quando você executa mysqladmin shutdown em um servidor remoto, o servidor mysqld irá continuar funcionando por um tempo depois do mysqladmin retornar, até que todas as queries parem e todas as chaves sejam descarregadas no disco.

Estágio 1: Verificando suas tabelas

Execute myisamchk *.MYI ou myisamchk -e *.MYI se você tiver tempo disponível. Utilize a opção -s (silencioso) para suprimir informações desnecessárias.

Se o servidor mysqld parar, deve ser utilizada a opção --update para dizer ao myisamchk marcar a tabela como 'checada'.

Você deve reparar somente as tabelas em que o myisamchk indicar um erro. Para tais tabelas, vá para o estágio 2.

Se você obter erros estranhos na verficação (como nos erros out of memory), ou se o myisamchk quebrar, vá para o estágio 3.

Estágio 2: Reparo simples e seguro

NOTA: Se você deseja que os reparos sejam mais rápidos, devem ser usadas as opções: -O sorf_buffer=# -O key_buffer=# (onde # seria 1/4 da memória disponível) para todos comandos isamchk/myisamchk.

Primeiro, tente usar myisamchk -r -q nome_tabela (-r -q significa ``modo de recuperação rápida''). Ele tentará reparar o arquivo de índice sem mexer no arquivo de dados. Se o arquivo de dados estiver normal e os links apagados apontam nas localizações corretas dentro do arquivo de dados, isto deve funcionar e a tabela será corrigida. Inicie o reparo da próxima tabela. Outra maneira seria utilizar os seguintes procedimentos:

  1. Faça um backup do arquivo de dados antes de continuar.

  2. Utilize myisamchk -r nome_tabela (-r significa modo de ``recuperação''). Isto removerá registros incorretos e deletados do arquivo de dados e reconstroi o arquivo de índices.

  3. Se o passo anterior falhar, utilize myisamchk --safe-recover nome_tabela. O modo de recuperação segura utiliza um metódo de recuperação antiga que trata de alguns casos que o modo de recuperação comum não consegue (porém é mais lento).

Se você obter erros estranhos no reparo (como em erros out of memory), ou se o myisamchk falhar, vá para o estágio 3.

Estágio 3: Reparo difícil

Você só deve atingir este estágio se o primeiro bloco de 16K do arquivo de índice estiver destruído ou conter informações incorretas, ou se o arquivo de índice não existir. Neste caso, é necessário criar um novo arquivo de índice. Faça como a seguir:

  1. Mova o arquivo de dados para algum lugar seguro.

  2. Use o arquivo de descrição de tabelas para criar novos arquivos (vazios) de dados e índices:

    shell> mysql nome_bd
    mysql> SET AUTOCOMMIT=1;
    mysql> TRUNCATE TABLE nome_tabela;
    mysql> quit
    

    Se sua versão do MySQL não possuir TRUNCATE TABLE, utilize DELETE FROM nome_tabela.

  3. Copie o antigo arquivo de dados de volta para o novo arquivo de dados criado. (Não só mova o antigo arquivo de volta para o novo arquivo; você deve uma cópia no caso de algo der errado.)

Volte ao estágio 2. myisamchk -r -q deve funcionar agora. (Isto não deve ser um loop eterno.)

No MySQL 4.0.2 você também pode utilizar REPAIR ... USE_FRM o qual realiza todo o procedimento automaticamente.

Estágio 4: Reparo muito difícil

Você deve atingir este estágio somente se o arquivo de descrição também falhar. Isto nunca deve acontecer, porque o arquivo de descrição não é alterado depois da tabela ser criada:

  1. Restaure o arquivo de descrição de um backup e volte ao estágio 3. Você pode também restaurar o arquivo de índice e voltar ao estágio 2. No último caso, você deve iniciar com myisamchk -r.

  2. Se você não tem um backup mas sabe exatamente como a tabela foi criada, crie uma cópia da tabela em outro banco de dados. Remova o novo arquivo de dados, e então mova a descrição e arquivos de índice do outro banco de dados para o banco de dados com problemas. Isto lhe fornece um novo arquivos índice e descrição, mas mantêm o arquivo de dados da mesma forma. Volte ao estágio 2 e tente reconstruir o arquivo de índices.

4.5.6.10. Otimização de Tabelas

Para agrupar registros fragmentados e eliminar perda de espaço resultante de remoções ou atualizações de registros, execute myisamchk no modo de recuperação:

shell> myisamchk -r nome_tabela

Você pode otimizar uma tabela da mesma forma utilizando a instrução SQL OPTIMIZE TABLE. OPTIMIZE TABLE faz o reparo de tabelas, analisa chaves e também ordena a árvore de índices para fazer pesquisas por chave mais rápidas. Também não existem possibilidade de interação não desejável entre o utilitário e o servidor, porque o servidor faz todo o trabalho quando você utiliza OPTIMIZE TABLE. Veja mais informações sobre isto na Seção 4.6.1, “Sintaxe de OPTIMIZE TABLE.

myisamchk também tem um número de outras opção que podem ser usadas para melhorar a performance de uma tabela:

  • -S, --sort-index

  • -R index_num, --sort-records=index_num

  • -a, --analyze

Para uma descrição completa da opção. Veja mais informações sobre isto na Seção 4.5.6.1, “Sintaxe do myisamchk.

4.5.7. Configurando um Regime de Manutenção das Tabelas

A partir do MySQL Versão 3.23.13, você pode conferir tabelas MyISAM com o comando CHECK TABLE. Veja mais informações sobre isto na Seção 4.5.4, “Sintaxe de CHECK TABLE. Você pode reparar tabelas com o comando REPAIR TABLE. Veja mais informações sobre isto na Seção 4.5.5, “Sintaxe do REPAIR TABLE.

É uma boa idéia verificar as tabelas regularmente em vez de esperar que ocorram problemas. Para propósitos de manutenção você pode utilizar o myisamchk -s para verificar as tabelas. A opção -s (abreviação de --silent) faz com que o myisamchk execute em modo silencioso, exibindo mensagens somente quando ocorrem erros.

É também uma boa idéia verificar as tabelas quando o servidor inicia. Por exemplo, sempre que a máquina reinicia no meio de uma atualização, você normalmente precisará conferir todas as tabelas que podem ter sido afetadas. (Isto é uma``tabela com falhas esperadas''.) Você pode adicionar um teste ao mysqld_safe que executa myisamchk para conferir todas tabelas que foram modificadas durante as últimas 24 horas se existir um arquivo .pid (process ID) antigo depois do último reboot. (O arquivo .pid é criado pelo mysqld quando ele inicia e removido quando ele termina normalmente. A presença de um arquivo .pid durante a inicialização do sistema indica que o mysqld terminou de forma anormal.)

Um teste ainda melhor seria verificar qualquer tabela cuja a data da última modificação é mais recente que a do arquivo .pid.

Você também deve verificar suas tabelas regularmente durante a operação normal do sistema. Na MySQL AB, nós executamos uma tarefa agendada cron para conferir todas nossas tabelas importantes uma vez por semana utilizando uma linha com esta no arquivo crontab:

35 0 * * 0 /diretório/do/myisamchk --fast --silent /diretório/de/dados/*/*.MYI

Isto mostra informações sobre tabelas com falhas para que possamos examiná-las e repará-las quando necessário.

Como nós não estamos tendo tabelas com falhas inesperadas (tabelas corrompidas por razões diferentes de problemas de hardware) por vários anos (isto realmente é verdade), uma vez por semana é mais que suficiente para nós.

Nós recomendamos que para iniciar, você execute myisamchk -s a cada noite em todas as tabelas que foram atualizadas durantes as últimas 24 horas, até que você confie no MySQL como nós confiamos.

Normalmente você não precisará de tanta manutenção em suas tabelas MySQL. Se você estiver alterando tabelas com registros de tamanho dinâmico (tabelas com colunas VARCHAR, BLOB ou TEXT) ou tem tabelas com vários registros apagados você pode desejar de tempos em tempos (uma vez ao mês?) desfragmentar/recuperar espaço das tabelas.

Você pode fazer isto utilizando OPTIMIZE TABLE nas tabelas em questão ou se você puder desligar o servidor mysqld por um tempo faça:

isamchk -r --silent --sort-index -O sort_buffer_size=16M */*.ISM
myisamchk -r --silent --sort-index -O sort_buffer_size=16M */*.MYI

4.5.8. Obtendo Informações sobre as Tabelas

Para obter uma descrição de uma tabela ou estatísticas sobre ela, utilize os comandos mostrados abaixo, nós explicaremos algumas das informações em mais detalhes posteriormente:

  • myisamchk -d nome_tabela Executa o myisamchk no ``modo descritivo'' para produzir uma descrição de sua tabela. Se você iniciar o servidor MySQL utilizando a opção --skip-locking, myisamchk pode relatar um erro para uma tabela que está sendo atualizada enquanto é executado. Entretanto, como o myisamchk não altera a tabela no modo de descrição, não existem riscos de destruição de dados.

  • myisamchk -d -v nome_tabela Para produzir mais informações sobre o que myisamchk está fazendo, adicione -v para solicitar a execução em modo verbose.

  • myisamchk -eis nome_tabela Exibe somente as informações mais importantes de uma tabela. Ele é lento porque é necessário ler a tabela inteira.

  • myisamchk -eiv nome_tabela Isto se parece com -eis, mas lhe diz o que está sendo feito.

Exemplo da saída de myisamchk -d

MyISAM file: company.MYI
Record format: Fixed length
Data records: 1403698 Deleted blocks: 0
Recordlength: 226
table description:
Key Start Len Index Type
1 2 8 unique double
2 15 10 multip. text packed stripped
3 219 8 multip. double
4 63 10 multip. text packed stripped
5 167 2 multip. unsigned short
6 177 4 multip. unsigned long
7 155 4 multip. text
8 138 4 multip. unsigned long
9 177 4 multip. unsigned long
193 1 text

Exemplo da saída de myisamchk -d -v :

MyISAM file: company
Record format: Fixed length
File-version: 1
Creation time: 1999-10-30 12:12:51
Recover time: 1999-10-31 19:13:01
Status: checked
Data records: 1403698 Deleted blocks: 0
Datafile parts: 1403698 Deleted data: 0
Datafilepointer (bytes): 3 Keyfile pointer (bytes): 3
Max datafile length: 3791650815 Max keyfile length: 4294967294
Recordlength: 226
table description:
Key Start Len Index Type Rec/key Root Blocksize
1 2 8 unique double 1 15845376 1024
2 15 10 multip. text packed stripped 2 25062400 1024
3 219 8 multip. double 73 40907776 1024
4 63 10 multip. text packed stripped 5 48097280 1024
5 167 2 multip. unsigned short 4840 55200768 1024
6 177 4 multip. unsigned long 1346 65145856 1024
7 155 4 multip. text 4995 75090944 1024
8 138 4 multip. unsigned long 87 85036032 1024
9 177 4 multip. unsigned long 178 96481280 1024
193 1 text

Exemplo da saída de myisamchk -eis:

Checking MyISAM file: company
Key: 1: Keyblocks used: 97% Packed: 0% Max levels: 4
Key: 2: Keyblocks used: 98% Packed: 50% Max levels: 4
Key: 3: Keyblocks used: 97% Packed: 0% Max levels: 4
Key: 4: Keyblocks used: 99% Packed: 60% Max levels: 3
Key: 5: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 6: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 7: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 8: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 9: Keyblocks used: 98% Packed: 0% Max levels: 4
Total: Keyblocks used: 98% Packed: 17%
Records: 1403698 M.recordlength: 226
Packed: 0%
Recordspace used: 100% Empty space: 0%
Blocks/Record: 1.00
Record blocks: 1403698 Delete blocks: 0
Recorddata: 317235748 Deleted data: 0
Lost space: 0 Linkdata: 0
User time 1626.51, System time 232.36
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 627, Swaps 0
Blocks in 0 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 639, Involuntary context switches 28966

Exemplo da saída de myisamchk -eiv:

Checking MyISAM file: company
Data records: 1403698 Deleted blocks: 0
- check file-size
- check delete-chain
block_size 1024:
index 1:
index 2:
index 3:
index 4:
index 5:
index 6:
index 7:
index 8:
index 9:
No recordlinks
- check index reference
- check data record references index: 1
Key: 1: Keyblocks used: 97% Packed: 0% Max levels: 4
- check data record references index: 2
Key: 2: Keyblocks used: 98% Packed: 50% Max levels: 4
- check data record references index: 3
Key: 3: Keyblocks used: 97% Packed: 0% Max levels: 4
- check data record references index: 4
Key: 4: Keyblocks used: 99% Packed: 60% Max levels: 3
- check data record references index: 5
Key: 5: Keyblocks used: 99% Packed: 0% Max levels: 3
- check data record references index: 6
Key: 6: Keyblocks used: 99% Packed: 0% Max levels: 3
- check data record references index: 7
Key: 7: Keyblocks used: 99% Packed: 0% Max levels: 3
- check data record references index: 8
Key: 8: Keyblocks used: 99% Packed: 0% Max levels: 3
- check data record references index: 9
Key: 9: Keyblocks used: 98% Packed: 0% Max levels: 4
Total: Keyblocks used: 9% Packed: 17%
- check records and index references
[LOTS OF ROW NUMBERS DELETED]
Records: 1403698 M.recordlength: 226 Packed: 0%
Recordspace used: 100% Empty space: 0% Blocks/Record: 1.00
Record blocks: 1403698 Delete blocks: 0
Recorddata: 317235748 Deleted data: 0
Lost space: 0 Linkdata: 0
User time 1639.63, System time 251.61
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 10580, Swaps 0
Blocks in 4 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 10604, Involuntary context switches 122798

Aqui estão os tamanhos dos arquivos de dados e índices para a tabela utilizada nos exemplos anteriores:

-rw-rw-r-- 1 monty tcx 317235748 Jan 12 17:30 company.MYD
-rw-rw-r-- 1 davida tcx 96482304 Jan 12 18:35 company.MYM

Explicações para os tipos de informações que o myisamchk produz são fornecidas abaixo. O ``keyfile'' é o arquivo de índices. ``Registro'' e ``linha'' são sinônimos:

  • ISAM file Nome do arquivo (índice) ISAM.

  • Isam-version Versão do formato ISAM. Atualmente sempre 2.

  • Creation time Quando o arquivo de dados foi criado.

  • Recover time Quando foi a última vez que o arquivo de índices/dados foi reconstruído.

  • Data records Quantos registros existem na tabela.

  • Deleted blocks Quantos blocos apagados continuam alocando espaço. Você pode otimizar sua tabela para minimizar este espaço. Veja mais informações sobre isto na Seção 4.5.6.10, “Otimização de Tabelas”.

  • Datafile: Parts Para formato de registros dinâmicos, isto indica quantos blocos de dados existem. Para uma tabela otimizada sem registros fragmentados, isto é o mesmo que Data records.

  • Deleted data Quantos bytes de dados deletados não recuperados existem. Você pode otimizar sua tabela para minimizar este espaço. Veja mais informações sobre isto na Seção 4.5.6.10, “Otimização de Tabelas”.

  • Data file pointer O tamanho do ponteiro do arquivo de dados, em bytes. Ele normalmente possui 2, 3, 4 ou 5 bytes. A maioria das tabelas trabalham com 2 bytes, mas isto ainda não pode ser controlado pelo MySQL ainda. Para tabelas fixas, isto é um endereço de registro. Para tabelas dinâmicas, isto é um endereço de byte.

  • Keyfile pointer O tamanho de um ponteiro de arquivo de índices, em bytes. Ele normalmente possui 1, 2 ou 3 bytes. A maioria das tabelas trabalham com 2 bytes, mas isto é calculado automaticamente pelo MySQL. Ele é sempre um endereço de bloco.

  • Max datafile length Qual tamanho o arquivo de dados (arquivos .MYD) pode atingir, em bytes.

  • Max keyfile length Qual tamanho o arquivo de índices (.MYI pode atingir, em bytes.

  • Recordlength Quanto espaço cada registro ocupa, em bytes.

  • Record format O formato utilizado para armazenar as linhas da tabelas. Os exemplos anteriores abaixo utilizam Fixed length (tamanho fixo). Outros valores possíveis são Compressed(compactado) e Packed(empacotado).

  • table description Uma lista de todas as chaves na tabela. Para cada chave, alguma informação de baixo nível é apresentada:

    • Key

      O Número desta chave.

    • Start

      Onde, no registro, esta parte do índice inicia.

    • Len

      Qual o tamanho desta parte do índice. Para números empacotados, isto deve sempre ser o tamanho total da coluna. Para strings, deve ser mais curto que o tamanho total da coluna indexada, porque você pode indexar um prefixo de uma coluna string.

    • Index

      unique ou multip. (multiplos). Indica se um valor pode ou não exisitir várias vezes neste índice.

    • Type

      Que tipo de dados esta parte do índice tem. Isto é um tipo de dados ISAM com as opções packed, stripped ou empty.

    • Root

      Endereço do bloco de índice raiz.

    • Blocksize

      O tamanho de cada bloco de índice. O tamanho padrão é 1024, mas o valor pode ser alterado na compilação.

    • Rec/key

      Este é um valor estatístico utilizado pelo otimizador. Ele diz quantos registros existem por valor para esta chave. Uma chave única sempre tem um valor de 1. Ele pode ser atualizado depois que uma tabela é carregada (ou muito alterada) com myisamchk -a. Se isto não for completamente atualizado, um valor padrão de 30 é fornecido.

  • No primeiro exemplo acima, a nona chave é uma chave multi partes com duas partes.

  • Keyblocks used Qual o percentual de bloco de chaves são usados. Como a tabela usada nos exemplos foi reorganizada com myisamchk, os valores são muito altos (muito próximos do máximo teórico).

  • Packed O MySQL tenta empacotar chaves com um sufixo comum. Isto pode ser usado somente para chaves CHAR/VARCHAR/DECIMAL. Para strings grandes como nomes, isto pode reduzir significativamente o espaço utilizado. No terceiro exemplo acima, a quarta chave possui 10 caracteres e uma redução de 60% no espaço é obtida.

  • Max levels Qual a profundidade da árvore-B para esta chave. Grandes tabelas com chaves longas resultam em valores altos.

  • Records Quantos registros existem na tabela.

  • M.recordlength A média de tamanho do registro. Para tabelas com registros de tamanho fixo, isto é o tamanho exato do registro.

  • Packed O MySQL corta espaços do final de strings. O valor Packed indica o percentual de economia alcançado fazendo isto.

  • Recordspace used Qual percentual do arquivo de dados é usado.

  • Empty space Qual percetual do arquivo de dados não é usado.

  • Blocks/Record Número médio de blocos por registro (isto é, de quantos links um registro fragmentado é composto). Sempre será 1 para tabelas de formato fixo. Este valor deve permanecer o mais próximo possível de 1.0. Se ele aumentar, você pode reorganizar a tabela com myisamchk. Veja mais informações sobre isto na Seção 4.5.6.10, “Otimização de Tabelas”.

  • Recordblocks Quantos blocos (links) são utilizados. Para formatos fixos, este é o mesmo que o número de registros.

  • Deleteblocks Quantos blocos (links) foram excluídos.

  • Recorddata Quantos bytes no arquivo de dados são usados.

  • Deleted data Quantos bytes no arquivo de dados foram apagados (sem uso).

  • Lost space Se um registro é atualizado para um tamanho menor, algum espaço é perdido. Isto é a soma de todas estas perdas, em bytes.

  • Linkdata Quando o formato de tabela dinâmica é utilizado, fragmentos de registros são ligados com ponteiros (4 a 7 bytes cada). Linkdata é a soma do montante de armazenamento utilizado por todos estes ponteiros.

Se uma tabela foi compactada com myisampack, mysiamchk -d mostra informações adicionais sobre cada coluna da tabela. Veja Seção 4.8.4, “myisampack, O Gerador de Tabelas Compactadas de Somente Leitura do MySQL”, para um exemplo desta informação e uma descrição do que ela significa.