WebMoney:  WMZ Z294115950220  WMR R409981405661  WME E134003968233	Visa  4274 3200 2453 6495

7.5 Таблицы BDB или Berkeley_DB 7.5.1 Обзор таблиц BDB Поддержка для таблиц BDB включена в исходники MySQL начиная с версии 3.23.34 и активизирована в двоичной версии MySQL-Max. BerkeleyDB, доступные по адресу http://www.sleepycat.com обеспечивают MySQL транзакционным драйвером таблицы. Используя BerkeleyDB, Ваши таблицы могут иметь большую возможность выживания после сбоев, а также обеспечивать COMMIT и ROLLBACK на транзакциях. В дистрибутив исходников MySQL входит комплект исходников BDB с несколькими патчами для обеспечения работы с MySQL. Непропатченную версию BDB использовать вместе с MySQL нельзя. 7.5.2 Установка BDB Если Вы загрузили двоичную версию 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 все еще рассматривается в качестве бета-версии. Но он активно улучшается и отлаживается. 7.5.3 Опции запуска BDB Если Вы работаете с 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, если Вы используете большие транзакции. 7.5.4 Характеристики таблиц BDB Для поддержки транзакций обратной перемотки BDB поддерживает журналы. Для достижения максимальной эффективности Вы должны поместить их на другой диск, чем тот, на котором хранятся базы данных, используя параметр --bdb_log_dir. MySQL делает контрольную точку каждый раз, когда начат новый журнал BDB, и удаляет любые журналы, которые не необходимы для текущих (актуальных) транзакций. Можно также выполнять FLUSH LOGS в любое время для создания контрольной точки таблицы Berkeley DB. Для восстановления нужно использовать копии таблицы плюс двоичный файл регистрации MySQL. Подробности в разделе "4.4.1 Резервирование баз данных". Предупреждение: Если Вы удаляете старые журналы, которые еще находятся в использовании, BDB не будет способен делать восстановление вообще, и Вы можете потерять данные, если что-то пойдет неправильно. MySQL требует 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 может вызвать автоматическую обратную перемотку, а любое чтение может терпеть неудачу с ошибкой тупика. Ключи не сжаты на предыдущие ключи, как с таблицами ISAM или MyISAM. Другими словами, информация ключа будет занимать немного больше места в таблицах BDB в сравнении с соответствующими таблицами MyISAM, которые не используют PACK_KEYS=0. Имеются пропуски в таблице BDB, чтобы позволить Вам вставлять новые строки в середину дерева ключей. Это делает BDB-таблицы несколько больше, чем MyISAM-таблицы. Оптимизатор должен знать приближенные данные о числе строк в таблице. MySQL решает это, считая вставки и поддерживая соответствующие данные в отдельном сегменте в каждой BDB таблице. Если Вы не делаете много вызовов DELETE или ROLLBACK, это число должно быть достаточно точным для оптимизатора MySQL, но поскольку MySQL сохраняет его только на завершении, может быть неправильно, если MySQL свалится неожиданно. Не должно быть фатально, если это число не 100%-но правильно. Можно модифицировать число строк выполнением ANALYZE TABLE или вызовом OPTIMIZE TABLE. Если Вы получаете полный диск при работе таблицей BDB, Вы получите ошибку (вероятно, ошибку с кодом 28), и транзакция должна быть отменена. Это отличие от таблиц MyISAM и ISAM, где mysqld будет ждать достаточного свободного места на диске перед продолжением выполнения транзакции. 7.5.5 Некоторые вещи, которые планируется реализовать для BDB в ближайшем будущем Очень не спешит открывать много BDB-таблиц в то же самое время. Если Вы собираетесь использовать BDB-таблицы, Вы не должны иметь очень большой кэш таблиц (>256?), и Вы должны использовать --no-auto-rehash при вызове клиентов mysql. Планируется исправить к версии 4.0. SHOW TABLE STATUS не обеспечивает много полезной информации для BDB-таблиц. Оптимизировать эффективность. Не использовать блокировки страницы вообще, когда мы сканируем таблицы. 7.5.6 Операционные системы, поддерживающие таблицы типа BDB Если Вы, сформировав MySQL с поддержкой для BDB-таблиц, получаете следующую ошибку в журнале, когда Вы запускаете mysqld: bdb: architecture lacks fast mutexes: applications cannot be threaded Can't init dtabases Это означает, что таблицы BDB пока не поддержаны для Вашей архитектуры. В этом случае Вы должны восстановить MySQL без поддержки таблиц BDB. ОБРАТИТЕ ВНИМАНИЕ: следующий список не полон, разработчики его модифицируют, поскольку получают большое количество информации о проблемах. На сегодняшний день таблицы BDB работают под следующими ОС: Linux 2.x intel Solaris sparc SCO OpenServer SCO UnixWare 7.0.1 На сегодняшний день таблицы BDB НЕ работают под следующими ОС: Linux 2.x Alpha Max OS X 7.5.7 Ошибки, которые Вы можете получать, когда используете 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 Это не фатально, но я не рекомендую проводить такие эксперименты над Вашей системой, пока эта проблема не будет исправлена разработчиками.

Поиск На сайте В Яндексе