Spec-Zone .ru
спецификации, руководства, описания, API
|
InnoDB 1.1 включает несколько проверок, чтобы принять меры против возможных катастрофических отказов и повреждений данных, которые могли бы произойти, если Вы выполняете более старый выпуск сервера MySQL на файлах данных InnoDB, используя более новый формат файла. Эти проверки имеют место, когда сервер запускается, и когда Вы сначала получаете доступ к таблице. Этот раздел описывает эти проверки, как можно управлять ими, и ошибкой и предупреждением условий, что мог бы возникнуть.
Соображения обратной совместимости только применяются при использовании недавней версии InnoDB (Плагин InnoDB, или MySQL 5.5 и выше с InnoDB 1.1) рядом с более старым (MySQL 5.1 или ранее, со встроенным InnoDB, а не Плагином InnoDB). Чтобы минимизировать шанс проблем совместимости, можно стандартизировать на Плагине InnoDB для всего Вашего MySQL 5.1 и более ранних серверов баз данных.
Вообще, более новая версия InnoDB может составить таблицу или индексировать, который не может безопасно быть считан или записан с предыдущей версией InnoDB без риска катастрофических отказов, зависает, неправильно результаты или повреждения. InnoDB 1.1 включает механизм, чтобы принять меры против этих условий, и помочь сохранить совместимость среди файлов базы данных и версий InnoDB. Этот механизм позволяет Вам использовать в своих интересах некоторые новые функции выпуска InnoDB (такие как улучшения производительности и исправления ошибок), и все еще сохранять опцию использования Вашей базы данных с предыдущей версией InnoDB, предотвращая случайное использование новых функций, которые создают нисходящие несовместимые дисковые файлы.
Если версия InnoDB поддерживает определенный формат файла (является ли тот формат значением по умолчанию), можно запросить и обновить любую таблицу, которая требует что формат или более ранний формат. Только создание новых таблиц, использующих новые функции, ограничивается основанное на определенном включенном формате файла. Наоборот, если табличная область содержит таблицу, или индексируйте, который использует формат файла, который не поддерживается в настоящий момент рабочим программным обеспечением, к ней нельзя получить доступ вообще, даже для доступа для чтения.
Единственный способ "понизить" табличную область
InnoDB к более раннему формату файла состоит в том, чтобы скопировать данные в новую таблицу в табличной
области, которая использует более ранний формат. Это может быть сделано с ALTER TABLE
оператор, как описано в Разделе
5.4.7.4, "Понижая Формат файла".
Самый легкий способ определить формат файла существующей табличной области InnoDB состоит в том, чтобы
исследовать свойства таблицы, которую это содержит, используя SHOW TABLE STATUS
команда или запросы таблицы INFORMATION_SCHEMA.TABLES
. Если Row_format
из таблицы сообщается как 'Compressed'
или 'Dynamic'
,
табличная область, содержащая таблицу, использует формат Барракуды. Иначе, это использует предшествующий формат
файла InnoDB, Антилопу.
Каждый InnoDB табличная область на таблицу (представленный a *.ibd
файл), файл
маркируется идентификатором формата файла. Системная табличная область (представленный ibdata
файлы), тегируется с "самым высоким" форматом
файла в использовании в группе файлов базы данных InnoDB, и этот тег проверяется, когда файлы открываются.
Составление сжатой таблицы, или таблицы с ROW_FORMAT=DYNAMIC
, обновляет заголовок
файла для соответствия .ibd
файл и таблица вводят словарь данных InnoDB с
идентификатором для формата файла Барракуды. От той точки вперед, таблица не может использоваться с версией
InnoDB, который не поддерживает этот новый формат файла. Защищать от аномального поведения, версии 5.0.21 InnoDB
и позже выполняет проверку совместимости, когда таблица открывается. (Во многих случаях, ALTER TABLE
оператор воссоздает таблицу и таким образом изменяет ее свойства.
Особый случай добавления или отбрасывания индексирует, не восстанавливая таблицу, описывается в
Чтобы избежать беспорядка, в целях этого обсуждения, мы даем определение слову "ib-файл набора", чтобы означать набор файлов операционной системы, которыми InnoDB управляет как модуль. Набор ib-файла включает следующие файлы:
Системная табличная область (один или больше ibdata
файлы), которые содержат внутреннюю информацию о системе (включая внутренние каталоги и отменяют
информацию), и может включать пользовательские данные и индексирует.
Нуль или больше одно-табличных табличных областей (также вызванный "файл на таблицу" файлы, названные *.ibd
файлы).
Файлы журнала InnoDB; обычно два, ib_logfile0
и ib_logfile1
. Используемый для восстановления катастрофического отказа и в
резервных копиях.
"Набор ib-файла" не включает соответствие .frm
файлы, которые содержат метаданные о таблицах InnoDB. .frm
файлы создаются и управляются MySQL, и могут иногда выходить из синхронизации с
внутренними метаданными в InnoDB.
Многократные таблицы, даже больше чем от одной базы данных, могут быть сохранены в единственном "наборе ib-файла". (В MySQL "база данных" является логическим набором таблиц, что другие системы именуют как "схема" или "каталог".)
Чтобы предотвратить возможные катастрофические отказы или повреждения данных, когда InnoDB открывает набор
ib-файла, он проверяет, что может полностью поддерживать форматы файлов в использовании в пределах набора
ib-файла. Если система перезапускается после катастрофического отказа, или "быстрого завершения работы" (то есть, innodb_fast_shutdown
больше чем нуль), могут быть дисковые структуры
данных (такие как восстановление или отменить записи, или doublewrite страницы), которые находятся в "также новом" формате для текущего
программного обеспечения. Во время процесса восстановления серьезный ущерб может быть нанесен Вашим файлам
данных, если к этим структурам данных получают доступ. Проверка запуска формата файла происходит прежде, чем
любой процесс восстановления начинается, таким образом предотвращая проблемы непротиворечивости с новыми
таблицами или проблемами запуска для сервера MySQL.
Начинаясь с версии, InnoDB 1.0.1, системная табличная область записывает идентификатор или тег для "самого высокого" формата файла, используемого
любой таблицей в любой из табличных областей, которая является частью набора ib-файла. Проверками против
этого тега формата файла управляет параметр конфигурации innodb_file_format_check
, который является ON
по умолчанию.
Если тег формата файла в системной табличной области более нов или выше чем самая высокая версия,
поддерживаемая определенным в настоящий момент выполняющимся программным обеспечением и если innodb_file_format_check
ON
, следующая
ошибка выпускается, когда сервер запускается:
InnoDB: Error: the system tablespace is in afile format that this version doesn't support
Можно также установить innodb_file_format
к имени формата файла. Выполнение так препятствует тому,
чтобы InnoDB запустился, если текущее программное обеспечение не поддерживает определенный формат файла. Это
также устанавливает "метку паводка" в
значение, которое Вы определяете. Возможность установить innodb_file_format_check
будет полезно (с будущими выпусками InnoDB),
если Вы вручную "понизите" все таблицы в
наборе ib-файла (как описано в
При некоторых ограниченных обстоятельствах Вы могли бы хотеть запустить сервер и использовать набор
ib-файла, который находится в "слишком новом" формате (тот, который не поддерживается
программным обеспечением, которое Вы используете). Если Вы устанавливаете параметр конфигурации innodb_file_format_check
к OFF
, InnoDB открывает базу данных, но выпускает это предупреждающее сообщение
в журнале ошибок:
InnoDB: Warning: the system tablespace is in afile format that this version doesn't support
Это - очень опасная установка, поскольку она разрешает процессу восстановления работать,
возможно повреждая Вашу базу данных, если предыдущее завершение работы было катастрофическим отказом или
"быстрым завершением работы". Следует
только установить innodb_file_format_check
к OFF
если Вы
уверены, что предыдущее завершение работы было сделано с innodb_fast_shutdown=0
, так, чтобы по существу никакой процесс
восстановления не произошел. В будущем выпуске эта установка параметра может быть переименована от OFF
к UNSAFE
. (Однако, до есть более новые
выпуски InnoDB, которые поддерживают дополнительные форматы файлов, даже отключая проверку запуска
фактически "безопасен".)
Параметр innodb_file_format_check
влияет только, что происходит, когда база данных открывается, не впоследствии. Наоборот, параметр innodb_file_format
(который включает определенному формату), только определяет, может ли новая таблица быть составлена во
включенном формате и не имеет никакого эффекта на то, может ли база данных быть открыта.
Тег формата файла является "меткой паводка",
и как таковой, он увеличивается после того, как сервер запускается, если таблица в "более высоком" формате составляется, или к существующей
таблице получают доступ для чтения или записи (предполагающий, что ее формат поддерживается). Если Вы
получаете доступ к существующей таблице в формате выше чем формат, рабочее программное обеспечение
поддерживает, системный тег табличной области не обновляется, но проверка совместимости на уровне таблицы
применяется (и ошибка выпускается), как описано в Разделе
5.4.7.2.2, "Проверка совместимости, Когда Таблица Открывается". Любое время метка паводка
обновляется, значение innodb_file_format_check
обновляется также, таким образом, команда SELECT @@innodb_file_format_check;
выводит на экран имя новейшего формата
файла, который, как известно, использовался таблицами в в настоящий момент открытом наборе ib-файла и
поддерживаться в настоящий момент выполняющимся программным обеспечением.
Чтобы лучше всего иллюстрировать это поведение, считайте сценарий описанным в Таблице 5.7, "Совместимость Файла данных InnoDB и Связанные Параметры InnoDB". Предположите, что некоторая будущая версия InnoDB поддерживает формат Гепарда и что набор ib-файла использовался с той версией.
Таблица 5.7. Совместимость Файла данных InnoDB и Связанные Параметры InnoDB
проверка формата файла innodb | формат файла innodb | Самый высокий формат файла используется в установленном ib-файле | Самый высокий формат файла поддерживается InnoDB | Результат |
---|---|---|---|---|
OFF |
Antelope или Barracuda |
Barracuda |
Barracuda |
База данных может быть открыта; таблицы могут быть составлены, которые требуют формата файла Антилопы или Барракуды |
OFF |
Antelope или Barracuda |
Cheetah |
Barracuda |
База данных может быть открыта с предупреждением, так как база данных содержит файлы в "слишком новом" формате; таблицы могут быть составлены в формате файла Антилопы или Барракуды; к таблицам в формате Гепарда нельзя получить доступ |
OFF |
Cheetah |
Barracuda |
Barracuda |
База данных не может быть открыта; innodb_file_format не может быть установлен в Гепарда
|
ON |
Antelope или Barracuda |
Barracuda |
Barracuda |
База данных может быть открыта; таблицы могут быть составлены в формате файла Антилопы или Барракуды |
ON |
Antelope или Barracuda |
Cheetah |
Barracuda |
База данных не может быть открыта, так как база данных содержит файлы в "слишком новом" формате (Гепард) |
ON |
Cheetah |
Barracuda |
Barracuda |
База данных не может быть открыта; innodb_file_format не может быть установлен в Гепарда
|
Когда к таблице сначала получают доступ, InnoDB (включая некоторые выпуски до InnoDB 1.0) проверяет, что формат файла табличной области, в которой сохранена таблица, полностью поддерживается. Эта проверка предотвращает катастрофические отказы или повреждения, которые иначе произошли бы, когда с таблицами, используя "слишком новую" структуру данных встречаются.
Все таблицы, используя любой формат файла, поддерживаемый выпуском, могут быть считаны или записаны
(принятие, что у пользователя есть достаточные полномочия). Установка параметра конфигурации системы innodb_file_format
может предотвратить составление новой таблицы, которая использует определенные форматы файлов, даже если они
поддерживаются данным выпуском. Такая установка могла бы использоваться, чтобы сохранить обратную
совместимость, но это не предотвращает доступ к любой таблице, которая использует любой поддерживаемый
формат.
Как отмечено в Именованных Форматах файлов, версии MySQL, более старого чем 5.0.21, не могут достоверно использовать файлы базы данных, создаваемые более новыми версиями, если новый формат файла использовался, когда таблица была составлена. Чтобы предотвратить различные состояния ошибки или повреждения, InnoDB проверяет совместимость формата файла, когда это открывает файл (например на первый доступ к таблице). Если в настоящий момент рабочая версия InnoDB не поддерживает формат файла, идентифицированный таблицей, вводят словарь данных InnoDB, MySQL сообщает о следующей ошибке:
ERROR 1146 (42S02): Table 'test
.t1
' doesn't exist
InnoDB также пишет сообщение в журнал ошибок:
InnoDB: tabletest
/t1
: unknown table type33
Табличный тип должен быть равным флагам табличной области, который содержит версию формата файла как обсуждено в Разделе 5.4.7.3, "Идентифицируя Формат файла в Использовании".
Версии InnoDB до MySQL 4.1 не включали идентификаторы формата таблицы в файлы базы данных, и версии до MySQL 5.0.21 не включали проверку совместимости формата таблицы. Поэтому, нет никакого способа гарантировать правильное функционирование, если таблица в "слишком новом" формате используется с версиями InnoDB до 5.0.21.
Возможность управления форматом файла в InnoDB 1.0 и выше (тегирование табличной области и проверки на этапе выполнения) позволяет InnoDB проверять как можно скорее, что рабочая версия программного обеспечения может должным образом обработать таблицы, существующие в базе данных.
Если Вы разрешаете InnoDB открывать базу данных, содержащую файлы в формате, он не поддерживает
(устанавливая параметры innodb_file_format_check
к OFF
), проверка на
уровне таблицы, описанная в этом разделе все еще, применяется.
Пользователей строго убеждают не использовать файлы базы данных, которые содержат таблицы формата файла Барракуды с выпусками InnoDB, более старого чем MySQL 5.1 с Плагином InnoDB. Возможно "понизить" такие таблицы к формату Антилопы с процедурой, описанной в Разделе 5.4.7.4, "Понижая Формат файла".