Mysql – Implementing older version of theSQL on RH9

MySQLmysql-3redhat

I'm building a virtual machine running Red Hat Linux 9 (Shrike) and MySQL. This is to virtualize a current production system that needs new hardware. Questions:

Can I copy the existing mysql daemon executables to the new machine from the old one and if so, where are they located, and what is involved?
Are their archived packages of the early mySQL packages? I was hoping to find the exact version running on my old server, to do an install, and the copy the database file.

Update:

Hi….. many thanks for the ideas. I'm pretty sure the copy is the way to go…. (thanks Tometzky), but it is somewhat fraught, as the old hardware has a software RAID array, so I'm not sure I can do a bitcopy and have it work. And, the original mySQL is 3.23 (just about the first production version….). Earliest source I've found was at SkyServer which started at version 4.x.

A dd from one /dev/sda to /dev/sdb seems to work fine (simulated in VirtualBox). So far an /dev/md0 (from a RAID 1 drive) doesn't work….but I'm going to try copying partitions individually, and then see if that will work.

Our original mySQL is 3.23 (just about the first production version….). Earliest packaged binaries at SkyServer are 4.1

Obviously, this is a temporary move to buy us some time while we re-write the applications that query the mySQL.

Best Answer

Personally, I would not risk moving the installed binaries laterally to a newer OS because you may have to drag along needed libraries WHICH MAY NOT WORK IN THE NEWER OS !!!

You should thoroughly look through MySQL's Archives, which goes back to MySQL 5.0.15.

SkySQL also tries to fully accommodate users of older versions of MySQL, MariaDB, and more. Please go to their repository and find the version you need. They go back to MySQL 4.1.

You should make sure SkySQL has RHEL6 builds, at least.

You could also try compiling MySQL from source within RH9. DISCLAIMER : Never Built MySQL From Source

QUESTION #1

Can I assume that the conversion went as intended?

Never assume a conversion until you test it. Thank you for backing it up in advance.

QUESTION #2

Are there any obvious checks I should perform to ensure that integrity is not compromised?

For any given table mydb.mytable you converted to InnoDB, please check two things

TABLE COUNT

Take a count of all the rows

SELECT COUNT(1) FROM mydb.mytable;

Run the same count on the MyISAM backup.

CHECKSUM

Run a checksum of the whole table

CHECKSUM TABLE mydb.mytable;

Run the same checksum on the MyISAM backup.

SUMMARY ON QUESTION #2

You should get the same count and checksum values for both the InnoDB and MyISAM tables.

SUGGESTION FOR QUESTION #2

If you would like to manage the InnoDB conversion in stages, try doing this next time

CREATE TABLE mydb.mytable_new LIKE mydb.mytable;
ALTER TABLE mydb.mytable_new ENGINE=InnoDB;
INSERT INTO mydb.mytable_new SELECT * FROM mydb.mytable;
ALTER TABLE mydb.mytable RENAME mydb.mytable_old;
ALTER TABLE mydb.mytable_new RENAME mydb.mytable;

Use the table, test it in staging, kick the tires.

If you are satisfied the table is fine, drop the old table

DROP TABLE mydb.mytable_old;

or retain it as a backup

ALTER TABLE mydb.mytable_old RENAME mydb.mytable_myisam;

QUESTION #3

Should I enforce that the DB is single user before conversion, or is my only worry that response time might be bad while conversion is ongoing + loss of work in case of a restore from the initial backup?

If you want convert a live MyISAM table to InnoDB, see my post Converting live MyISAM table to InnoDB

If you are very skeptical or fearful of data loss, your idea of single user access is fine.

You could just restart mysql like this

service mysql restart --skip-networking

service mysql restart

GIVE IT A TRY !!!

MySQL Error 1593 on Replication Between Versions 5.0.92 and 5.5.42

You didn't setup the server-id variable, or you didn't restart after doing it (it is not a dynamic variable, changes will not be effective until you restart). It may be showing you a good id on both servers, but it will not really work until both servers are restarted, both master and slave.

It could be a bug, but the above has happened too many times on support cases that I would bet it is that.

Regarding circular replication: 5.0 -> 5.5 "should work", 5.5 -> 5.0 is possible, but not recommended. I understand why you want that, but you may encounter many incompatibilities in the queries and format.