2.11.2. Понижение MySQL

2.11.2.1. Понижение к MySQL 5.6

Этот раздел описывает, что сделать, чтобы понизить к более старой версии MySQL в маловероятном случае что предыдущая версия, работавшая лучше чем новый.

Это всегда - хорошая идея сделать резервное копирование заранее, в случае, если упадок перестал работать и листы экземпляр в неприменимом состоянии.

Чтобы понизить между Общедоступностью (GA) версии состояния в пределах того же самого ряда выпуска, обычно Вы только устанавливаете новые двоичные файлы сверху старых и не производите изменений в базах данных.

Упадки между выпусками вехи (или от выпуска GA до выпуска вехи) в пределах того же самого ряда выпуска не поддерживаются, и можно встретиться с проблемами.

Следующие элементы формируют контрольный список вещей сделать всякий раз, когда Вы выполняете упадок:

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

В большинстве случаев можно переместить файлы формата MySQL и файлы данных между различными версиями GA на той же самой архитектуре, пока Вы остаетесь в пределах версий для той же самой серии выпуска MySQL.

Если Вы понижаете от одного ряда выпуска до другого, в табличных форматах хранения могут быть несовместимости. В этом случае используйте mysqldump, чтобы вывести Ваши таблицы перед понижением. После понижения перезагрузите файл дампа, используя mysql или mysqlimport, чтобы воссоздать Ваши таблицы. Для примеров см. Раздел 2.11.5, "Копирование MySQL Databases to Another Machine".

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

Остановите более старый сервер MySQL, к которому Вы понижаете.
Перезапустите более новый сервер MySQL, от которого Вы понижаете.
Выведите любые таблицы, которые были недоступны более старому серверу при использовании mysqldump, чтобы создать файл дампа.
Остановите более новый сервер MySQL и перезапустите более старый.
Перезагрузите файл дампа в более старый сервер. Ваши таблицы должны быть доступными.

Если системные таблицы в mysql база данных изменилась, понижение могло бы представить некоторую потерю функциональности или потребовать некоторых корректировок. Вот некоторые примеры:

Триггерное создание требует TRIGGER полномочие с MySQL 5.1. В MySQL 5.0, есть нет TRIGGER полномочие и SUPER требуется вместо этого. Если Вы понизите от MySQL 5.1 до 5.0, то Вы должны будете дать SUPER полномочие к тем учетным записям, которые имели TRIGGER полномочие в 5.1.
Триггеры были добавлены в MySQL 5.0, так, если Вы понижаете от 5.0 до 4.1, невозможно использовать триггеры вообще.
mysql.proc.comment определение столбца изменилось между MySQL 5.1 и 5.5. После упадка от 5.5 до 5.1, эта таблица замечается как поврежденная и нуждающаяся в восстановлении. К обходному решению эта проблема выполните mysql_upgrade от версии MySQL, к которому Вы понизили.