We would like to setup another JIRA server and perform a full clone of the current JIRA server over to the new one. It would all just come over as part of the clone.
Instead of the normal migration using import/export xml backup file, do we just need to reconfigure the Jira software and database with the new server name and IP address? The Jira application would still use the same port number on the new server.
This all depends on how you set up Jira. If the database is on the same machine and the database host is set to 127.0.0.1 it makes things easier.
You can clone it while running on low load, boot it with it's nic disabled, set a new ip, add /etc/hosts entries to all your Atlassian stack to localhost (otherwise you will have 2 applicationservers talking to all your application links from the same unique id).
Before starting it up, it makes sense removing your hardcoded hostnames in the database, so do a mysqldump, and do something like:
cat jira.sql | sed 's/http:\/\/jira\./http:\/\/jira-test2\./g' | sed 's/https:\/\/jira\./https:\/\/jira-test2\./g' | sed 's/http:\/\/other.hostname\./http:\/\/confluence-test2\./g' | sed 's/https:\/\/other.hostname\./https:\/\/confluence-test2\./g' | sed 's/http:\/\/jira\//http:\/\/jira-test2\//g' | sed 's/https:\/\/jira\//https:\/\/jira-test2\//g' | sed 's/http:\/\/other.hostname\//http:\/\/confluence-test2\//g' | sed 's/https:\/\/other.hostname\//https:\/\/confluence-test2\//g' | sed 's/http:\/\/confluence\//http:\/\/confluence-test2\//g' | sed 's/https:\/\/confluence\//https:\/\/confluence-test2\//g' | sed 's/http:\/\/confluence\./http:\/\/confluence-test2\./g' | sed 's/https:\/\/confluence\./https:\/\/confluence-test2\./g' > new.jira.sql
The import the new dump back to the mysqlserver.
At this point find your dbconfig.xml and verify that it does not point to your production database server
Lastly, edit your setenv.sh to make sure you have the disabled email row uncommented. If not you will receive 2 notifications from different servers.
Lastly, if your JIRA instance talks a lot to applications around your landscape, add all the hostnames, short and FQDN's to the hostfile pointing at 127.0.0.1. Better to have it chatter to itself than a production instance.
If you terminate SSL you might need to replace your cacerts file with a new keystore.
Thanks Jonas for your quick reply. Looks like it is not as easy as using JIRA default export/import xml backup files.
Is the following way also good enough to do the migration?
I finally took the time to write a jira-cloner for work. It's written in bash but due to being developed at work they own the IP so i can't share the code but i can share a few things i learned along the way.
Stepstoning it functions with continues sanitychecks is a must. Two instances that accidentally talk to the database WILL crash production and test and leave the database in a mess very hard to recover from.
I start the process on production server. In short:
* kick of a script that verifies the status of the test server, makes sure it can SSH with a ssh-key, that the test-instance is not running, that mysql is installed, apache rewrite proxy exists and so on, then proceeds to delete most of the data/app directory (skipping logs as we have gigs of it). It also drops the database and recreates an empty one.
* Next on production i do a mysqldump that is added to /opt/atlassian/
* Next i rsync the database dump and a current copy of the filesystem to the test server.
* Next i kick off a script that updates:
server.xml (changes reverse proxy statements
setenv.sh (disable emails as you dont want notifications from test)
dbconfig.xml (change database server to localhost, renaming username/password/database)
* stringreplaces all instances of hostnames such as jira, bamboo, bitbucket, confluence to it's correlating test-server names in the database dump file, then imports it to the local database server.
* using openssl i download all the respective certificates to files, and imports them to the keystore.
* replace our jira logo with one that clearly states jira-test
* using atlassian guide on how to remove application links via the database, i automated this into a script too.
* using a list of host i dont want this server to be able to talk to, i add them to /etc/hosts (localhost) making sure if jira wants to talk to them, it will only talk to localhost.
I can now clone jira while it is still running in less than 25 minutes, by simply firing up a single script. Most of this time is spent on rsyncing 26gb of files over the network, and a fraction to sed replace hostnames in database and the import of the database dump. I noticed that not deleting all was an option, but the footprint of cache dirs might grow on test, but in return i can clone it in ~ 5 minutes.
It's well worth taking this time to automate it, because what was a gigantic task that took 5 hours and only happened every 3 months, can now happen on a weekly base.
The only manual labor left is reestablishing the application links, but once i have done this for all atlassian apps, i will approach this issue too, most likely via the database.
Next up: Confluence! :)
This approach requires you to have the JIRA administrative rights. The main aim of this article is to help you achieve an organized, easy-to-maintain workflows in your JIRA instance thereby, reducin...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs