MaxDB series: when do we publish the next article?

2006/03/25by admin

Dear MySQL users, MaxDB users and friends,

it happened what we always told you what might happen: we did not make it to write an article for you in this week. Of course, this is not the end of the series. It will continue, but other duties might force us in the future to skip a week again. As a small “excuse” for you, we have written an FAQ like entry.

Can I recover a MaxDB backup on a different version and/or a different system?

It depends: the processor architecture and the MaxDB version must be compatible. Given these two main preconditions you can take a backup from one system and recover it on a different system. This is a common situation when you are planning to upgrade the database software and the server hardware in one step. In general, we do not recommend to do these two steps at once. The simple reason that we do not is, that you should never change two variables at once. This makes debugging extremly difficult, if it should become necessary.

Precondition 1: compatible processor architecture. The processor architecture on the source and the target systems must be compatible. For the experts among you: it is a question of little vs. big endian. Luckily, the manual has a chart that shows which systems are compatible for all of us that are not CPU experts. Use the glossary in the MaxDB online manual to check for “Database Copy”. You will find out some facts that might amaze if you are not a CPU expert. For example, you can take a backup on Win32 and recover it on Win64.

Precondition 2: compatible MaxDB versions. The MySQL MaxDB history starts with MaxDB 7.5.00, therefore we will not discuss hints for any older versions. For 7.5.00 and 7.6.00 the main precondition of compatibility is that both databases have the same version (7.x.x) in the first three places. The build level of the target instance version is equal to or higher than the build level of the source instance. This means, you can for example create a backup on 7.5.00 Build 23 (7.5.00.23) and recover it on 7.5.00 Build 34 (7.5.00.34), because the first three places of the version string are the same. But you cannot recover a 7.6.00 backup on a 7.5.00 server, nor is there any warranty that you can recover a 7.5.00 backup on a 7.6.00 server!

Additionally you have to take care which version of the DBM GUI you use to do the work. In the first three places, the version of the Database
Manager GUI should be higher than or equal to the version of the database kernel. If it is equal, the build level (the last two figures) of the DBMGUI version can be lower than that of the database kernel.

Is that all you need to take care off? No! This is only a description how to find out if the backup files are compatible. Check the manual on hints and instructions how to perform a backup, what to do after a recovery (bad indexes) and what to take care of when you plan to upgrade from one MaxDB version to another.

We hope to have the promised SQL-highlights posting ready for you until next wednesday, happy hacking!