The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Как обновить MySQL 5.0 до MySQL 5.1 в Gentoo Linux
Возникла необходимость обновить MySQL 5.0 до MySQL 5.1 в Gentoo с минимальным перерывом в работе, 
описываю свой опыт. Вполне допускаю, что будет для гуру банальностью, тем не
менее, как "напоминалка"
будет полезна. Хотя бы мне самому :)
Основой послужили  статья Peter Davies'a и руководство MySQL Upgrading MySQL.

1. Работа с пакетами

Поскольку 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-битной версией, поэтому не обойтись без явного задания
разрешения сборки 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%.


2. Создание архивной копии

Почему идёт вторым шагом? Потому что операции, приведённые выше, по идее не
должны вызывать никаких
изменений в работающем 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, кроме как
скурпулезного сравнения документации.
 
29.09.2009 , Автор: Dennis Yusupoff , Источник: http://users.livejournal.com/_dyr/8...
Ключи: database, gentoo, linux, mysql
Раздел:    Корень / Программисту и web-разработчику / SQL и базы данных / MySQL специфика / Оптимизация и администрирование MySQL

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, vadiml (?), 11:38, 30/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А что, уже есть смысл перелазить с 5.0 на 5.1?
     
     
  • 2.2, Dyr (ok), 11:56, 30/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    В принципе да, есть. В 5.1 довольно много изменений и она стабильная.
     

  • 1.3, daevy (?), 12:06, 30/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    лень копаться в ссылках, но я где то видел у тебя бенчмарк где в версии 5.1 провал в производительности по сравнению с 5.0. Как прокоментируете?
     
     
  • 2.4, Dyr (ok), 12:38, 30/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >лень копаться в ссылках, но я где то видел у тебя бенчмарк
    >где в версии 5.1 провал в производительности по сравнению с 5.0.

    А в предыдущем посте и был

    >Как прокоментируете?

    Уже неделю гоняю тесты туда-сюда, чтобы выяснить причину провала. :\ Для конфига под Linux выяснилось, что виноват query_cache_size. Стоило закомментировать его, как производительность резко возросла (хоть и всё равно отстаёт по производительности от 5.0). Странность заключается в том, что все тесты sysbench'ем для 5.0 проходили с включенным query_cache_size без таких проблем, так что гадаю теперь, почему это могло происходить.
    В данный момент линуксовый конфиг я оттестировал, теперь проверяю на Фре разницу с отключенным query_cache_size.

     
     
  • 3.5, ws (ok), 16:13, 30/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Вот это возможно поможет вам понять причину
    http://www.realcoding.net/articles/mysql-query-cache.html
     
     
  • 4.6, Dyr (ok), 16:32, 30/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Вот это возможно поможет вам понять причину
    >http://www.realcoding.net/articles/mysql-query-cache.html

    Ого, спасибо, классная статья!

     

  • 1.7, Капитан Анонимность (?), 15:20, 02/10/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Простота, доступность и открытость. MySQL.
     
     
  • 2.8, Мумука (?), 15:20, 02/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Всю ночь ставил. Понравилось...
     
     
  • 3.9, Dyr (ok), 18:19, 02/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Всю ночь ставил. Понравилось...

    Что из этого всю ночь делать??

     

  • 1.10, Капитан Анонимность (?), 18:09, 03/10/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А для людей нормальный способ обновления придумать нельзя? чтобы запустить и все обновилось само
     
     
  • 2.11, angra (ok), 04:51, 04/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Есть такой способ, называется выбор вменяемого дистрибутива :)
     
     
  • 3.12, кракозябра (?), 19:36, 04/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    т.е. чтобы обновлять MySQL нужно поменять дистрибутив? т.е. этот линукс - это не тот линукс... ппц
     
  • 2.13, Денис Юсупов (?), 12:03, 05/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    5.0 до 5.1 напрямую ни в одном дистрибе, насколько я знаю, не обновляется, ибо разные ветки. Так что за исключением указания флагов расмаскирования, алгоритм будет тот же.
     
  • 2.14, pavlinux (ok), 18:02, 06/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > А для людей нормальный способ обновления придумать нельзя? чтобы запустить и все обновилось само

    Нормальные сначала думают - Что надо?,...
    В общем классика:
    1. Задача ->
    2. Способы решения ->
    3. Изучение аналогов ->
    4. Варианты решения ->
    5. Затраты на решения ->
    6. Выбор и Обоснование - >
    7. Решение ->
    8. Тестирование.

    А на этих гентушнегов не обращайте внимание, у них всё через жопу.  

    1. Решение ->
    2. Тестирование.
    3. Обоснование ->
    4. Затраты. Всю ночь устанавливал ->
    5. Варианты. Наверно можно было и не устанавливать. Опа, а 5.0 почему-то тоже работает и даже бытре. и на BSD тоже. ->
    6. А ведь можно было по другому установить ->
    7. Ура я установил в Генте Мусоль 5.1
    8. Вроде уже стабильная, и рабочая.

     

  • 1.15, Александр (??), 15:01, 25/11/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не совсем в тему...;) а как обновиться с 5.1.xx до 5.1.40? то в рамках одной ветви?

    гугл мучаю уже неделю.. варианты только 5.0.x до 5.1.x ...

     
  • 1.17, ka4a (ok), 17:23, 11/04/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    не навижу генту. чтоб вы все сдохли!
     


     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру