Поддержка для таблиц BDB включена в исходники MySQL начиная с версии 3.23.34 и активизирована в двоичной версии MySQL-Max.
BerkeleyDB, доступные по адресу
http://www.sleepycat.com обеспечивают MySQL транзакционным драйвером
таблицы. Используя BerkeleyDB, Ваши таблицы могут иметь большую возможность
выживания после сбоев, а также обеспечивать COMMIT и
ROLLBACK на транзакциях. В дистрибутив исходников MySQL входит
комплект исходников BDB с несколькими патчами для обеспечения работы с MySQL.
Непропатченную версию BDB использовать вместе с MySQL нельзя.
Если Вы загрузили двоичную версию MySQL, которая включает поддержку для BerkeleyDB, надо просто следовать командам для установки двоичной версии MySQL. Подробности в разделе "4.7.5 mysqld-max, расширенный сервер mysqld".
Чтобы компилировать MySQL с поддержкой Berkeley DB, загрузите MySQL
Version 3.23.34 или более новую и сконфигурируйте MySQL с
опцией --with-berkeley-db. Подробности в разделе
"2.3 Установка исходников MySQL".
cd /path/to/source/of/mysql-3.23.34 ./configure --with-berkeley-db
Пожалуйста, обратитесь к руководству, предоставленному дистрибутивом
BDB для получения более подробной информации.
Даже при том, что Berkeley DB сам по себе очень проверен и надежен, интерфейс с MySQL все еще рассматривается в качестве бета-версии. Но он активно улучшается и отлаживается.
Если Вы работаете с AUTOCOMMIT=0, изменения в таблицах
BDB не будут восприниматься, пока Вы не выполните
COMMIT. Вместо этого можно выполнить ROLLBACK,
чтобы забыть Ваши изменения.
Если Вы работаете с AUTOCOMMIT=1 (значение по умолчанию),
Ваши изменения будут совершены немедленно. Вы можете запустить расширенную
транзакцию с помощью вызова SQL BEGIN WORK, после которой Ваши
изменения не будут внесены в таблицу до тех пор, пока Вы не выполните
COMMIT (или ROLLBACK для отмены изменений).
Следующие параметры mysqld могут использоваться, чтобы
изменить поведение BDB таблиц:
| Опция | Что она делает |
--bdb-home=directory | Базовый каталог для таблиц BDB. Может совпадать с именем, указанным в --datadir. |
--bdb-lock-detect=# | Определение блокировок по Berkeley. Допустимы значения: DEFAULT, OLDEST, RANDOM или YOUNGEST. |
--bdb-logdir=directory | Каталог для файлов протоколирования Berkeley DB. |
--bdb-no-sync | Не синхронизировать сброс протоколов. |
--bdb-no-recover | Не запускать Berkeley DB в режиме восстановления. |
--bdb-shared-data | Запускать Berkeley DB в
многопроцессном режиме (не используйте DB_PRIVATE при
установке Berkeley DB). |
--bdb-tmpdir=directory | Имя временного файла Berkeley DB. |
--skip-bdb | Не использовать поддержку berkeley db. |
-O bdb_max_lock=1000 | Установить максимальное
число допустимых блокировок. Подробности в разделе
"4.5.5.4 Синтаксис SHOW VARIABLES
". |
Если Вы использовали опцию --skip-bdb, MySQL не будет
инициализировать библиотеку Berkeley DB, что лишит возможности использовать
таблицы BDB, но зато сэкономит немало памяти.
Обычно Вы должны запустить mysqld без опции
--bdb-no-recover, если Вы предполагаете использовать
BDB-таблицы. Это, однако, может создавать Вам проблемы, когда Вы пробуете
запускать mysqld, если BDB журналы разрушены.
С помощью опции bdb_max_lock Вы можете определять
максимальное число блокировок (10000 по умолчанию), которые можно иметь
активными на BDB-таблице. Вы должны увеличить это число, если получаете
ошибки типа bdb: Lock table is out of available locks или
Got error 12 from ..., когда Вы делаете длинные транзакции, или
если mysqld должен исследовать очень много строк, чтобы
вычислить результат запроса.
Вы можете также изменять binlog_cache_size и
max_binlog_cache_size, если Вы используете большие транзакции.
BDB
--bdb_log_dir.
FLUSH LOGS в любое время для
создания контрольной точки таблицы Berkeley DB. Для восстановления нужно
использовать копии таблицы плюс двоичный файл регистрации MySQL. Подробности
в разделе "4.4.1 Резервирование баз данных".
Предупреждение: Если Вы удаляете старые журналы, которые
еще находятся в использовании, BDB не будет способен делать восстановление
вообще, и Вы можете потерять данные, если что-то пойдет неправильно.
PRIMARY KEY в каждой BDB-таблице, чтобы
предварительно читать строки. Если Вы не создаете ключ, MySQL сам создаст
поддерживающий скрытый PRIMARY KEY для Вас. Скрытый ключ имеет
длину 5 байт и будет увеличен для каждой попытки вставки.
BDB,
представляют собой часть того же самого индекса или части первичного ключа,
то MySQL может выполнять запрос без того, чтобы обращаться к фактической
строке. В таблице MyISAM вышеупомянутое верно только, если
столбцы представляют собой часть того же самого индекса.
PRIMARY KEY будет быстрее, чем любой другой ключ, поскольку
PRIMARY KEY сохранен вместе с данными строки. Поскольку другие
ключи сохранены как данные ключа+PRIMARY KEY, важно держать
PRIMARY KEY максимально коротким, что сэкономит место на диске.
LOCK TABLES работает на таблицах BDB так же,
как и с другими таблицами. Если Вы не используете LOCK TABLE,
MYSQL выдаст внутреннюю блокировку многократной записи на таблице, чтобы
гарантировать, что таблица будет правильно блокирована, если другой процесс
выдает блокировку таблицы.
BDB выполнена
на уровне страницы.
SELECT COUNT(*) FROM table_name работает медленно на
таблицах BDB, поскольку BDB таблицы не поддерживают счетчик
числа строк в таблице.
MyISAM,
поскольку данные в BDB-таблицах, сохранены в B-деревьях, а не в
отдельном файле данных.
BDB может вызвать автоматическую
обратную перемотку, а любое чтение может терпеть неудачу с ошибкой тупика.
BDB в сравнении с соответствующими таблицами MyISAM,
которые не используют PACK_KEYS=0.
DELETE или ROLLBACK, это число должно быть
достаточно точным для оптимизатора MySQL, но поскольку MySQL сохраняет его
только на завершении, может быть неправильно, если MySQL свалится неожиданно.
Не должно быть фатально, если это число не 100%-но правильно. Можно
модифицировать число строк выполнением ANALYZE TABLE или
вызовом OPTIMIZE TABLE.
BDB, Вы
получите ошибку (вероятно, ошибку с кодом 28), и транзакция должна быть
отменена. Это отличие от таблиц MyISAM и ISAM, где
mysqld будет ждать достаточного свободного места на диске перед
продолжением выполнения транзакции.--no-auto-rehash
при вызове клиентов mysql. Планируется исправить к версии 4.0.
SHOW TABLE STATUS не обеспечивает много полезной информации
для BDB-таблиц.
Если Вы, сформировав MySQL с поддержкой для BDB-таблиц, получаете
следующую ошибку в журнале, когда Вы запускаете mysqld:
bdb: architecture lacks fast mutexes: applications cannot be threaded Can't init dtabases
Это означает, что таблицы BDB пока не поддержаны для Вашей
архитектуры. В этом случае Вы должны восстановить MySQL без поддержки таблиц
BDB.
ОБРАТИТЕ ВНИМАНИЕ: следующий список не полон, разработчики его модифицируют, поскольку получают большое количество информации о проблемах.
На сегодняшний день таблицы BDB работают под следующими ОС:
На сегодняшний день таблицы BDB НЕ работают под следующими ОС:
hostname.err при запуске mysqld:
bdb: Ignoring log file: .../log.XXXXXXXXXX: unsupported log version #Это означает, что новая версия
BDB не поддерживает старый формат
журнала. В этом случае Вы должны удалить протоколы BDB из Вашего
каталога баз данных (файлы, которые имеют имена в формате
log.XXXXXXXXXX) и перезапустить mysqld. Советую
также выполнить для Ваших старых BDB-таблиц команду
mysqldump --opt, удалить их и восстановить из дампа.
auto_commit и удаляете
таблицу, используемую другим процессом, Вы можете получать следующие
сообщения об ошибках в файле регистрации ошибок 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Это не фатально, но я не рекомендую проводить такие эксперименты над Вашей системой, пока эта проблема не будет исправлена разработчиками.