We are trying to setup a Disaster Recovery solution for our Atlassian applications (so far, Crowd, JIRA, Confluence and Crucible). The production environment consist of the following servers: Crowd: running on Windows, linked with AD to provide user authentication JIRA, Confluence and Crucible: Each of this runs on its own Ubuntu 10.04 server MS SQL Server 2008: Database server shared by all the above Our approach is to have every server replicated to a cold server (in a different geographical location), do an rsync to keep the different data folders up to date and have a secondary database server that we keep up to date with database replication. First issue is to make sure we filter what files are replicated through rsync, so we do not overwrite the cold server settings like database configuration (should point to the failover DB server). Second problem is to filter what tables get replicated for the databases. The last releases of Atlassian apps have the User Directory configuration stored in the DB. This means that if we do not filter this settings, we'd have the failover JIRA server pointing to the production Crowd, instead of the failover one. Still haven't completed this setup, but would like to hear of any thoughts about this setup and other possible solutions to provide resiliance to our Atlassian environment. I'm specially concerned of the administrative burden that this will bring when upgrading the live environment. Also, any changes in the configuration files and/or configuration settings stored in the DB in future releases would probably mean our cold failover environment will be broken.

Community
Q&A
Jira
Questions
Atlassian high availavility: cold failover?

Migrating Issues and Maintaining Issue Keys

Ran into a bit of a hairy situation regarding migrations and keeping issue-keys the same.

Context: We are planning to migrate a next-gen, team-managed project to a classic, company-managed project to enable more features for the customer.

Requirements:
1. Issue-key should remain the same.
2. Issue-key numbers should remain the same
3. Contents of issues should not be touched, including custom fields, workflow, and Developer data from Github.

Proposed solution: Bulk-update issues to move from original next-gen project (ABC) to new classic project (EFG). Then delete original project, and rename EFG issue key to ABC.

Problems:
1. If ABC-123 becomes EFG-456 and ABC-789 becomes EFG-123, then EFG is renamed to ABC, what happens to ABC-123? does it redirect to EFG-456? With the link alias be broken?
2. Confirmed with testing that bulk-moving issues does NOT retain the the issue-key numbers. Is there a way to retain the original numbers of these issue-keys? And if it's through exporting issues and importing them via CSV, what fields are required to migrate to make this work? (issue-key, issue-id, parent-id, Github?)
3. Will this break existing Github/JIRA connections that are tied by JIRA issue-keys?

Assumptions:

Doing some thorough research and combing through documentation and threads, I can determine that renaming the classic project EFG to ABC may break the historical connections to the original issue, as Atlassian's logic prioritizes the active issue in the classic project, rather than the previously deleted next-gen project.
Documentation: Migration of Jira's Historical Keys for Issues and Projects
Another thread from a Community leader confirming that "“should be aware that if you plan to re-use the old project key AAA for a different project (either renaming an existing project or creating a new one with that project key) you will effectively break this redirect for all issues that used to have an AAA issue key. So that is one way that this commit data could be lost or even misdirected.”
Thread: "If I move issues from on project to another, what will happen to my Github info?"

2 answers

1 accepted

3 votes

Answer accepted

Sounds unnecessarily complex... your JDBC url should contain the DNS alias for the database server, such that if the database is failed over then it the same url automatically points to the DR database system. Unless you are a very small company this should be provided for you by the DBAs I would have thought.

I don't use Crowd, but the same thing applies to LDAP servers. You point to one that gets round-robinned by DNS, and any that are down get dropped automatically. So I'd suggest you just set up DR for Crowd and use F5s or whatever to automatically have the crowd url directed to the correct crowd server.

We use a clustered filesystem so in the event of failover the filesystem is automatically mounted on the DR machine. If we had to change configuration files or ensure that they had not been synced that would just increase the chance of a problem in an already panicked situation.

In short, at least for the DB thing, try to leverage whatever your DBAs recommend.