![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=92.1){kind=small}
Возникла необходимость обновить MySQL 5.0 до MySQL 5.1 в Gentoo с минимальным перерывом в работе, описываю свой опыт. Вполне допускаю, что будет для гуру банальностью, тем не менее, как "напоминалка" будет полезна. Хотя бы мне самому :)
Основой послужили статья Peter Davies'a и руководство MySQL Upgrading MySQL
1. Работа с пакетами
2. Создание архивной копииПоскольку Gentoo считает, что версии 5.1 недостойны называться стабильными (хотя она уже довольно давно является "релизной", в отличии от 5.4. планы развития веток MySQL), то они занесены в список исключений, т.н. "masked", так что при попытке установить их без вынесения из этого списка приведут к ошибке.
Чтобы обойти это, нужно зарегистрировать эту версию MySQL в "список исключений из списка исключений" :)
echo "=dev-db/mysql-community-5.1.21_beta" >> /etc/portage/package.unmask
Если просто комментировать соответствующие строки в файле /usr/portage/profiles/package.mask, как это предлагает Питер, то при каждом обновлении пакета этот файл будет обновлятся, с соответственным удалением комментариев. Не совершайте такой ошибки, какую сделал я :)
Gentoo у меня собран 64-битной версией (что, кто-то иначе делает для серверов БД и более чем 3ГБ памяти?), поэтому не обойтись без явного задания разрешения сборки 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%.
Почему идёт вторым шагом? Потому что операции, приведённые выше, по идее не должны вызывать никаких изменений в работающем 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 Гб
3. Обновление MySQL и таблиц
Итак, пакеты и архивные копии готовы, предупреждаем тех.поддержку о возможных перебоях (лично я это не всегда делаю, но надо ведь :), и
молимсяприступаем:
Останавливаем работающий 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, кроме как муторного сравнения документации.
September 30 2009, 08:06:30 UTC 2 years ago
&
echo "dev-db/mysql-community" >> /etc/portage/package.keywords
will give you the same effect
September 30 2009, 08:40:55 UTC 2 years ago
Hm
I had use it as it was described in handbook.Thanks for comment!
Anonymous
September 30 2009, 08:36:21 UTC 2 years ago
Разве нет причин держать mysql hardmasked???
Быть может это только мне так кажется но подобная фраза:"Поскольку Gentoo считает, что версии 5.1 недостойны называться стабильными (хотя она уже довольно давно является "релизной" "
звучит довольно вызывающе.
Действительно mysql-5.1 не является стабильной и по достаточно существенной причине: сервер рушиться на базах данных поддерживаемых infrastructure team. То есть мы сами до сих пор не можем его использовать! Как вы думаете, нам стоит думать иначе? Если хотите деталей, почитайте, что пишет robbat2 о mysql в багзиле (и, думаю, не только там, и, кстати, не только он).
September 30 2009, 08:50:32 UTC 2 years ago
Ну да, вызывающе :)
А не кинете ссылкой?На http://dev.mysql.com/downloads/ указано чётко:
Кроме того, изменений между имеющимся сейчас в репозитарии 5.1.21 и анонсированным почти месяц назад 5.1.39 достаточно много, чтобы накопить багфиксы.