14.4. El motor de almacenamiento BDB (BerkeleyDB)

MySQL 5.0

previous page next page

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 . Se incluye soporte para en distribuciones fuentes de MySQL y en distribuciones binarias MySQL-Max .

Las tablas pueden tener una gran probabilidad de sobrevivir a fallos del sistema y ser capaces de realizar y en transacciones. La distibución fuente MySQL incluye una distribución preparada para funcionar con MySQL. No puede usar una versión de 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 , 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 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 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

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 , pero ocurre el siguiente error cuando arranca mysqld, significa que 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 o arrancar el servidor con la opción .

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 .)

Si compila MySQL de las fuentes, puede activar soporte ejecutando configure con la opción 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 []

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 :

  • Directorio base para tablas . Debe ser el mismo directorio que use para .

  • El método de bloqueo . El valor debe ser , , , o .

  • El directorio del fichero de log .

  • No arranca Berkeley DB en modo recuperación.

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

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

  • El directorio de ficheros temporales de .

  • Desactiva el motor de almacenamiento .

  • Vuelca síncronamente los logs . Esta opción está activada por defecto ; use para desactivarla.

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

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

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

Con la variable , puede especificar el máximo número de bloqueos que pueden estar activos en una tabla . 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 y 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 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 almacena la definición de tabla, y un fichero contiene los datos de tabla e índices.

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

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

es sinónimo de en la opción o .

El motor de almacenamiento 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 se efectúan inmediatamente y no pueden deshacerse.

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

    Puede comenzar una transacción con el comando para suspender autocommit, o con para desactivar autocommit explícitamente.

Consulte Sección 13.4.1, “Sintaxis de , y ”.

El motor de almacenamiento tiene las siguientes características:

  • En MySQL 5.0, las tablas 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 en cada tabla para que cada registro pueda identificarse unívocamente. Si no crea una explícitamente, MySQL crea y mantiene una 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 o .

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

    Este comportamiento es similar al de , 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 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 , esto sólo puede hacerse si las columnas son parte del mismo índice.

  • El escaneo secuencial es más lento que para tablas ya que los datos en tablas 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 . En otras palabras, la información clave ocupa más espacio en tablas en comparación con .

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

  • es lento para tablas , 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 . Si no realiza muchos comandos o , 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 o . Consulte Sección 13.5.2.1, “Sintaxis de ” y Sección 13.5.2.5, “Sintaxis de ”.

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

  • funciona en tablas como con otras tablas. Si no usa , 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 mantiene ficheros de log. Para máximo rendimiento puede usar la opción para guardar los logs en un disco distinto al que tiene las bases de datos.

  • MySQL realiza un checkpoint cada vez que se comienza un nuevo fichero log , y borra cualquier fichero de log no necesario para transacciones actuales. Puede usar 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, 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 pueda causar un rollback automático y cualquier lectura puede fallar con un error de deadlock.

  • Si obtiene un disco entero con una tabla , obtiene un error (probablemente error 28) y la transacción debe deshacerse. Esto contrasta con tablas 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 a la vez puede ser muy lento. Si va a usar tablas no debe tener una caché de tabla muy grande (por ejemplo, con tamaño superior a 256) y debe usar la opción cuando use el cliente mysql .

  • no proporciona alguna información para tablas : 

    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 :

  • Cada tabla almacena en el fichero 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 de un directorio de base de datos a otro.

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

  • Si una columan que permite valores tiene un índice único, sólo un se permite un valor . 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 no soporta el antiguo formato de log: 

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

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

  • Si el modo autocommit está desactivado y borra una tabla 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 excepto con el modo autocommit activado. (La forma de arreglarlo no es trivial.)

previous page start next page