| |
Поддержка для таблиц 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Это не фатально, но я не рекомендую проводить такие эксперименты над Вашей системой, пока эта проблема не будет исправлена разработчиками.
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |