Spec-Zone .ru
спецификации, руководства, описания, API
|
Это - хорошая практика, чтобы поддержать Ваши данные прежде, чем установить любую новую версию программного обеспечения. Хотя MySQL очень работает усиленно, чтобы гарантировать высокий уровень качества, защитите свои данные, делая резервное копирование.
Чтобы обновить до 5.7 от любой предыдущей версии, MySQL рекомендует, чтобы Вы вывели свои таблицы с
mysqldump прежде, чем обновить и перезагрузили файл
дампа после обновления. Используйте --all-databases
опция, чтобы включать все базы данных в дамп. Если Ваши
базы данных включают сохраненные программы, используйте --routines
и --events
опции также.
Вообще, сделайте следующий, обновляя от MySQL 5.6 до 5.7:
Считайте все элементы в этих разделах, чтобы видеть, мог ли бы какой-либо из них влиять на Ваши приложения:
У раздела 2.11.1, "MySQL Upgrading", есть общая информация об обновлении.
Элементы в списках изменения, обеспеченных позже в этом разделе, позволяют Вам идентифицировать проблемы обновления, которые применяются к Вашей текущей установке MySQL. Некоторые несовместимости, обсужденные там, требуют Вашего внимания перед обновлением. С другими нужно иметь дело после обновления.
Обратите внимание особенно на любые изменения, которые отмечаются Известная
проблема или Несовместимое изменение. Эти
несовместимости с более ранними версиями 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 содержит большой объем данных, который мог бы занять много времени, чтобы
преобразовать после оперативного обновления, Вы могли бы счесть полезным создать "фиктивный" экземпляр базы данных для того, чтобы оценить, какие
преобразования могли бы быть необходимы и работа, включенная, чтобы выполнить их. Сделайте копию своего
экземпляра MySQL, который содержит полную копию mysql
база данных, плюс все другие
базы данных без данных. Выполните свою процедуру обновления на этом фиктивном экземпляре, чтобы видеть, какие
действия могли бы быть необходимы так, чтобы можно было лучше оценить работу, включенную, выполняя фактическое
преобразование данных на Вашем исходном экземпляре базы данных.
Считайте все элементы в следующих разделах, чтобы видеть, мог ли бы какой-либо из них влиять на Ваши приложения:
Несовместимое изменение: Несколько
изменений были произведены в контрольном плагине журнала для лучшей совместимости с Хранилищем Аудита
Oracle. Для того, чтобы обновить цель, главный вопрос - то, что формат контрольного файла журнала
изменился: информация в пределах <AUDIT_RECORD>
элементы ранее
записанные атрибуты использования теперь пишутся, используя подэлементы.
Пример старых <AUDIT_RECORD>
формат:
<AUDIT_RECORD TIMESTAMP="2013-04-15T15:27:27" NAME="Query" CONNECTION_ID="3" STATUS="0" SQLTEXT="SELECT 1"/>
Пример нового формата:
<AUDIT_RECORD> <TIMESTAMP>2013-04-15T15:27:27 UTC</TIMESTAMP> <RECORD_ID>3998_2013-04-15T15:27:27</RECORD_ID> <NAME>Query</NAME> <CONNECTION_ID>3</CONNECTION_ID> <STATUS>0</STATUS> <STATUS_CODE>0</STATUS_CODE> <USER>root[root] @ localhost [127.0.0.1]</USER> <OS_LOGIN></OS_LOGIN> <HOST>localhost</HOST> <IP>127.0.0.1</IP> <COMMAND_CLASS>select</COMMAND_CLASS> <SQLTEXT>SELECT 1</SQLTEXT></AUDIT_RECORD>
Если Вы ранее использовали более старую версию контрольного плагина журнала, используйте эту процедуру, чтобы избежать писать записи журнала нового формата в существующий файл журнала, который содержит записи старого формата:
Остановите сервер.
Переименуйте текущий контрольный файл журнала вручную. Этот файл будет содержать только записи журнала старого формата.
Обновите сервер и перезапустите его. Контрольный плагин журнала создаст новый файл журнала, который будет содержать только записи журнала нового формата.
Для получения информации о контрольном плагине журнала см. Раздел 6.3.11, "Плагин Журнала Аудита MySQL Enterprise".
Некоторые ключевые слова могут быть зарезервированы в MySQL 5.7, которые не были зарезервированы в MySQL 5.6. См. Раздел 9.3, "Зарезервированные слова".