Upgrade Guide

This guide describes upgrades and rollbacks for Git MultiSite.

1. Upgrade from version 1.3.1.1 to 1.4

1.1 Assumptions

This guide describes an upgrade on a Centos 6.4 server - running on a different distribution may vary slightly.
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.

Email Notification settings are not preserved

Notification settings (which trigger alert emails) are lost as part of the upgrade from 1.2 to 1.2.1. In future upgrades these settings will be preserved.

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.3.1.1 to version 1.4:

Connect to each node in the 1.3.1.1 replication group, by command line, as root.

Backup your 1.3.1.1 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 1.4 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.

2. Rollback from version 1.4 to 1.3.1.1

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.3.1.1
- You can push to a repository successfully
- The pushed change is replicated across the entire replication group