Oh, yeah...You're going to have to make sure any remnants of MySQL 5 are removed from the system after uninstalling. If there's anything in /var/lib/mysql, you'll need to get rid of it. It'd be asking for trouble to leave MySQL 5 data lying around during the switch to version 4.
Check out the forum guidelines!
Yes i'm on i386.
All files are downloaded.
How do I uninstall MySQL 5 without ending up like last time I was told to do a yum remove ending up with a almost totally deleted box *smile*
Can you just give me some short advice, for how to safely remove and then how I install the MySQL4, should they go in a specific order?
That's also potentially a hard problem. ;-)
yum remove mysql might do the trick...I just realized, though that you'll also need PHP rebuilt, if your scripts are in PHP. This is going to get ugly. You're traveling in uncharted waters here.
Anyway...let's cross that bridge when we come to it. Removing MySQL can probably be done safely with:
rpm -qa | grep mysql
rpm -e whatever the previous command listed
This rpm -e command will probably be:
rpm -e mysql mysql-server mysql-devel php-mysql
But there might be more packages than that.
Once that's done, you can install the new ones (probably, though there might be some extra dependencies). And finally, we'll need to build the PHP MySQL bindings. I'll have to figure out how to do that for you...
Ok... somehow i'm not sleepy any more :-)
Feels like i'm walking on very thin ice here!
I have a (maybee silly) question.
Is there some other way to get these things set up from a new install? If I uninstall MySQL and PHP, and then uninstall or reinstall Virtualmin... Don't the install.sh then pick up the missing things? or am I totally wrong here?
<i>Is there some other way to get these things set up from a new install? If I uninstall MySQL and PHP, and then uninstall or reinstall Virtualmin... Don't the install.sh then pick up the missing things? or am I totally wrong here?</i>
And if you do so, which version of MySQL will be installed? Somebody has to <i>build</i> those packages, if you don't want the ones that come from the Fedora Core 6 software repository (even our custom PHP4 packages are built to talk to MySQL 5, as provided by FC6...so, it won't work in your case, either).
If you need MySQL 4 on Fedora Core 6, we have to build it. If you then want PHP to talk to that MySQL version, we'll have to build it, too. Things get complicated when we go against the defaults in the OS, which is why we avoid it as much as possible.
I told you it was a stupid question... :-)
Ok, the reason for all my questions is that my problem here is NOT caused by any of your software, and I was just thinking if there was some "shortcut" to get this to work. And mainly to NOT give you guys more problems to solve.
I really appreciate all the help we get from you!
Do you think this is the way to go... or should I once more extend our contract for our old box, so I can rewrite those sites to be compatible with MySQL 5. It's a rather big job, but on the other hand I don't know how much work YOU have to put in to get MySQL 4 working on/with FC6.
I'm also is in a rather tight time frame here, the old box is supposed to get "killed" in two days (by the 24th).
I Don't know how much work or time it would take to get MySQL 4, PHP and all other stuff it involves up and running. I think I need about one day to move the domains. I can't do backup and restore on all the domains. Some of them needs to be moved/updated manually. So this gives me just one day for MySQL 4. And of course, to get it to work I NEED your support, and I can't take for granted that you guys are there to "fix" this for me in this short time.
So... it end up with this question, is it possible to get this up and running in, lets say 12 hours, if so, it leavs me time for transfering the domains. If not, I'm stuck for another month with the old server. This gives me a month to upgrade/rewrite our code to work with MySQL 5.
What do you think, should I go for MySQL 4 and the dedline by the 24 of April. Or should I go the "safe" way ???
<i>So... it end up with this question, is it possible to get this up and running in, lets say 12 hours, if so, it leavs me time for transfering the domains. If not, I'm stuck for another month with the old server. This gives me a month to upgrade/rewrite our code to work with MySQL 5.</i>
I don't know.
I'm setting up a pristine FC6 build environment as we speak...but I've gotta hit the sack (it's nearly 2AM here, and I've been up a long time...). I am hopeful that rebuilding PHP with bindings for MySQL 4 will not be difficult. It built OK on CentOS (for the same MySQL version that I built for you), so I suspect it'll build OK on FC6. I believe it'll probably work fine--but it'll still take an hour or so to build even if nothing goes wrong and it builds on the first try (which is probably more than we can hope for).
So, 12 hours is probably too much to hope for, but 24 is almost certainly do-able.
I don't mind building it--it's not actually taking a lot of human time. It's just that builds of big software in a sandbox environment (qemu in this case, since I can't easily use mock for this) takes a pretty long time, and if anything goes wrong I won't know until it's spent a bunch of time grinding away on the build. It's just a slow process, generally.
Downgrading MySQL can be a serious challenge...but in your case, I'm assuming you don't have any new data in the MySQL 5 database? That's the biggest problem with downgrading is getting the data to go downward (data that takes advantage of new features are impossible to import into the older version).
Let me see if I can build MySQL 4 packages for you real quick. I'll let you know in about an hour whether it'll be easy or not.
Have you hade time to check if it's possible to do this?
Or could you just give me a hint on when you have time to check this up, would be nice to know because i'm starting to get these horrible thoughts of getting a couple hours of sleep... thats not a good thought ;-)
(time here in Sweden is now 5:45am)
Hopefully it ends up ok, I think I can by me a day or two before the old server goes offline.
I'll go for MySQL 4. (IF they can give me a few days more)
Yes, sleep... I'm will do the same, getting really hard to hold my head up and eyes open.
I will talk to the guys at our server hall when they open(in about 2 hours) to see if I can get some extra days before the server is shut down.
I have also updated most of our ecommerce code during the night so it should now work with MySQL 5 and it's new way of handling JOINS. I have changed/updated most of the code(100 files manually updated) and it should now run fine(hopefully), I'll do the final testrun before I make the call to the serverguys in yhe morning.
If the code runs fine then I probably have time to update the other sites and code so all customers can be switched ower to our new box by end of day.
I'll will now try to get 2-3 hours of sleep before our serverguys is back at work, and of course do the final test of our code. If the guys says NO I'll need the day for the rest of the site code update and transfers witch of course needs our new box up and running. Also if I at this time should go for MySQL 4 I most certanly will need your assistance... and I guess you are sleeping(or anyway should be ;-) ) when we have morning/day here in Sweden.
I hope everything will be up and running by the end of day so we finally can drop the old box.
Joe, if I get a NO for a few extra days I'll have to stick with version 5. I'll drop a message here in a few hours and let you know what way we are going.
Thanks for all the help!
I know this isn't really any help to you, but i just thought i'd throw it out there...
You say your sites broke because they were written for MySQL4 and won't work on MySQL 5. This has never happend to me, i've written many sites for MySQL3 and 4 and never had any "serious" problems when moving them to later versions of MySQL. Nothing that couldn't be config'd away or fixed by a JDBC driver upgrade etc.
AFAIK MySQL5 is backward compatible with earlier version for almost every commonly used feature, the only real ones i can think of is the loss of support for ISAM tables (easily solved by moving to MyISAM before upgrade) and password hashing (which changed in 4.1), which can be solved by adding "old-passwords" to the mysqld section of your my.cnf
If it were me, i would stick with my old system while i planned and tested the migration of sites to MySQL5 (probably on CentOS, not Fedora). Upgrading the OS and downgrading the DB is not really a longterm solution, as i'm sure Joe won't want to build MySQL4 for every new version of Fedora that comes out, especially with Fedoras limited lifespan.
Just my $0.02
Some behavior is chaged!
I actually got aware of it the hard way... I have now changed our code to work in MySQL 5
here are some info,
The behaviour change reported by C. Vu is NOT a bug; it is entirely intentional. Queries that used to work with "FROM t1, t2" now need to be written using "FROM (t1, t2)" as previously stated.
To put parentheses explicitly as in (2). Then you can refer to t1 columns from expr.
Unfortunately, this change is not properly documented in the manual, it will be fixed.
The changes in behavior for joins are documented here now, along with suggestions on how to rewrite queries when necessary:
There is no sql_mode setting for getting the old incorrect behavior.
Here you have an example:
This works in MySQL 4, NOT in MySQL 5:
$listing_sql = "select " . $select_col_list . " p.prod_id, p.manufact_id, p.prod_price, p.prod_moms_class_id, IF(s.status, s.erb_new_prod_price, NULL) as erb_new_prod_price, IF(s.status, s.erb_new_prod_price, p.prod_price) as final_price from " . TABLE_PROD_DESC . " pd, " . TABLE_PROD . " p left join " . TABLE_MANUFACT . " m on p.manufact_id = m.manufact_id, " . TABLE_PROD_TO_CAT . " p2c left join " . TABLE_ERB . " s on p.prod_id = s.prod_id where p.prod_status = '1' and p.prod_id = p2c.prod_id and pd.prod_id = p2c.prod_id and pd.language_id = '" . (int)$languages_id . "' and p2c.cat_id = '" . (int)$current_cat_id . "'";
This works in both MySQL 4 and MySQL 5:
$listing_sql = "select " . $select_col_list . " p.prod_id, p.manufact_id, p.prod_price, p.prod_moms_class_id, IF(s.status, s.erb_new_prod_price, NULL) as erb_new_prod_price, IF(s.status, s.erb_new_prod_price, p.prod_price) as final_price from ((" . TABLE_PROD_DESC . " pd, " . TABLE_PROD . " p) left join " . TABLE_MANUFACT . " m on p.manufact_id = m.manufact_id, " . TABLE_PROD_TO_CAT . " p2c) left join " . TABLE_ERB . " s on p.prod_id = s.prod_id where p.prod_status = '1' and p.prod_id = p2c.prod_id and pd.prod_id = p2c.prod_id and pd.language_id = '" . (int)$languages_id . "' and p2c.cat_id = '" . (int)$current_cat_id . "'";
I have now done the testrun with the new code and it runs ok and make database queries correctly.
(some of our customers databases have 40000+ records)
I have also been talking to our serverguys and our old server will go offline by noon tomorrow(22 hours from now), instead of by midnight.
By this time I can have all pages updated for MySQL 5.
Can I somehow get MySQL 5 to use iso-8859-1(latin1) instead of utf-8, although it looks like it use latin1 but when importing databases it gets converted to utf-8.
Utf-8 gives us problem, for example when we edit/write some text in Swedish we use iso-8895-1 coding like "& a r i n g ;" for the swedish a with the ring above.
Some times i get files in Swedish that don't use "& a r i n g ;" or "& # 2 2 9 ;", the character show like it should but with some other utf format like "Ã