Instance replication

To enhance OpenKM availability you can have two instances of the application running on different servers. If the principal server gets 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 a 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 what minimizes the transfer 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.

An option is to use a DNS which you can modify in case of server failure, or an HAProxy instance which properly configured can detect a problem in the main server and forward the request to the working one. 

Keep in mind that in this configuration only one server should accept client petitions.

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 modification from the main instance.
  • Datastore files are periodically updated by 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 which 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 database can be configured in master / slave mode, which the required mode for this server configuration. But you can also deploy the database in a dedicated server (which should be also replied) but some providers like Oracle offer specific database cluster solutions which should be taken in consideration.

Sample Linux implementation

The replication is done only in one direction, from main server to mirror server.

 The mirror server must be configured to be in read-only mode so users can't add or modify documents.

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

On the sample the main server

Both OpenKM are installed at the OpenKM user home (/home/openkm) for simplicity.

This script should be executed - by user root - from the main server, and can be scheduled to be executed every day using Linux cron utility, for example.

The script uses rsync to minimize network load and only modified or added documents will be transferred. The whole process can take a few minutes, depending on your repository activity.


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 localtion.

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

After the first synchronization, stop remote Tomcat,  update the start.sql script there and start the Tomcat again.