I have to plan a DB2 upgrade activity from 9.7 to 10.5 - for a customer with critical online applications and one huge backend database of 300-400 GB.
OS: RHEL 6.7 or 6.8 (new one if necessary)
DB2 HADR cluster
We have to limit as much as possible the outage / downtime of their critical apps.
The backup activity for this huge database takes about 4 hours or more.
What should I choose:
- for the safety of the upgrade / applications - customers prefer the upgrade to a new server.
This requires mandatory an offline backup and restore that means many hours of downtime.
What is the best solution to balance the downtime and the safety of the upgrade operations ?
What is the best scenario to choose:
1) Forget about the customer request and try to convince the customer to upgrade on the same server - there will be only a small outage right?
install DB2 10.5 on the same machines and proceed with the upgrade and migration as rtfm.
Limited outage only to change the connections right if everything is setup before.
2) Clone the existing DB2's 9.7 HADR to a new machine - keep the apps working on old server.
On the new server do the upgade as in case 1 - on the same machine
when everything is completed on the new server - stop connections on old and start on new one with 10.5
3) Install a fresh 10.5 do the upgrade and perform upgrade to a new server: https://www.ibm.com/support/knowledg.../t0011368.html
as specified in documentation - do an offline backup and restore in the new server
This is the safest method but automatically implies many hours of downtime.
I am pretty sure many of you faced a similar situation and already did such an upgrade involving online apps and huge databases.
I read over the forum and I carefully read the documentation but I am not sure I have a certain solution so please advice / help.
To me, the ideal solution would be to end up on the new hardware.
Here is an idea you can toss around.
1) Break the HADR pair
2) Migrate the production instance to 10.5
3) On the new hardware, create a new 10.5 instance and setup HADR from the production system
4) When HADR is in PEER mode, stop the database and fail to the new hardware
5) On the second new hardware, setup new 10.5 instance, and setup HADR from the current 10.5 production on the new hardware
This will give you 2 short down times (steps 2 and 4) as opposed to one large one.
Personally, I would setup the new hardware on 10.5, and do the offline backup and restore to the new hardware. In case any issue crop up during the migration, you still have the old system to fall back to. Any other method does not give you that level of recovery.
Just a thought... If downtime is a critical factor and new hardware is lot better than old hardware, moving to new hardware before 10.5 upgrade might be better option. With better hardware, downtime will be less.
Yes downtime length is the most critical factor.
Indeed instead of upgrade to 10.5 I think it is better to move to the new hardware (install 9.7 and 10.5 on the new hw)
I think the main reason would be that if we upgrade first on the old hardware and install 10.5 along the existing 9.7 - it might be a case of a failure (small probability indeed) that would demand a restore !!!
This restore would last many hours and I want to avoid such a situation !
If I keep on old hardware a running 9.7 and on new hardware install 9.7 (clone the existing databases) and also 10.5 both installed and configured.
In case of a similar failure on new hw when migrate from 9.7 to 10.5 then I do not need to restore but I can immediately switch back to the old hw with 9.7 am I right?
Anyway I think I will come with a full scenario and all required steps.
Also I should keep in mind that we have a HADR cluster architecture.
There was work done to allow a streamlined upgrade from 9.7 to 11.1 directly. Also some other things like a better GUI installer, if you use it. (I think the GUI installer is for both Linux and Windows.)