CLM(JTS & CCM) Migration from one server to another
Hello All,
We have an existing Instance on RTC 4.0 which is installed on a server and this server will be decommisioned soon.
Hence now we need to Install a new Instance of RTC 4.0 in another server and also migrate all the data from the old server to the new server.
Our configurations are
CLM 4.0 (CCM 4.0 & JTS 4.0)
DB2 9.7
Tomcat application server
Ldap authentication
Hence we want to move
RTC 4.0 (old server) -> RTC 4.0(new server)
Data from DB2 -> DB2
Tomcat -> Tomcat
Ldap -> Ldap (Use same existing repository groups)
Note : The hostnames are different for both servers hence I am quite concerned.
Please suggest what is the best approach to do this ?
|
6 answers
Hello Varun, I found some information which would be useful for server migration.
Back up : https://jazz.net/library/article/547
Migrating database : http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m3/index.jsp?re=1&topic=/com.ibm.jazz.install.doc/topics/t_migrate_dbs.html&scope=null
Follow http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m3/index.jsp?re=1&topic=/com.ibm.jazz.install.doc/topics/t_manually_update_config_db2.html&scope=null to configure DB2 for new server if it has been done already.
Once above steps are completed
- run repotools -reindex
- run repotools -rebuildTextIndices - run repotools -rebuildIndices
You can also run jts/setup at this stage to ensure there were no mistake during manual migration process.
- You can also run jts/setup at this stage to ensure there were no mistake during manual migration process
As far as I am aware, different hostname for server should not matter, unless you have set your public URI as your hostname or IP address. You will need to be more concerned if they would be using same public URI.
Hope it Helps
DH
|
Hi Varun,
As DH said, this is key: different hostname for server should not matter, unless you have set your public URI as your hostname or IP address. As an alternative to using repotools to move the database, you could use the DB2 vendor tools to backup the db and restore to the new db server. You would need to update the teamserver.properties with the new connection information. For the rest of the CLM configuration files, the easiest approach is to use DH's idea to make a file system backup and restore to the new environment.
If for some reason, that can't be done, the alternative is to think of this as an upgrade. Install CLM into the new location and then replace all the configuration files with the ones from the source server, including the Tomcat LDAP files.
|
|
Hello DH & Antoinette,
Thank you for the links, they were helpful.
Can you please give me a road map of steps that I would need to perform??
Let's say now I have 2 servers.
Integration1(old)
Integration2(new)
Integration1 has Jts & ccm 4.0 installed. Db2 is configured on a different server.Ldap on a different server.
Now all project areas,workitems,plans,artifacts etc will be as
https://integration1:9443/jts/admin
https://integration1:9443/ccm/admin
https://integration1:9443/web/projects/project1#action=com.ibm.team.workitem.viewWorkItem&id=37895
Now when I migrate to the new server ,ie. Integration2
Will all the links be changed to
https://integration2:9443/jts/admin
https://integration2:9443/ccm/admin
https://integration2:9443/web/projects/project1#action=com.ibm.team.workitem.viewWorkItem&id=37895
How do I achieve this ? Or is there a different approach ? Kindly provide me the step by step for the same if possible. It'll be really helpfull.
Thanks again
|
|
Hello Toni, I discussed the issue with IBM support by opening a PMR and they suggested a server rename. Now the server rename operation was successfull and also we are able to see all the project areas with data. But here's the problem. When I go the ccm/admin > server > run diagnostics I get an error with the JFS Index
ERRORS:
CRJZS5758E The information in the index for private applications might be incorrect because the timestamp (2013-10-11T14:54:45.712Z) of the "triple live" index is ahead of the timestamp (2013-10-11T14:14:54.152Z) of the database. Stop the server and either restore the index that corresponds to the database or run the following command: "repotools-ccm -reindex" to recover the correct index. For more details, open the help system and search for CRJZS5758E. CRJZS5758E The information in the index for private applications might be incorrect because the timestamp (2013-10-11T14:54:45.712Z) of the "text live" index is ahead of the timestamp (2013-10-11T14:14:54.152Z) of the database. Stop the server and either restore the index that corresponds to the database or run the following command: "repotools-ccm -reindex" to recover the correct index. For more details, open the help system and search for CRJZS5758E.
So should I run the repotools reindex command ? I am a bit scared if I will loose the data. Please advice.
|
|
Varun,
There are 2 causes for this message, system clock of the database is out of sync with that of the application server or the upgrade had database data from a later time than the indexes. So depending on the cause, you need to either correct the system clock or recreate the indexes. You aren't going to lose data recreating the indexes. You can always take a file system backup of them first if you want. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.