XOOPS Brasil

 

7.6. Tabelas BDB ou BerkeleyDB

7.6.1. Visão Geral de Tabelas BDB

BerkeleyDB, disponível em http://www.sleepycat.com/ tem provido o MySQL com um mecanismo de armazenamento transacional. O suporte para este mecanismo de armazenamento está incluído na distribuição fonte do MySQL a partir da versão 3.23.34 e está ativo no binário do MySQL-Max. Este mecanismo de armazenamento é chamado normalmente de BDB.

Tabelas BDB podem ter maior chance de sobrevivência a falhas e também são capazes de realizar operações COMMIT e ROLLBACK em transações. A distribuição fonte do MySQL vem com uma distribuição BDB que possui alguns pequenos patchs para faze-lo funcionar mais suavemente com o MySQL. Você não pode usar uma versão BDB sem estes patchs com o MySQL.

Na MySQL AB, nós estamos trabalhando em cooperação com a Sleepycat para manter a alta qualidade da interface do MySQL/BDB.

Quando trouxemos o suporte a tabelas BDB, nos comprometemos a ajudar os nosso utilizadores a localizar o problema e criar um caso de teste reproduzível para qualquer problema envolvendo tabelas BDB. Tais casos de teste serão enviados a Sleepycat que nos ajudará a encontrar e arrumar o problema. Como esta é uma operação de dois estágios, qualquer problema com tabelas BDB podem levar um tempo um pouco maior para ser resolvido do que em outros mecanismos de armazenamento. De qualquer forma, como o código do BerkeleyDB tem sido usado em autras aplicações além do MySQL, nós não vemos nenhum grande problema com isto. Veja mais informações sobre isto na Seção 1.4.1, “Suporte Oferecido pela MySQL AB”.

7.6.2. Instalando BDB

Se você tiver feito o download de uma versão binária do MySQL que inclui suporte a BerkeleyDB, simplesmente siga as instruções de instalação de uma versão binária do MySQL. Veja mais informações sobre isto na Seção 2.2.9, “Instalando uma Distribuição Binária do MySQL”. Veja mais informações sobre isto na Seção 4.8.5, “mysqld-max, om servidor mysqld extendido”.

Para compilar o MySQL com suporte a BerkeleyDB, faça o download do MySQL versão 3.23.34 ou mais novo e configure MySQL com a opção --with-berkeley-db. Veja mais informações sobre isto na Seção 2.3, “Instalando uma distribuição com fontes do MySQL”.

cd /path/to/source/of/mysql-3.23.34
./configure --with-berkeley-db

Por favor, de uma olhada no manual fornecido com a distribuição BDB para informações mais atualizadas.

Mesmo sendo o BerkeleyDB muito testado e confiável, a interface com o MySQL ainda é considerada com qualidade gamma. Nós estamos ativamente melhorando e otimizando para torná-la estável o mais breve possível.

7.6.3. Opções de Inicialização do BDB

Se você estiver executando com AUTOCOMMIT=0 então as suas alterações em tabelas BDB não serão atualizadas até que você execute um COMMIT. No lugar de commit você pode executar um ROLLBACK para ignorar as suas alterações. Veja mais informações sobre isto na Seção 6.7.1, “Sintaxe de START TRANSACTION, COMMIT e ROLLBACK.

Se você estiver execuando AUTOCOMMIT=1 (padrão), será feito um commit das sua alterações imediatamente. Você pode iniciar uma transação estendida com o comando SQL BEGIN WORK, depois do qual não será feito commit de suas alterações ae que você execute COMMIT (ou faça ROLLBACK das alterações.)

As seguintes opções do mysqld podem ser usadas pa alterar o comportamento de tabelas BDB:

OpçãoDescrição
--bdb-home=directoryDiretório base das tabelas BDB. Ele deve ser o mesmo diretório usado para --datadir.
--bdb-lock-detect=#Detecção de travas de Berkeley. Pode ser (DEFAULT, OLDEST, RANDOM, ou YOUNGEST).
--bdb-logdir=directoryDiretório de arquivos log de Berkeley DB.
--bdb-no-syncNão sincroniza logs descarregados.
--bdb-no-recoverNão inicia Berkeley DB no modo de recuperação.
--bdb-shared-dataInicia Berkeley DB no modo de multi-processos (Não usa DB_PRIVATE ao inicializar Berkeley DB)
--bdb-tmpdir=directoryDiretorio de arquivos temporários do Berkeley DB.
--skip-bdbDisabilita o uso de tabelas BDB.
-O bdb_max_lock=1000Define o número máximo de travas possíveis. Veja mais informações sobre isto na Seção 4.6.8.4, “SHOW VARIABLES.

Se você utiliza --skip-bdb, MySQL não irá inicializar o biblioteca Berkeley DB e isto irá economizar muita memória. É claro que você não pode utilizar tabelas BDB se você estiver usando esta opção. Se você tentar criar uma tabela BDB, o MySQL criará uma tabela MyISAM.

Normalmente você deve iniciar mysqld sem --bdb-no-recover se você pretende usar tabelas BDB. Isto pode, no entanto, lhe trazer problemas quando você tentar iniciar o mysqld e os arquivos de log do BDB estiverem corrompidos. Veja mais informações sobre isto na Seção 2.4.2, “Problemas Inicializando o Servidor MySQL”.

Com bdb_max_lock você pode especificar o número mácimo de travas (10000 por padrão) que você pode tar ativas em uma tabela BDB. Você deve aumentá-lo se você obter um erro do tipo bdb: Lock table is out of available locks ou Got error 12 from ... quando você fizer transações longas ou quando mysqld tiver que examinar muitas linhas para calcular a consulta.

Você também pode desejar alterar binlog_cache_size e max_binlog_cache_size se você estiver usando transações multi-linhas. Veja mais informações sobre isto na Seção 6.7.1, “Sintaxe de START TRANSACTION, COMMIT e ROLLBACK.

7.6.4. Características de Tabelas BDB:

  • Para estar apto a fazer roolback da transação, o mecanismo de armazenamento BDB mantém arquivos de log. Para obter o máximo de desempenho você deve colocar estes arquivos em outro disco diferente do usado por seus bancos de dados usando a opção --bdb-logdir.

  • O MySQL realiza um ponto de verificação a cada vez que um novo arquivo de log do BDB é iniciado e remove qualquer arquivo de log que não for necessário para a transação atual. Pode se executar FLUSH LOGS a qualquer momento para faze um ponto de verificação de tabelas Berkeley DB.

    Para recuperação de desastres, deve-se usar backups de tabelas mais log binário do MySQL. Veja mais informações sobre isto na Seção 4.5.1, “Backups dos Bancos de Dados”.

    Aviso: Se você delatar arquivos de log antigos que estão em uso, o BDB não estará apto a fazer a recuperação e você pode perder dados se algo der errado.

  • O MySQL precisa de uma PRIMARY KEY em cada tabela BDB para poder fazer referência a linha lida anteriormente. Se você não criar um o MySQL criará uma chave primária oculta para você. A chave oculta tem um tamanho de 5 bytes e é incrementada a cada tentaiva de inserção.

  • Se todas as colunas que você acessa em uma tabela BDB são parte do mesmo índice ou parte de uma chave primária, então o MySQL pode executar a consulta ser ter que acessar a linha atual. Em uma tabela MyISAM o descrito acima é guardado apenas se as colunas são parte do mesmo índice.

  • A PRIMARY KEY será mais rápida que qualquer outra chave, já que a PRIMARY KEY é armazenada junto com o registro do dado. Como as outras chaves são armazenads como os dados da chave + a PRIMARY KEY, é importante manter a PRIMARY KEY o menor possível para economizar disco e conseguir maior velocidade.

  • LOCK TABLES funciona em tabelas BDB como nas outras tabelas. Se você não utilizar LOCK TABLE, MySQL comandará um bloqueio interno de múltipla-escrita nas tabelas para assegurar que a tabela será bloqueada apropriadamente se outra thread executar um bloqueio de tabela.

  • Bloqueios internos em tabelas BDB é feito por página.

  • SELECT COUNT(*) FROM nome_tabela é lento pois tabelas BDB não mantém um contador do número de linha na tabela.

  • A varredura sequencial é mais lenta que com tabelas MyISAM já que os dados em tabelas BDB são armazenados em árvores-B e não em um arquivo de dados separado.

  • A aplicação sempre deve estar preparada para tratar casos onde qualquer alteração de uma tabela BDB pode fazer um rollback automático e quqlquer leitura pode falhar com um erro de deadlock.

  • As chaves não são compactadas por prefixo ou por sufixo como em tabelas MyISAM. Em outras palavras, a informação da chave gastará um pouco mais de espaço em tabelas BDB quando comparadas a tabelas MyISAM.

  • Existem buracos frequentemente em tabelas BDB para permitir que você insira novas linhas no meio da árvore de chaves. Isto torna tabelas BDB um pouco maiores que tabelas MyISAM.

  • O otimizador precisa conhecer aproximadamente o número de linhas na tabela. O MySQL resolve isto contando inserções e mantendo isto em um segmento separado em cada tabela BDB. Se você não executar várias instruções DELETE ou ROLLBACK, este número deverá estar suficientemente próximo do exato para o otimizador do MySQL, mas como o MySQL só armazerna o número ao finalizar, ele pode estar incorreto se o MySQL finalizar inesperadamente. Isto não deve ser fatail mesmo se este número não for 100% correto. POde se atualizar o número de linhas executando ANALYZE TABLE ou OPTIMIZE TABLE. Veja mais informações sobre isto na Seção 4.6.2, “Sintaxe de ANALYZE TABLE . Veja mais informações sobre isto na Seção 4.6.1, “Sintaxe de OPTIMIZE TABLE.

  • Se você ficar com o seu disco cheio com uma tabela BDB, você obterá um erro (provavelmente erro 28) e deve ser feito um rollback da transação. Isto está em contraste com as tabelas MyISAM e ISAM onde o mysqld irá esperar por espaço suficiente em disco pra continuar.

7.6.5. Itens a serem corrigidos no BDB num futuro próximo:

  • É muito lento abrir muitas tabelas BDB ao mesmo tempo. Se você for utilizar tabelas BDB, você não deve ter um cache de tabela muito grande (> 256) e você deve usar --no-auto-rehash com o cliente mysql. Nós planejamos arrumar isto parcialmente na versãp 4.0.

  • SHOW TABLE STATUS ainda mão fornece muitas informações para tabelas BDB

  • Otimizar o desempenho.

  • Fazer com que não seja utilizado bloqueio de páginas quando varrermos a tabela.

7.6.6. Sistemas operacionais suportados pelo BDB

Atualmente sabemos que o mecanismo de armazenamento BDB funciona com os seguintes sistemas operacionais:

  • Linux 2.x Intel

  • Sun Solaris (sparc e x86)

  • FreeBSD 4.x/5.x (x86, sparc64)

  • IBM AIX 4.3.x

  • SCO OpenServer

  • SCO UnixWare 7.0.1

Ele não funciona com os seguintes sistemas operacionais.

  • Linux 2.x Alpha

  • Linux 2.x AMD64

  • Linux 2.x IA64

  • Linux 2.x s390

  • Max OS X

Nota: A lista acima não está completa; atualizaremos ela assim que recebermos mais informações.

Se você construir o MySQL como suporte a tabelas BDB e obter o seguinte erro no arquivo de log quando você iniciar o mysqld:

bdb: architecture lacks fast mutexes: applications cannot be threaded
Can't init dtabases

Isto significa que as tabelas BDB não são suportadas por sua arquitetura. Neste caso você deve reconstruir o MySQL sem o suporte a tabelas BDB.

7.6.7. Restrições em Tabelas BDB

Aqui segue as restrições que você tem quando utiliza tabelas BDB:

  • Tabelas BDB armazenam no arquivo .db o caminho para o arquivo no qual ela foi crada. (Isto foi feito para tornar possível detectar travas em um ambiente multi-utilizador que suporte links simbólicos)

    O efeito disto é que tabelas BDB não podem ser movidas entre diretórios!

  • Ao tirar backups de tabelas BDB, você pode utilizar mysqldump ou tirar backup de todos os arquivos nome_tabela.db e os arquivos de log do BDB. Os arquivos de log do BDB são os arquivos no diretório de dados base chamado log.XXXXXXXXXX (dez digitos); O mecanismo de armazenamento BDB guarda transações não terminadas em arquivos de log e exige que estes arquivos sejam apresentados quando o mysqld iniciar.

7.6.8. Erros Que Podem Ocorrer Usando Tabelas BDB

  • Se você obter o seguinte erro no log hostname.err ao iniciar o mysqld:

    bdb: Ignoring log file: .../log.XXXXXXXXXX: unsupported log version #
    

    significa que a nova versão BDB não suporta o formato do arquivo de log antigo. Neste caso você tem que deletar todos os logs BDB do seu diretório de banco de dados (o arquivo com nomes no formato log.XXXXXXXXXX) e reiniciar o mysqld. Também recomentdamos que você faça um mysqldump --opt de sua tabela BDB antiga, delete as tabelas antigas e restaure o dump.

  • Se você não estiver executando em modo auto-commit e deltar uma tabela que é referenciada em outra transação, você pode obter a seguinte mensagem de erro em seu log de erro do MySQL:

    001119 23:43:56 bdb: Missing log fileid entry
    001119 23:43:56 bdb: txn_abort: Log undo failed for LSN:
    1 3644744: Invalid
    

    Isto não é fatal mas não recomendamos deletar tabelas se não estiver no modo auto-commit, até que este problema seja resolvido (a solução não é trivial).