1 of 1 people found this helpful
This approach has been explained only partially correct. While it is possible to go with a one-node "upgrade", this is only partially an upgrade. Let me explain in detail:
For the sake of simplicity I assume that both nodes are set up as gateway nodes for the 9.6.1 installation.
So, if you take away one of the two nodes, either the other one already is the master gateway, or it will assume the role of the master gateway within a few minutes.
Meaning the easiest way to "separate" the two nodes is to simply shut down either node (e.g. node1).
However, if you now upgrade the software installation on node1, then the upgrade process would try to upgrade the contents of all repository DBs, namely the domain repository and the application service repositories (such as MRS, PowerCenter repository, Business Glossary, and so on).
This is surely NOT what you want because you want to keep the existing 9.6.1 system (now consisting of node2 only) running, but if you upgrade the repository structure to 10.2, then node2 will no longer be able to access any repository (in particular not the domain repository) and so the 9.6.1 installation will cease execution immediately.
What will work is this:
Keep e.g. node2 running as it is in 9.6.1 and keep all repository DB schemas (domain and application service repositories) as they are. Do not touch them in any way.
Now you can remove node1 from the 9.6.1 domain.
Uninstall the 9.6.1 software from node1.
Check that all installation pre-requisites are met by node1 before continuing.
Install the 10.2 software on node1 and make sure that you use NEWLY CREATED database schemas for the 10.2 repositories (both the domain repository and all application service repositories).
This way the 9.6.1 installation will continue to work with the 9.6.1 contents and domain repository while the 10.2 installation can work with its own contents and repositories.
Now you have to cater for user setup, user groups, roles, and so on (basically all the security-related stuff).
Once this is all set, you can create new application services in the 10.2 domain (again, DO NOT use any DB schema already used by the 9.6.1 installation, use freshly created schemas) and "copy" the repository contents from the 9.6.1 installation to the 10.2 installation one by one.
Now you can start to test everything in the 10.2 domain while the 9.6.1 installation still works on the old DB schemas.
Once you're satisfied with all the tests, you can perform the "final migration" from 9.6.1 to 10.2:
- Upgrade all 9.6.1 repositories to 10.2. There are several steps involved in this step, you can find them in many posts here on this forum.
- After all application service repositories have been upgraded, shut down the 9.6.1 domain, uninstall the 9.6.1 software from node2, and finally install the 10.2 software on node2 and join the existing 10.2 domain (of which node1 is the master gateway).
Granted, this is simplified in several places, but that's the general outline.
And yes, you will need notably more DB power and disk space during the migration. But that's the price to pay for this migration approach.
Thanks Nico for detailed explanation of the approach and steps. Your responses are always beneficial and helpful to deal with critical scenarios. I am clear about the road-map and execution of the upgrade process by mentioned approach. I would try to upgrade both nodes.