Upgrade Guide

This guide describes upgrades and rollbacks for Git MultiSite.

1. Upgrade from 1.2 (or later) to latest version

1.1 Assumptions

You have root access on each node and also access to the user account that Git MultiSite is running under, typically this is the "gitms" user.
The procedure assumes that you are not changing your replication configuration. You're not adding or removing nodes from the replication group.

Changes to MultiSite's database format

Some updates may change MultiSite's internal DConE prevayler database format. For the update to work properly you will need to run the transformer tool to convert the currently installed version of Git MultiSites backup file to support the latest prevayler database format. This is discussed in more detail in the Update Procedure below.

IMPORTANT: upgrade one node first, then upgrade the rest in parallel
Select one node and run the upgrade on this node to completion. Type y to the question:

Is this the first node? y/N:

When this is complete you can then upgrade all the other nodes in parallel by typing n to answer this question.
Do not bring up any node until ALL of the nodes have been upgraded.

1.2 Procedure

If your upgrade of the initial node fails for any reason, then you must contact WANdisco Support immediately, without trying to upgrade any other nodes.

To upgrade from version 1.2 (or higher) to latest version:

Connect to each node in the existing replication system, by command line, as root.

Backup your v1.2 (or higher) databases on each node using the following command:

curl --user <admin user>:<admin password> -X POST http://<node ip address>:8082/api/backup

Make a backup of the replicator database to allow for rollback:

cp -r /opt/wandisco/git-multisite/replicator/database/* /path/to/your/backup/directory

Copy the latest installer script to each Node and run it as root.
Exit from your gitms account back to the root account
Start the git-multisite service:
```
service git-multisite start
```
Finally, check the following:
- All nodes have running replicators.
- Replicator and GUI versions are showing 1.4.
- You can push to a repository successfully.
- The pushed change is replicated across the entire replication group.

Changes to Tiebreaker node availability
It may be worth remembering that in Git MultiSite 1.4 the functionality for tiebreaker nodes changed slightly. After upgrading from an earlier version of Git MultiSite, if you make a change to a replication group that has an odd number of voter nodes, including a change to the schedule, any tiebreaker nodes will now lose their special tiebreaker designation. Tiebreaker nodes are now only available when there is an even number of nodes, along with the corresponding risk that a vote could be evenly split between voters. Note that this change wasn't applied after upgrading to Git MultiSite 1.4 but will apply only after you next alter an applicable replication group.

2. Rollback to previous version

If you need to roll back to the previous version of Git MultiSite, use the following procedure:

On each node, uninstall the current version using the following script:

#This script removes the install of git-multsite to be able to install cleanly
echo "Removing Git-Multisite RPMS"
yum remove -y git-multisite git-multisite-gui git-multisite-hook git-multisite-all
echo "Removing Git-Multisite Directory"
rm -rf /opt/wandisco/git-multisite
killall java
cd /tmp
rm -rf *
cd

On each node, re-install the previous version
Stop the git-multisite service:
```
service git-multisite stop
```
Remove the contents of the Git MultiSite database directory:
```
rm -r /opt/wandisco/git-multisite/replicator/database/*
```
Change to the gitms user:
```
su gitms
```

On each node, copy the content of your backed up database directory into place:

cd /opt/wandisco/git-multisite/replicator/database
cp -r /path/to/your/backup/directory/* .

Check the database directory and all its contents are owned by gitms:gitms and permissions are set to 755
Exit from your gitms account back to the root account
Restart the git-multisite service:
```
service git-multisite start
```
Finally, check the following:
- All nodes have running replicators
- Replicator and GUI versions are showing 1.4
- You can push to a repository successfully
- The pushed change is replicated across the entire replication group