трънки и блогинки

MySQL 4.1.x на Fedora

Написано на: 13.02.2005 · 11 коментара

Едно от нещата, които ме дразнят в подбора на пакетите включени в Fedora Core 3 е старата версия на предпочитаната от мен база данни – MySQL. Клонът версии започващи с 3.x.x отдавна е обявен за остарял от екипа на MySQL, но поради неизвестни за мен причини разработчиците на Fedora ползват последната стабилна версия от него.

Досега предпочитах удобството на автоматичните обновявания на стария клон, но тъй като все повече продукти изискват версия 4.x, а и предимствата на новите версии стават все повече и повече, реших да обновя до последната стабилна версия.

MySQL AB предоставят и rpm дистрибутив, който се ползва за основа на включения в development клона на Fedora Core пакет на MySQL версия 4.1.9. Това, че е в development клона не трябва да ни притеснява, защото MySQL са доказали многократно, че не пускат нестабилни версии, а в момента 4.1 клона е водещата им стабилна версия.

Проблемът при обновяването на MySQL се състои в това, че много други пакети разчитат на него. Такива са php-mysql, perl-DBD-MySQL, MySQL-python и други. Затова ако опитаме просто да обновим версията ще получим конфликт на зависимостите, защото ще се опитаме да премахнем библиотеки, от които горните пакети имат нужда. На моята работна станция следните пакети зависят от MySQL:

rpm -e --test mysql mysql-server mysql-devel
error: Failed dependencies:
libmysqlclient.so.10 is needed by (installed) pam_mysql-0.5-1.i386
libmysqlclient.so.10 is needed by (installed) perl-DBD-MySQL-2.9003-5.i386
libmysqlclient.so.10 is needed by (installed) php-mysql-4.3.10-3.2.i386

Възможен начин да се справим с тази зависимост е да прекомпилираме всички зависими пакети да ползват новите библиотеки, но това ще направи доста трудно последващото им обновяване, а плюс това има значително по-лесен начин.

MySQL предоставят rpm пакет MySQL-shared-compat, който съдържа библиотеките от предишните версии и сред тях е и липсващата ни в горния случай libmysqlclient.so.10:
rpm -qpl MySQL-shared-compat-4.1.9-0.i386.rpm
warning: MySQL-shared-compat-4.1.9-0.i386.rpm: V3 DSA signature: NOKEY, key ID 5072e1f5
/usr/lib/libmysqlclient.so
/usr/lib/libmysqlclient.so.10
/usr/lib/libmysqlclient.so.10.0.0
/usr/lib/libmysqlclient.so.12
/usr/lib/libmysqlclient.so.12.0.0
/usr/lib/libmysqlclient.so.14
/usr/lib/libmysqlclient.so.14.0.0
/usr/lib/libmysqlclient_r.so
/usr/lib/libmysqlclient_r.so.10
/usr/lib/libmysqlclient_r.so.10.0.0
/usr/lib/libmysqlclient_r.so.12
/usr/lib/libmysqlclient_r.so.12.0.0
/usr/lib/libmysqlclient_r.so.14
/usr/lib/libmysqlclient_r.so.14.0.0

Използвайки този пакет, няма да ни се налага да прекомпилираме зависимите от новата версия пакети, като те ще могат да бъдат обновявани автоматично.

Разработчиците на Fedora предлагат своя версия на този пакет под името mysqlclient10-3.23.58-4.i386.rpm и този пакет съдържа само библиотеките от версиите на MySQL, които се дистрибутират в стабилния клон на Fedora:
rpm -qpl mysqlclient10-3.23.58-4.i386.rpm
/etc/ld.so.conf.d/mysqlclient10-i386.conf
/usr/lib/mysql/libmysqlclient.so.10
/usr/lib/mysql/libmysqlclient.so.10.0.0
/usr/lib/mysql/libmysqlclient_r.so.10
/usr/lib/mysql/libmysqlclient_r.so.10.0.0

Аз предпочитам да ползвам пакета на Fedora, защото нямам нужда от съвместимост с 4.0 версията.

Тъй като опита да обновим версията чрез познатото ни rpm -Uvh ще доведе до грешка поради конфликт на зависимостите, трябва първо да премахнем старата версия и да инсталираме на чисто пакета със старите библиотеки, за удовлетворяване на зависимостите, а след това и самия сървър за бази данни. Това става със следните команди:
rpm -e --nodeps mysql mysql-server mysql-devel mysql-bench
rpm -Uvh mysqlclient10-3.23.58-4.i386.rpm
rpm -Uvh mysql-4.1.9-1.i386.rpm mysql-devel-4.1.9-1.i386.rpm mysql-server-4.1.9-1.i386.rpm mysql-bench-4.1.9-1.i386.rpm

След това трябва вече да имаме функциониращ MySQL версия 4.1.9.

Казано накратко този шел скрипт трябва да свърши работата вместо вас:
#!/bin/bash
# A script to update MySQL on Fedora systems
# Author Peio Popov # Use at your own risk!

# Current MySQL version and build
VER=4.1.9-1

echo "Stop the database server"
/etc/init.d/mysqld stop

echo "Remove old MySQL version"
rpm -e --nodeps mysql mysql-server mysql-devel mysql-bench

echo "Install the compatibility libraries"
rpm -Uvh http://fedora.lcpe.uni-sofia.bg/fedora/linux/core/development/i386/Fedora/RPMS/mysqlclient10-3.23.58-4.i386.rpm

echo "Install the new MySQL"
rpm -Uvh http://fedora.lcpe.uni-sofia.bg/fedora/linux/core/development/i386/Fedora/RPMS/mysql-$VER.i386.rpm
rpm -Uvh http://fedora.lcpe.uni-sofia.bg/fedora/linux/core/development/i386/Fedora/RPMS/mysql-devel-$VER.i386.rpm
rpm -Uvh http://fedora.lcpe.uni-sofia.bg/fedora/linux/core/development/i386/Fedora/RPMS/mysql-bench-$VER.i386.rpm
rpm -Uvh http://fedora.lcpe.uni-sofia.bg/fedora/linux/core/development/i386/Fedora/RPMS/mysql-server-$VER.i386.rpm

echo "Start the database server"
/etc/init.d/mysqld start

Категория: свободни неща

11 коментара ↓

  • Хубаво ми е, когато хората коментират. Чета внимателно всеки коментар и отговарям, когато имам какво да кажа.

  • yovko на 14.02.2005г. в 03:49ч.

    Има пакет за съвместимост, Пейо – MySQL-shared-compat.x.x.rpm ако не се лъжа – поне за x86 платформа. Иначе аз точно се борех със същия проблем снощи, защото този пакет го няма за AMD64, какъвто ми трябваше. А и пусках 4.0 MySQL…

    Всъщност новата Core 4 ще идва с MySQL 4.1 и PHP5 като пакетите за това са вече налични в development хранилището и съм готов да се обзаложа, че ще тръгнат и върху FC3.

  • yovko на 14.02.2005г. в 03:51ч.

    Всъщност забравих да кажа най-важното, заради което започнах да пиша коментара, че за платформи различни от x86 има разни пакетчета от вида mysqlclient10.rpm из мрежата вместо MySQL-shared-compat.

  • пейо на 14.02.2005г. в 04:06ч.

    Ми че аз нали съм описал и на MySQL пакета за съвместимост и на Fedora!?
    Да не би да си скочил от увода директно на коментарите?

    А аз не бих минавал на 4.0 като имам предвид как са променени charsets и collations в 4.1. Мигрирането, както го разбирам, би трябвало да е нетривиален процес и затова аз бих ти препоръчал да работиш директно с 4.1 ако имаш сходни на моите мисли.

  • пейо на 14.02.2005г. в 04:15ч.

    А ето и от къде се е появило това ми разбиране за проблеми:
    http://www.livejournal.com/users/peter_zaitsev/12083.html

    И плюс това php5 ми изглежда рисковано като се има предвид разнообразието от приложения и възможните изненади. Затова се надявам да пуснат поне алтернативно и php4.

  • yovko на 14.02.2005г. в 10:38ч.

    Мда – малко по диагонал съм минал, sorry! Ще ти пусна снимка на mainframe отвътре ако ми бъде простено. ;)

    А аз не мигрирам бази от версия към друга, а от машина на машина затова ми е по-лесно да запазя базите в 4.0 и без това останалия гърч ми е достатъчен, а на следващ етап ще ъпгрейдвам…

  • пейо на 14.02.2005г. в 11:42ч.

    Ще го пишем на деня на влюбените на сметката тогава. Сори, ама с теб асоциацията с Трифон Зарезан не ми е силна :)

    А снимка на мейнфрейм пак пусни :)

  • Георги Иванов на 14.02.2005г. в 17:49ч.

    Незнам , но ми се струва , че postgre доста изпревари и то не точно изпревари mysql а малко е била по напред макара ,че на намен лично postgre ми се струва доста куца откъм администрация , но откъм възможности мисля , че е доста по напред. Не очаквам флейм очаквам да чуя лични мнения :))

  • пейо на 15.02.2005г. в 03:41ч.

    @ Георги Иванов
    Аз и сега не ползвам пълните възможности на MySQL, а плюс това и я познавам по-добре. MySQL е там и работи. Работи в пълна тишина и от години и затова не виждам никаква нужда да я сменям.

    А, че има и ще има нещо, което ще е с повече възможности – така е, но за щастие СУБД не са като пишките, колите и др. и самочувствието ми не зависи от потенциалните им възможности.

  • Владимир Герджиков на 16.02.2005г. в 06:31ч.

    Всъщност, аз този пост го разбирам, като опракване от подбора на пакетите във Fedora. Не ми се затъва в подробности, но и досега ми е голяма загадка от какво всъщност се определя комплектацията. Защо примерно Core 1 има качествен пакет xawtv, а друг не. После във версия 3 нещата отново са ОК (това е само пример). И така мога да продължа до безкрай.
    В началото се опитвах да проследя нишките и споровете във един от форумите им, но после се отказах. Прекалено енергоемко ми е.
    Все пак, може би трябва да се търси някакво равновесие м/у чистите RPM пакети и tarball-овете? Със сигурност истината е по средата.
    Иначе и аз хвърлих няколко десетки ругатни по MySQL комплектацията, въпреки пакетите за съвместимост. Че какво толкова щеше да им струва да сложат каквото трябва?!

  • пейо на 16.02.2005г. в 07:55ч.

    Не, чак оплакване не е. По-скоро неудобство. MySQL си дават rpm, в development си има работещ rpm също, а за кода и компилатора сам си знаеш :)

    Неприятното е като се взимат крайни решения за пакети, от които зависят много други. Подхода с пакетите за съвместимост ми хареса много. Други дистрибуции като Gentoo и SuSE пък ти дават да си избираш коя версия на apache httpd да ползваш. Има начин, но ако може и да не ни карат да се мъчим много, ще е най-добре.

  • yovko на 16.02.2005г. в 11:01ч.

    Ами до този момент имаше абсурдна съпротива към MySQL 4.x за да влезе във Fedora. Аз лично се заяждах още по времето на прехода FC1 към FC2, но поради откровено твърдоглавие и нежелание за решаване на проблема от страна на Fedora девелоперите (начело с Алън Кокс за съжаление) темате беше отхвърлена (за пореден път като досадна и маловажна). Ескалирах проблема чак до Zak Greant (тогава още работеше за MySQL) – той направи опити да се намеси, но… За да има диалог трябва да си говорят и двете страни, нали?

    Всъщност не е тайна за никого, че Red Hat винаги са толерирали PostgreSQL, но просто отношението към MySQL беше повече от обидно. Добре, че за FC4 на някой му е увряла главата. Или пък двете community-та са започнали да си говорят?…