Sleepycat Software fournit à MySQL le moteur de stockage transactionnel Berkeley DB. Ce moteur est généralement appelée BDB. Le support des tables BDB est inclus par la distribution des sources de MySQL à partir de la version 3.23.34 et est activé dans le binaire MySQL-Max. En utilisant les tables DBD, vos tables ont plus de chances de survivre aux crashs, et vous avez accès à COMMIT et ROLLBACK avec les transactions. La distribution des sources de MySQL fournit une distribution corrigée de BDB pour lui permettre de fonctionner d'une fa¸on plus souple avec MySQL. Vous pouvez utiliser une version non-patchée de BDB avec MySQL. Nous travaillons chez MySQL AB en coopération étroite avec Sleepycat pour garantir une bonne qualité d'interface MySQL/BDB. Même si Berkeley DB est très surveillée et fiable, l'interface MySQL est considérée de qualité Gamma. Nous y travaillons et l'optimisons. Lorsqu'ils utilisent les tables BDB, nous aiderons nos utilisateurs à trouver les problèmes et à créer des batteries de tests reproductibles pour tout problème ayant trait aux tables BDB. De tels tests seront aussi envoyés à Sleepycat qui nous aidera aussi à trouver et résoudre les problèmes. Vu qu'il s'agit d'une collaboration à deux niveaux, les problèmes concernant les tables BDB prendront un peu plus de temps à être résolus en comparaison avec les autres gestionnaires de tables. Toutefois, étant donné que le code de BerkeleyDB a lui-même été utilisé par plusieurs autres applications à part MySQL, nous n'envisageons pas de rencontrer de gros problèmes avec. Pour des informations générales sur Berkeley DB, visitez le site de Sleepycat Web, http://www.sleepycat.com/.

 

Systèmes d'exploitation supportés par BDB
Actuellement, nous savons que le gestionnaire BDB fonctionne avec les systèmes d'exploitation suivants :
Linux 2.x Intel
Sun Solaris (SPARC et x86)
FreeBSD 4.x/5.x (x86, sparc64)
IBM AIX 4.3.x
SCO OpenServer
SCO UnixWare 7.1.x
Il ne fonctionne pas sur les systèmes d'exploitations suivants :
Linux 2.x Alpha
Linux 2.x AMD64
Linux 2.x IA64
Linux 2.x s390
Max OS X
Note :
La liste ci-dessus n'est pas complète; nous la mettrons à jour au fur et à mesure que nous recevrons des informations à ce propos. Si, après avoir compilé MySQL avec le support des tables BDB tables, obtenez l'erreur suivante dans le fichier de logs quand vous démarrez mysqld : bdb: architecture lacks fast mutexes: applications cannot be threaded Can't init dtabases Cela signifie que les tables BDB ne sont pas supportées par votre architecture. Dans ce cas, vous devez recompiler MySQL sans le support des tables BDB.

 

Installation de BDB
Si vous avez téléchargé une version binaire de MySQL qui inclut le support de BerkeleyDB, vous n'avez qu'à suivre les instructions classiques (MySQL-Max inclut le support BDB). Si vous compilez MySQL depuis les sources, vous pouvez activer le support BDB en ajoutant au script configure l'option --with-berkeley-db en plus des autres options que vous avez. Téléchargez la distribution de MySQL 3.23.34 ou plus récent, allez dans la racine des sources, et tapez : Pour plus d'informations, voyez Section 2.3, « Installer MySQL sur d'autres systèmes type Linux », Section , « mysqld-max, la version étendue du serveur mysqld » et See Section , « Installation de MySQL avec une distribution source ».

 

Options de démarrage BDB
Les options suivantes de mysqld peuvent être utilisées pour modifier le comportement des tables BDB : Répertoire de base des tables BDB. Cela doit être le même répertoire que vous avez utilisés pour --datadir.
Détection des verrouillages Berkeley. (DEFAULT, OLDEST, RANDOM, ou YOUNGEST).
Répertoire des fichiers de log de Berkeley DB. Ne pas démarrer Berkeley DB en mode de restauration. Ne pas vider les tampons synchroniquement. Démarrer Berkeley DB en mode multi-processus (Ne pas utiliser DB_PRIVATE lors de l'initialisation de Berkeley DB) Répertoire des fichiers temporaires de Berkeley DB. Désactive l'utilisation des tables BDB. voir Section , « Options de ligne de commande de mysqld ». Les variables systèmes suivante affectent le comportement des tables BDB :
bdb_max_lock Le nombre maximal de verrous actifs sur une table BDB. See Section 5.2.3, « Variables serveur système ». Si vous utilisez --skip-bdb, MySQL n'initialisera pas la bibliothèque Berkeley DB et cela économisera beaucoup de mémoire. Bien sûr, vous ne pouvez pas utiliser les table BDB si vous utilisez cette option. Si vous essayez de créer une table BDB, MySQL créera une table MyISAM à la place. Normalement, vous devez démarrer mysqld sans --bdb-no-recover si vous avez l'intention d'utiliser des tables BDB. Cela peut cependant vous poser des problèmes si vous essayez de démarrer mysqld alors que des fichiers de log BDB sont corrompus. See Section 2.5.2.3, « Problèmes de démarrage du serveur MySQL ». Vous pouvez spécifier le nombre maximal de verrous avec bdb_max_lock (10000 par défaut) que vous pouvez activer sur une table BDB. Vous devez l'augmenter si vous obtenez des erreurs du type : bdb: Lock table is out of available locks Got error 12 from ... lorsque vous avez fait de longues transactions ou quand mysqld doit examiner beaucoup de lignes pour calculer la requête. Vous pouvez aussi changer les options binlog_cache_size et max_binlog_cache_size si vous utilisez de grandes transactions multi-lignes. See Section 5.9.4, « Le log binaire ».

 

Caractéristiques des tables BDB
Chaque table BDB est stocké sur le disque en deux fichiers. Les fichiers portent le nom de la table, et ont des extensions qui indiquent le type de fichier. Un fichier .frm stocke la définition de la table, et le fichier .db contient les données et les index. Pour spécifier explicitement que vous voulez une table BDB, indiquez l'option de création de table ENGINE ou TYPE : BerkeleyDB est un synonyme de BDB pour les options ENGINE et TYPE. Le moteur de tables BDB fournit un modèle transactionnel. La fa¸on dont vous utilisez ces tables dépend du mode de validation :
Si vous utilisez le mot d'auto-validation (ce qui est le mode par défaut), les modifications dans les tables BDB sont validées immédiatement, et ne peuvent pas être annulées.
Si vous utilisez le mode de validation manuel, les modifications ne seront rendues permanentes que si vous envoyez la commande COMMIT. AU lieu de valider, vous pouvez aussi annuler avec la commande ROLLBACK pour détruire les modifications. Vous pouvez démarrer une transaction avec la commande BEGIN WORK pour suspendre le mode d'auto-validation, ou avec SET AUTOCOMMIT=0 pour le désactiver explicitement. voir Section , « Syntaxes de START TRANSACTION, COMMIT et ROLLBACK ». Le moteur de tables BDB a les caractéristiques suivantes :
Les tables BDB peuvent avoir jusqu'à 31 index par table, 16 colonnes par index, et un taille maximale de 1024 octets par index (500 octets avant MySQL 4.0).
MySQL requiert une clé PRIMARY KEY dans chaque table BDB pour être capable de faire référence aux lignes précédemment lues. Si vous n'en créez pas, MySQL va gérer une telle clé de manière cachée. La clé cachée a une taille de 5 octets, et est incrémentée à chaque nouvelle insertion.
La clé PRIMARY KEY sera plus rapide que n'importe quelle autre clé, car la PRIMARY KEY est stockée avec les données. Comme les autres clés sont stockées sous la forme données + PRIMARY KEY, il est important de garder une clé PRIMARY KEY aussi courte que possible pour économiser de l'espace disque, et améliorer la vitesse. Ce comportement est similaire à celui d'InnoDB, où des clés primaires courtes économisent de l'espace pour la clé primaire et pour les index secondaire aussi.
Si toutes les colonnes auxquelles vous accédez dans une table BDB font partie du même index dans la clé primaire, alors MySQL peut exécuter la requête sans avoir à lire la ligne elle-même. Dans une tableMyISAM, ce qui précède n'est valable que si les colonnes font partie du même index.
Scanner séquentiellement est plus lent qu'avec MyISAM car les tables BDB stockent les données dans un fichier B-tree et non pas dans un fichier séparé.
Les clés ne sont pas compressées avec les clés précédentes, comme pour les tables ISAM et MyISAM. En d'autres termes, les informations de clés prennent un peu plus d'espace pour les tables BDB, comparativement aux tables MyISAM qui n'utilisent pas l'option PACK_KEYS=0.
Il y a souvent des trous dans les tables BDB pour vous permettre d'insérer de nouvelles lignes au milieu de l'arbre de données. Cela rend les tables BDB un peu plus grandes que les tables MyISAM.
SELECT COUNT(*) FROM table_name est très lent, car les tables BDB ne maintiennent pas un compte de leur lignes dans la table.
L'optimiseur a besoin de connaître une approximation du nombre de lignes dans la table. MySQL résout ce problème en comptant les insertions et en conservant ce compte dans un segment séparé pour chaque table BDB. Si vous ne faites pas souvent de DELETE ou ROLLBACK, ce nombre sera plutôt précis pour l'optimiseur MySQL, mais comme MySQL ne stocke ce nombre qu'à la fermeture de la table, il peut être incorrecte si MySQL s'interrompt inopinément. Cela ne doit pas être fatal si ce nombre n'est pas à 100% correct. Vous pouvez forcer la mise à jour de ce nombre avec la commande ANALYZE TABLE ou OPTIMIZE TABLE. Section 13.5.2.1, « Syntaxe de ANALYZE TABLE » . Section 13.5.2.5, « Syntaxe de OPTIMIZE TABLE ».
Le verrouillage interne des tables BDB est fait au niveau page.
LOCK TABLES fonctionne avec les tables BDB sur les autres tables. Si vous n'utilisez pas le verrou LOCK TABLE, MySQL va poser un verrou interne multiple sur la table, pour s'assurer que la table est bien verrouillée, si un autre thread tente de poser un verrou.
Pour permettre les annulations de transaction, BDB gère un fichier de log. Pour maximiser les performances, vous devriez placer ces fichiers sur un autre disque que celui de votre base, en utilisant l'option --bdb-logdir.
MySQL fait un point de contrôle à chaque fois qu'un nouveau fichier de log BDB est démarré, et supprime les fichiers de logs anciens qui ne sont pas utiles. Si vous exécutez la commande FLUSH LOGS, vous placerez un nouveau point de contrôle pour les tables Berkeley DB. Pour la restauration après crash, vous devez utiliser les sauvegardes et le log binaire de MySQL. See Section 5.7.1, « Sauvegardes de base de données ».
Attention : si vous effacez les anciens fichiers de log qui sont en cours d'utilisation, BDB ne sera pas capable de faire la restauration et vous risquez de perdre des données.
L'application doit toujours être prête à gérer des cas où une modification sur une table BDB peut être annulée, ou une lecture abandonnée pour cause de blocage de verrous.
Si vous atteignez la capacité maximale du disque avec la table BDB, vous allez obtenir une erreur (probablement l'erreur 28), et la transaction va s'annuler. C'est un comportement différent des tables MyISAM et ISAM qui vont attendre que mysqld ait trouvé de l'espace disque avant de continuer.

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