Instance replication

To enhance OpenKM's availability, you can have two instances of the application running on different servers. If the principal server goes down due to a hardware failure, you can switch to the mirrored server and keep working.

If you want a typical high availability configuration, you can use the Cluster configuration, but it is a complex architecture if you want to achieve a real high availability scheme. There is another option, easier to setup and also provides good protection against a server failure. This is somewhat like a simplified cluster configuration where the main instance is synchronized with the backup instance. For example, this can be done using a software solution like Rsync, which minimizes the transfer of data. 

In this scheme, we assume:

• Each node has its own document repository and database.
• The backup instance is supposed to be a clone of the main instance.
• In case the main instance is down, you should send the client request to the backup instance.

When the main server is down, the backup one becomes the new main server, so the old main server is now the backup one (well, when it is available again).

This is the configuration of each server:

Main server

• OpenKM is configured normally.
• The database is configured to send modifications to the backup instance.
• Rsync is configured to send datastore modifications every few minutes to the backup server.

Mirror server

• OpenKM is configured in read-only mode.
• The database is configured to accept modifications from the main instance.
• Datastore files are periodically updated by the Rsync tool from the main server.

Different implementations

The provided solution is not the only one, but the simplest.

An improvement over this first approach is using an external file server (connected by NFS) so Rsync is not needed. Using a NAS solution that improves the data backup and availability. It is highly recommended if the stored information is critical for your business.

Another improvement is related to the database. Some databases can be configured in master / slave mode, which is the required mode for this server configuration. But you can also deploy the database in a dedicated server (which should also be replicated), but some providers like Oracle offer specific database cluster solutions, which should be taken into consideration.

Sample Linux implementation

The following script will propagate the repository changes from the main server to the mirror server:

#!/bin/bash
TOMCAT_HOME="/home/openkm/tomcat-9.0.76"
REMOTE_HOST="root@192.168.1.102"
MYSQL_PASS="*****"

echo -e "### BEGIN: $(date +"%x %X") ###\n"

# Stop local OpenKM
/etc/init.d/openkm stop

# Stop remote OpenKM
ssh $REMOTE_HOST '/etc/init.d/openkm stop'

# Sync OpenKM repositories
rsync -avh --stats --delete --exclude repository/.system.key --exclude logs $TOMCAT_HOME ${REMOTE_HOST}:/home/openkm

# Dump and copy database
mysqldump -u root -p${MYSQL_PASS} okmdb | ssh $REMOTE_HOST "mysql -u root -p${MYSQL_PASS} okmdb"

# Start local OpenKM
/etc/init.d/openkm start

# Start remote OpenKM
ssh $REMOTE_HOST '/etc/init.d/openkm start'

echo -e "\n### END: $(date +"%x %X") ###"

Copy the following SQL into the remote $TOMCAT_HOME/start.sql server location.

update OKM_CONFIG set 'true' where CFG_KEY='system.readonly';