14.4. El motor de almacenamiento BDB (BerkeleyDB)

MySQL 5.0

14.4. El motor de almacenamiento `BDB` (`BerkeleyDB`)

Sleepycat Software ha proporcionado a MySQL el motor de almacenamiento transaccional Berkeley DB. A este motor de almacenamiento se le llama tradicionalmente BDB. Se incluye soporte para BDB en distribuciones fuentes de MySQL y en distribuciones binarias MySQL-Max .

Las tablas BDB pueden tener una gran probabilidad de sobrevivir a fallos del sistema y ser capaces de realizar COMMIT y ROLLBACK en transacciones. La distibución fuente MySQL incluye una distribución BDB preparada para funcionar con MySQL. No puede usar una versión de BDB no preparada para funcionar con MySQL.

En MySQL AB trabajamos codo a codo con Sleepycat para mantener la calidad de la interfaz MySQL/BDB . (Incluso aunque Berkeley DB está muy testeado y es muy fiable, la interfaz MySQL se considera de calidad gamma. Continuamos mejorando y optimizándola.)

Cuando hay algún problema con tablas BDB, ayudamos a nuestros usuarios a localizar el problema y reproducir casos de test. Cualquiera de estos casos de test se envía a Sleepycat, que nos ayuda a encontrar y arreglar el problema. Con esta operación de dos fases, cualquier problema con tablas BDB puede tardar un poco más en ser resuelto que con nuestros motores de almacenamiento. Sin embargo, no anticipamos dificultades significativas con este procedimiento ya que el código Berkeley DB se usa en muchas aplicaciones distintas a MySQL.

Para información general sobre Berkeley DB, visite el sitio web de Sleepycat , http://www.sleepycat.com/.

14.4.1. Sistemas operativos que soporta `BDB`

Actualmente, sabemos que el motor de almacenamiento BDB funcioina con los siguientes sistemas operativos:

Linux 2.x Intel
Sun Solaris (SPARC y x86)
FreeBSD 4.x/5.x (x86, sparc64)
IBM AIX 4.3.x
SCO OpenServer
SCO UnixWare 7.1.x
Windows NT/2000/XP

BDB no funciona con los siguientes sistemas operativos:

Linux 2.x Alpha
Linux 2.x AMD64
Linux 2.x IA-64
Linux 2.x s390
Mac OS X

Nota: La lista precedente no está completa. La actualizamos cuando tenemos más información.

Si compila MySQL de las fuentes con soporte para tablas BDB , pero ocurre el siguiente error cuando arranca mysqld, significa que BDB no está soportado por su arquitectura:

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

En este caso, debe recompilar MySQL sin soporte para tablas BDB o arrancar el servidor con la opción --skip-bdb .

14.4.2. Instalación de `BDB`

Si ha bajado una versión binaria de MySQL que incluya soporte para Berkeley DB, símplemente siga las instrucciones de instalación usuales. (Distribuciones MySQL-Max incluyen soporte BDB .)

Si compila MySQL de las fuentes, puede activar soporte BDB ejecutando configure con la opción --with-berkeley-db además de cualquier otra distribución que use normalmente. Descargue una distribución MySQL 5.0 , cambie la localización en su directorio más alto, y ejecute este comando:

shell> ./configure --with-berkeley-db [other-options]

Para más información consulte Sección 2.7, “Instalación de MySQL en otros sistemas similares a Unix”, Sección 5.1.2, “El servidor extendido de MySQL mysqld-max”, y Sección 2.8, “Instalación de MySQL usando una distribución de código fuente”.

14.4.3. Opciones de arranque de `BDB`

Las siguientes opciones de mysqld pueden usarse para cambiar el comportamiento del motor de almacenamiento BDB:

--bdb-home=path

Directorio base para tablas BDB . Debe ser el mismo directorio que use para --datadir.

--bdb-lock-detect=method

El método de bloqueo BDB . El valor debe ser DEFAULT, OLDEST, RANDOM, o YOUNGEST.

--bdb-logdir=path

El directorio del fichero de log BDB .

--bdb-no-recover

No arranca Berkeley DB en modo recuperación.

--bdb-no-sync

No vuelca síncronamente los logs BDB . Esta opción está obsolta; use --skip-sync-bdb-logs en su lugar (consulte la descripción de --sync-bdb-logs).

--bdb-shared-data

Arranca Berkeley DB en modo multi proceso. (No use DB_PRIVATE al inicializar Berkeley DB.)

--bdb-tmpdir=path

El directorio de ficheros temporales de BDB .

--skip-bdb

Desactiva el motor de almacenamiento BDB .

--sync-bdb-logs

Vuelca síncronamente los logs BDB . Esta opción está activada por defecto ; use --skip-sync-bdb-logs para desactivarla.

See Sección 5.3.1, “Opciones del comando mysqld”.

Si usa la opción --skip-bdb , MySQL no inicializa la biblioteca Berkeley DB library y esto ahorra mucha memoria. Sin embargo, si usa esta opción, no puede usar tablas BDB . Si trata de crear una tabla BDB , MySQL crea una tabla MyISAM en su lugar.

Normalmente, debe arrancar mysqld sin la opción --bdb-no-recover si quiere usar tablas BDB . Sin embargo, esto puede causar problemas cuando trata de arrancar mysqld si los ficheros de log de BDB están corruptos. Consulte Sección 2.9.2.3, “Arrancar y resolver problemas del servidor MySQL”.

Con la variable bdb_max_lock , puede especificar el máximo número de bloqueos que pueden estar activos en una tabla BDB . Por defecto son 10,000. Debe incrementar esto si ocurren errores como el siguiente cuando realiza transacciones largas o cuando mysqld tiene que examinar muchos registros para ejecutar una consulta:

bdb: Lock table is out of available locks Got error 12 from ...

Puede cambiar las variables binlog_cache_size y max_binlog_cache_size si usa transacciones de varios comandos muy largas. Consulte Sección 5.10.3, “El registro binario (Binary Log)”.

Consulte Sección 5.3.3, “Variables de sistema del servidor”.

14.4.4. Características de las tablas BDB

Cada tabla BDB se almacena en disco en dos ficheros. Los ficheros tienen nombres que comienzan con el nombre de la tabla y tienen una extensión para indicar el tipo de fichero. Un fichero .frm almacena la definición de tabla, y un fichero .db contiene los datos de tabla e índices.

Para especificar explícitamente que quiere una tabla BDB, indíquelo con una opición de tabla ENGINE o TYPE:

CREATE TABLE t (i INT) ENGINE = BDB; CREATE TABLE t (i INT) TYPE = BDB;

BerkeleyDB es sinónimo de BDB en la opción ENGINE o TYPE .

El motor de almacenamiento BDB proporciona tablas transaccionales. La forma de usar estas tablas depende del modo autocommit:

Si está ejecutando con autocommit activado (por defecto), los cambios en las tablas BDB se efectúan inmediatamente y no pueden deshacerse.

Si está ejecutando con autocommit desactivado, los cambios no son permanentes hasta que ejecuta un comando COMMIT . En lugar de hacer un commit puede ejecutar ROLLBACK para olvidar los cambios.

Puede comenzar una transacción con el comando BEGIN WORK para suspender autocommit, o con SET AUTOCOMMIT=0 para desactivar autocommit explícitamente.

Consulte Sección 13.4.1, “Sintaxis de START TRANSACTION, COMMIT y ROLLBACK”.

El motor de almacenamiento BDB tiene las siguientes características:

En MySQL 5.0, las tablas BDB pueden tener hasta 31 índices por tabla, 16 columnas por índice, y un máximo de tamaño de clave de 1024 bytes.

MySQL necesita una PRIMARY KEY en cada tabla BDB para que cada registro pueda identificarse unívocamente. Si no crea una explícitamente, MySQL crea y mantiene una PRIMARY KEY oculta. La clave oculta tiene una longitud de 5 bytes y se incrementa para cada intento de inserción. Esta clave no aparece en la salida de SHOW CREATE TABLE o DESCRIBE.

La PRIMARY KEY es más rápida que cualquier otro índice, ya que la PRIMARY KEY se almacena junto con los datos. Los otros índices se almacenan como los datos claves + la PRIMARY KEY, por lo que es importante mantener la PRIMARY KEY tan pequeña como sea posible para ahorrar espacio en disco y tener más velocidad.

Este comportamiento es similar al de InnoDB, donde las claves primarias pequeñas ahorran espacio no sólo en el índice primario sino también en índices secundarios.

Si todas las columnas a las que accede en una tabla BDB son parte del mismo índice o parte de la clave primaria, MySQL puede ejcutar la consulta sin tener que acceder al registro. En una tabla MyISAM , esto sólo puede hacerse si las columnas son parte del mismo índice.

El escaneo secuencial es más lento que para tablas MyISAM ya que los datos en tablas BDB se almacena en B-trees y no en un fichero de datos separado.

Los valores clave no tienen compresión de prefijo ni sufijo como los valores clave en tablas MyISAM . En otras palabras, la información clave ocupa más espacio en tablas BDB en comparación con MyISAM .

A menudo hay huecos en la tabla BDB que le permiten insertar nuevos registros en medio del árbol índice. Esto hace que las tablas BDB sean algo más grandes que las MyISAM.

SELECT COUNT(*) FROMtbl_name es lento para tablas BDB , ya que no se mantiene conteo de registros en la tabla.

El optimizador necesita saber el número aproximado de registros en la tabla. MySQL resuelve esto contando inerciones y manteniendo esto en un segmento separado en cada tabla BDB . Si no realiza muchos comandos DELETE o ROLLBACK , este número debe ser lo bastante adecuado para el optimizador MySQL . Sin embargo, MySQL almacena el número sólo al cerrar, así que puede ser incorrecto si el servidor termina inesperadamente. Puede que no sea fatal incluso si este número no es 100% correcto. Puede actualizar el contador de registros usando ANALYZE TABLE o OPTIMIZE TABLE. Consulte Sección 13.5.2.1, “Sintaxis de ANALYZE TABLE” y Sección 13.5.2.5, “Sintaxis de OPTIMIZE TABLE”.

Bloqueo interno en tablas BDB se realiza a nivel de páginas.

LOCK TABLES funciona en tablas BDB como con otras tablas. Si no usa LOCK TABLES, MySQL realiza un bloqueo interno de múltiple escritura en la tabla (un bloqueo que no bloquea otros escritores) para asegurar que la tabla está bloqueada apropiadamente si otro flujo realiza un bloqueo de tabla.

Para poder deshacer transacciones, el motor de almacenamiento BDB mantiene ficheros de log. Para máximo rendimiento puede usar la opción --bdb-logdir para guardar los logs BDB en un disco distinto al que tiene las bases de datos.

MySQL realiza un checkpoint cada vez que se comienza un nuevo fichero log BDB , y borra cualquier fichero de log BDB no necesario para transacciones actuales. Puede usar FLUSH LOGS en cualquier momento para hacer un checkpoint de tablas Berkeley DB.

Para recuperación de desastres, debe usar copias de seguridad de tablas más el log binario de MySQL. Consulte Sección 5.8.1, “Copias de seguridad de bases de datos”.

Atención: Si borra ficheros de log antiguos que estén en uso, BDB no es capaz de recuperar todo y puede perder datos si algo no va bien.

Las aplicaciones deben estar siempre preparadas para tratar casos donde cualquier cambio en una tabla BDB pueda causar un rollback automático y cualquier lectura puede fallar con un error de deadlock.

Si obtiene un disco entero con una tabla BDB , obtiene un error (probablemente error 28) y la transacción debe deshacerse. Esto contrasta con tablas MyISAM en las que mysqld espera a tener más espacio libre para continuar.

14.4.5. Temas pendientes de arreglo para BDB

Abrir muchas tablas BDB a la vez puede ser muy lento. Si va a usar tablas BDB no debe tener una caché de tabla muy grande (por ejemplo, con tamaño superior a 256) y debe usar la opción --no-auto-rehash cuando use el cliente mysql .

SHOW TABLE STATUS no proporciona alguna información para tablas BDB :

mysql> SHOW TABLE STATUS LIKE 'bdbtest'\G *************************** 1. row *************************** Name: bdbtest Engine: BerkeleyDB Version: 10 Row_format: Dynamic Rows: 154 Avg_row_length: 0 Data_length: 0 Max_data_length: 0 Index_length: 0 Data_free: 0 Auto_increment: NULL Create_time: NULL Update_time: NULL Check_time: NULL Collation: latin1_swedish_ci Checksum: NULL Create_options: Comment:

Optimizar rendimiento.

No use bloqueos de página para operaciones de escaneo de tabla..

14.4.6. Limitaciones en las tablas BDB

La siguiente lista muestra restricciones a tener en cuenta al usar tablas BDB :

Cada tabla BDB almacena en el fichero .db la ruta al fichero como si se hubiera creado. Esto se hizo para ser capaz de detectar bloqueos en un entorno multi usuario que soporte enlaces simbólicos. Como consecuencia, no es posible mover ficheros de tablas BDB de un directorio de base de datos a otro.

Al hacer copias de seguridad de tablas BDB, debe usar mysqldump o hacer una copia de seguridad que incluya los ficheros para cada tabla BDB (los ficheros .frm y .db ) así como los ficheros de log BDB . El motor de almacenamiento BDB almacena transacciones no acabadas en su log y las necesita cuando arranca mysqld . Los logs BDB son los ficheros en el directorio de datos con nombres de la forma log.XXXXXXXXXX (10 dígitos).

Si una columan que permite valores NULL tiene un índice único, sólo un se permite un valor NULL. Esto difiere de otros motores de almacenamiento.

14.4.7. Errores que pueden darse en el uso de tablas BDB

Si ocurre el siguiente error cuando arranca mysqld tras actualizar, significa que la nueva versión BDB no soporta el antiguo formato de log:

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

En este caso, debe borrar todos los logs BDB de su directorio de datos (los fichero con nombres que tienen el formato log.XXXXXXXXXX) y reinicie mysqld. También recomendamos que use mysqldump --opt para volcar las tablas BDB , borre las tablas, y las restaure del fichero de volcado.

Si el modo autocommit está desactivado y borra una tabla BDB referenciada por otra transacción, puede obtener un mensaje de error de la siguiente forma en el log de error 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

Esto no es fatal, pero hasta arreglar el problema, recomendamos que no borre tablas BDB excepto con el modo autocommit activado. (La forma de arreglarlo no es trivial.)

previous page start next page

14.4. El motor de almacenamiento BDB (BerkeleyDB)

MySQL 5.0