Возникла необходимость обновить 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.me/tips/info/2180.shtml
А что, уже есть смысл перелазить с 5.0 на 5.1?
В принципе да, есть. В 5.1 довольно много изменений и она стабильная.
лень копаться в ссылках, но я где то видел у тебя бенчмарк где в версии 5.1 провал в производительности по сравнению с 5.0. Как прокоментируете?
>лень копаться в ссылках, но я где то видел у тебя бенчмарк
>где в версии 5.1 провал в производительности по сравнению с 5.0.А в предыдущем посте и был
>Как прокоментируете?
Уже неделю гоняю тесты туда-сюда, чтобы выяснить причину провала. :\ Для конфига под Linux выяснилось, что виноват query_cache_size. Стоило закомментировать его, как производительность резко возросла (хоть и всё равно отстаёт по производительности от 5.0). Странность заключается в том, что все тесты sysbench'ем для 5.0 проходили с включенным query_cache_size без таких проблем, так что гадаю теперь, почему это могло происходить.
В данный момент линуксовый конфиг я оттестировал, теперь проверяю на Фре разницу с отключенным query_cache_size.
Вот это возможно поможет вам понять причину
http://www.realcoding.net/articles/mysql-query-cache.html
>Вот это возможно поможет вам понять причину
>http://www.realcoding.net/articles/mysql-query-cache.htmlОго, спасибо, классная статья!
Простота, доступность и открытость. MySQL.
Всю ночь ставил. Понравилось...
>Всю ночь ставил. Понравилось...Что из этого всю ночь делать??
А для людей нормальный способ обновления придумать нельзя? чтобы запустить и все обновилось само
Есть такой способ, называется выбор вменяемого дистрибутива :)
т.е. чтобы обновлять MySQL нужно поменять дистрибутив? т.е. этот линукс - это не тот линукс... ппц
5.0 до 5.1 напрямую ни в одном дистрибе, насколько я знаю, не обновляется, ибо разные ветки. Так что за исключением указания флагов расмаскирования, алгоритм будет тот же.
> А для людей нормальный способ обновления придумать нельзя? чтобы запустить и все обновилось самоНормальные сначала думают - Что надо?,...
В общем классика:
1. Задача ->
2. Способы решения ->
3. Изучение аналогов ->
4. Варианты решения ->
5. Затраты на решения ->
6. Выбор и Обоснование - >
7. Решение ->
8. Тестирование.А на этих гентушнегов не обращайте внимание, у них всё через жопу.
1. Решение ->
2. Тестирование.
3. Обоснование ->
4. Затраты. Всю ночь устанавливал ->
5. Варианты. Наверно можно было и не устанавливать. Опа, а 5.0 почему-то тоже работает и даже бытре. и на BSD тоже. ->
6. А ведь можно было по другому установить ->
7. Ура я установил в Генте Мусоль 5.1
8. Вроде уже стабильная, и рабочая.
Не совсем в тему...;) а как обновиться с 5.1.xx до 5.1.40? то в рамках одной ветви?гугл мучаю уже неделю.. варианты только 5.0.x до 5.1.x ...
не навижу генту. чтоб вы все сдохли!