Difference between revisions of "Repository mirroring"

From OpenKM Documentation
Jump to: navigation, search
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
To enhance OpenKM availability you can have two instances of the application running in different servers. If the principal server gets down due to a hardware failure you can switch to the mirrored server and keep working.
 
To enhance OpenKM availability you can have two instances of the application running in different servers. If the principal server gets down due to a hardware failure you can switch to the mirrored server and keep working.
  
<center>[[File:Okm installation guide 018.png]]</center>
+
[[File:Okm installation guide 018.png|center]]
  
 
The replication only is done in one direction: from main server to mirror server. Mirror server can be configured to be in read-only mode so users can't add or modify documents. This behavior can be achieved using the system.readonly configuration parameter.
 
The replication only is done in one direction: from main server to mirror server. Mirror server can be configured to be in read-only mode so users can't add or modify documents. This behavior can be achieved using the system.readonly configuration parameter.
  
The follow script will propagate the repository changes from man server to mirror server:
+
The follow script will propagate the repository changes from main server to mirror server:
  
 
<source lang="bash">
 
<source lang="bash">

Latest revision as of 19:45, 19 December 2012

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

Okm installation guide 018.png

The replication only is done in one direction: from main server to mirror server. Mirror server can be configured to be in read-only mode so users can't add or modify documents. This behavior can be achieved using the system.readonly configuration parameter.

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

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

# Stop local JBoss
/home/openkm/OpenKM/secure_stop.sh

# Stop remote JBoss
ssh root@192.168.1.101 '/home/openkm/OpenKM/secure_stop.sh'

# Sync OpenKM repositories
rsync -rahe 'ssh -p 22022' --stats --delete --exclude OpenKM/OpenKM.cfg --exclude OpenKM/server/default/log /home/openkm/OpenKM
root@192.168.1.101:/home/openkm

# Start local JBoss
/etc/init.d/jboss start

# Start remote JBoss
ssh root@192.168.1.201 '/etc/init.d/jboss start'

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

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.

Note that both OpenKM are installed at the openkm user home (/home/openkm) for simplicity.

And this is the secure_stop.sh script:

#!/bin/bash

# Stop JBoss
/etc/init.d/jboss stop
while [ "$(ps -ef | grep java | grep jboss | wc -l)" -gt "0" ]; do
   sleep 5; echo ".";
done