Возникла необходимость обновить MySQL 5.0 до MySQL 5.1 в Gentoo с минимальным перерывом в работе,
описываю свой опыт. Вполне допускаю, что будет для гуру банальностью, тем не менее, как "напоминалка"
будет полезна. Хотя бы мне самому :)
Основой послужили статья <a href="http://www.pkdavies.co.uk/blog/gentoo-mysql-5-1-upgrade"... Davies'a</a> и руководство <a href="http://dev.mysql.com/doc/refman/5.1/en/upgrade.html">... Upgrading MySQL</a>.<h3>1. Работа с пакетами
</h3>
Поскольку Gentoo считает, что версии 5.1 недостойны называться стабильными (хотя она уже довольно д
авно является "релизной", в отличии от <a href="http://dev.mysql.com/downloads/mysql/5.4.html">5.4&l.... см. <a href="http://forge.mysql.com/wiki/Development_Cycle">планы развития веток MySQL</a>),
то они занесены в список исключений, т.н. "masked", так что при попытке установить их без вынесения
из этого списка приведут к ошибке.
Чтобы обойти это, нужно зарегистрировать эту версию MySQL в "список исключений из списка исключений" :)
echo "=dev-db/mysql-community-5.1.21_beta" >> /etc/portage/package.unmask
Если просто комментировать соответствующие строки в файле /usr/portage/profiles/package.mask, как это
предлагает Питер, то при каждом обновлении пакета этот файл будет обновляться, с соответственным
удалением комментариев. Не совершайте такой ошибки, какую сделал я :)
Gentoo у меня собран 64-битной версией, поэтому не обойтись без явного задания разрешения сборки MySQL
под amd64. Для этого вносим соответствующую запись в очередной файл исключений:
echo "dev-db/mysql-community ~amd64" >> /etc/portage/package.keywords
и на всякий случай:
echo "virtual/mysql ~amd64" >> /etc/portage/package.keywords
Если просто выставить в командной строке ACCEPT_KEYWORDS="~amd64", то Gentoo не поймет, что такое
ключевое слово было выставлено при установке, и как итог, любое (авто-)обновление пакета
остановится с ошибкой "masked by: ~amd64".
Думаете, что этого уже достаточно для установки? Ошибаетесь :)
Помните, что у нас ещё стоит версия 5.0? Так вот чтобы установить 5.1, нам надо сначала удалить 5.0.
Явно не быстрое дело, а время простоя, напомню, критично. Поэтому вместо остановки работающего 5.0,
его удаления и компиляции 5.1, лучше сделать хитрее и воспользоваться возможностью создания бинарных пакетов.
Создам сначала бинарный пакет установленного mysql-5.0, чтобы в случае неудачи с 5.1 можно было
быстро откатится на предыдущую версию:
quickpkg dev-db/mysql или emerge --verbose --buildpkg dev-db/mysql
Затем подготовим нашу новую версию, создав бинарный пакет для последующей установки:
emerge --verbose --ask --buildpkgonly =dev-db/mysql-community-5.1.21_beta
Использование distcc и ccache обычно позволяет существенно уменьшить время компиляции. У меня при
использовании ccache и distcc на два сервера время сборки пакета mysql-5.0 уменьшилось на 35%.
<h3>2. Создание архивной копии
</h3>
Почему идёт вторым шагом? Потому что операции, приведённые выше, по идее не должны вызывать никаких
изменений в работающем MySQL, но занимают определённое количество времени, а терять изменения,
внесённые в БД за это время, не хочется.
Делаете любым удобным для себя способом, хотя бы как это описывает Питер, через mysqldump,
архивирование директории с БД после её остановки или репликацию на другой сервер.
Поскольку для меня было важным минимальный перерыв, а настраивать репликацию я не хотел,
я воспользовался первым способом:
mysqldump -A --opt --allow-keywords --flush-logs --hex-blob --master-data --max_allowed_packet=16M \
--quote-names --default-character-set=CP1251 --single-transaction --result-file=BACKUP_MYSQL_5.0.SQL
Единственное, что я хотел бы порекомендовать, это использовать помимо указанных Питером ключей,
ключ --single-transaction, который существенно ускоряет восстановление из бэкапа,
и ключ --default-character-set со значением "cp1251" для тех, у кого таблицы в cp1251, а не в UTF8,
который выставляется при дампах по умолчанию. У меня бекап, созданный без этих ключей весил 4.6 Гб, с ключами - 4.1 Гб
<h3>3. Обновление MySQL и таблиц
</h3>
Итак, пакеты и архивные копии готовы, предупреждаем тех.поддержку о возможных перебоях и приступаем:
Останавливаем работающий MySQL:
/etc/init.d/mysql stop
Удаляем MySQL 5.0:
emerge --unmerge --verbose dev-db/mysql
Устанавливаем бинарный пакет MySQL 5.1:
emerge --usepkgonly --verbose =dev-db/mysql-community-
5.1.21_beta.tbz2
Запускаем установленный MySQL 5.1:
/etc/init.d/mysql start
Обновляем таблицы:
mysql_upgrade --user=root --password=PASSWORD --default-character-set=cp1251 --verbose
При удачном раскладе (объединяйте команды в конвейер с помощью "&&"!) это займёт меньше минуты.
Учтите, что опции сервера, указанные в /etc/mysql/my.cnf, для 5.1 могут отличатся от 5.0!
Поэтому если сервер не стартует, смотрите tail /var/log/mysql/mysqld.err и исправляйте переменные.
Мне, скажем, пришлось терять время, пока я убирал "skip-bdb" и "skip-federated". К сожалению, я не
знаю другого способа проверить на совместимость файлы от 5.0 и 5.1, кроме как скурпулезного сравнения документации.
URL: http://users.livejournal.com/_dyr/89113.html
Обсуждается: http://www.opennet.dev/tips/info/2180.shtml
Вариант для распечатки
(ok) on 30-Сен-09, 11:56 
