2.11.1.1. Обновление от MySQL 5.5 до 5.6

Считайте все элементы в этих разделах, чтобы видеть, мог ли бы какой-либо из них влиять на Ваши приложения:

Обратите внимание особенно на любые изменения, которые отмечаются Известная проблема или Несовместимое изменение. Эти несовместимости с более ранними версиями MySQL могут потребовать Вашего внимания прежде, чем Вы обновите. Наша цель состоит в том, чтобы избежать этих изменений, но иногда они необходимы, чтобы исправить проблемы, которые были бы хуже чем несовместимость между выпусками. Если какая-либо проблема обновления, применимая к Вашей установке, включает несовместимость, которая требует специальной обработки, следуйте инструкциям, данным в описании несовместимости. Иногда это включает дамп и перезагрузку таблиц, или использования оператора такой как CHECK TABLE или REPAIR TABLE.

Для дампа и инструкций перезагрузки, см. Раздел 2.11.4, "Восстанавливая или Восстанавливая Таблицы, или Индексирует". Любая процедура, которая включает REPAIR TABLE с USE_FRM опция должна быть сделана перед обновлением. Использование этого оператора с версией MySQL, отличающегося от того, используемого, чтобы составить таблицу (то есть, используя это после обновления), может повредить таблицу. См. Раздел 13.7.2.5,"REPAIR TABLE Синтаксис".

Прежде, чем обновить до новой версии MySQL, Раздел 2.11.3, "Проверяя Или Таблицы или Индексирует, Должен быть Восстановлен", чтобы видеть, были ли изменения к форматам таблицы или к наборам символов или сопоставлениям произведены между Вашей текущей версией MySQL и версией, до которой Вы обновляете. Раз так и эти изменения приводят к несовместимости между версиями MySQL, Вы должны будете обновить таблицы, на которые влияют, используя инструкции в Разделе 2.11.4, "Восстанавливая или Восстанавливая Таблицы или Индексируете".

После обновления до новой версии MySQL, выполненный mysql_upgrade (см. Раздел 4.4.7, "mysql_upgrade — Таблицы MySQL Check и Upgrade" ). Эта программа проверяет Ваши таблицы, и пытается восстановить их в случае необходимости. Это также обновляет Ваши таблицы предоставления, чтобы удостовериться, что у них есть текущая структура так, чтобы можно было использовать в своих интересах любые новые возможности. (Некоторые выпуски MySQL представляют изменения структуре таблиц предоставления, чтобы добавить новые полномочия или функции.)

mysql_upgrade не обновляет содержание таблиц справки. Для инструкций обновления см. Раздел 5.1.10, "Серверная Справка".

Если Вы выполняете MySQL Server на Windows, см. Раздел 2.3.7, "Обновляя MySQL на Windows".

Если Вы используете репликацию, см. Раздел 16.4.3, "Обновляя Установку Репликации", для информации об обновлении Вашей репликации устанавливают.

Начинаясь с MySQL 5.6.6, у нескольких параметров MySQL Server есть значения по умолчанию, которые отличаются от предыдущих выпусков. Побуждение для этих изменений должно обеспечить лучшую производительность из поля и уменьшать потребность в администраторе базы данных изменить настройки вручную. Эти изменения подвергаются возможной версии в будущих выпусках, поскольку мы получаем обратную связь.

В некоторых случаях у параметра есть различное статическое значение по умолчанию. В других случаях сервер автоизмеряет параметр при запуске, используя формулу, основанную на других связанных параметрах или конфигурации узла сервера, вместо того, чтобы использовать статическое значение. Например, установка для back_log теперь его предыдущее значение по умолчанию 50, скорректированный количеством, пропорциональным значению max_connections. Идея позади автокалибровки состоит в том, что, когда сервер имеет информацию в наличии, чтобы принять решение об установке параметра, вероятно, быть лучше чем фиксированное значение по умолчанию, это будет.

Следующая таблица суммирует изменения к значениям по умолчанию. Любой из них может быть переопределен, определяя явное значение при запуске сервера.

Относительно совместимости с предыдущими выпусками самые важные изменения:

Поэтому, если Вы обновляете существующую установку MySQL, уже не изменили значения этих параметров от их предыдущих значений по умолчанию, и обратная совместимость является беспокойством, можно хотеть явно установить эти параметры к их предыдущим значениям по умолчанию. Например, поместите эти строки в файл параметра сервера:

[mysqld]innodb_file_per_table=0innodb_checksum_algorithm=INNODBbinlog_checksum=NONE

Те настройки сохраняют совместимость следующим образом:

Несовместимое изменение: С MySQL 5.6 полнотекстовый stopword файл загружается и искал использование latin1 если character_set_server ucs2, utf16, utf16le, или utf32. Если какая-либо таблица была составлена с FULLTEXT индексирует, в то время как набор символов сервера был ucs2, utf16, utf16le, или utf32, восстановите это использующий этот оператор:

REPAIR TABLE tbl_name QUICK;

Несовместимое изменение: MySQL 5.6.11 и позже поддерживает CREATE TABLE ... [SUB]PARTITION BY ALGORITHM=n [LINEAR] KEY (...), который может использоваться, чтобы составить таблицу чей KEY разделение является совместимым с сервером MySQL 5.1 (n=1). (Ошибка #14521864, Ошибка #66462) Этот синтаксис не принимается MySQL 5.6.10 и ранее, хотя это поддерживается в MySQL 5.5, начинающемся с MySQL 5.5.31. mysqldump в MySQL 5.5.31 и более поздних выпусках MySQL 5.5 включает ALGORITHM опция, выводя таблицы, используя эту опцию, но окружает это условными комментариями, как это:

CREATE TABLE t1 (a INT)/*!50100 PARTITION BY KEY */ /*!50531 ALGORITHM = 1
                    */ /*!50100 ()      PARTITIONS 3 */

Импортируя дамп, содержащий такой CREATE TABLE операторы в MySQL 5.6.10 или более ранний сервер MySQL 5.6, имеющий версию комментарий не игнорируется, который вызывает синтаксическую ошибку. Поэтому, до импорта такого файла дампа, следует или изменить комментарии так, чтобы сервер MySQL 5.6 проигнорировал их (удаляя строку !50531 или замена этого с !50611, везде, где это происходит), или удалите их.

Это не проблема с файлами дампа, сделанными, используя MySQL 5.6.11 или позже, где ALGORITHM опция пишется, используя /*!50611 ... */.

Некоторые ключевые слова могут быть зарезервированы в MySQL 5.6, которые не были зарезервированы в MySQL 5.5. См. Раздел 9.3, "Зарезервированные слова".

YEAR(2) у типа данных есть определенные вопросы, которые следует рассмотреть прежде, чем хотеть использовать его. С MySQL 5.6.6, YEAR(2) осуждается. YEAR(2) столбцы в существующих таблицах обрабатываются как прежде, но YEAR(2) в новых или измененных таблицах преобразовываются в YEAR(4). Для получения дополнительной информации см. Раздел 11.3.4,"YEAR(2) Ограничения и Переходящий на YEAR(4)".

С MySQL 5.6.6 это явно отвергается, чтобы присвоить значение DEFAULT к хранимой процедуре или параметрам функции или сохраненным локальным переменным программы (например с a SET var_name = DEFAULT оператор). Это ранее не поддерживалось, или задокументировано столь же разрешенное, но отмечается как несовместимое изменение в случае, если существующий код inadvertantly использовал эту конструкцию. Остается допустимым присвоиться DEFAULT к системным переменным, как прежде, но присвоение DEFAULT к параметрам или локальным переменным теперь приводит к синтаксической ошибке.

После обновления до MySQL 5.6.6 или позже, существующие сохраненные программы, которые используют эту конструкцию, производят синтаксическую ошибку когда вызвано. Если mysqldump файл от 5.6.5 или ранее загружается в 5.6.6 или позже, сбои работы загрузки и влиял на сохраненные определения программы, должен быть изменен.

В MySQL, TIMESTAMP тип данных отличается нестандартными способами от других типов данных:

Те нестандартные поведения остаются значением по умолчанию для TIMESTAMP но с MySQL 5.6.6 осуждаются, и это предупреждение появляется при запуске:

[Warning] TIMESTAMP with implicit DEFAULT value is deprecated.Please use --explicit_defaults_for_timestamp server option (seedocumentation for more details).

Как обозначено предупреждением, чтобы выключить нестандартные поведения, включают новому explicit_defaults_for_timestamp системная переменная при запуске сервера. С этой включенной переменной, дескрипторы сервера TIMESTAMP следующим образом вместо этого:

Чтобы обновить серверы, используемые для репликации, обновите ведомые устройства сначала, тогда ведущее устройство. Репликация между ведущим устройством и ее ведомыми устройствами должна работать при условии, что все использование то же самое значение explicit_defaults_for_timestamp: