Sophora Server Modes and Connected Sophora Servers

The property sophora.replication.mode in the sophora.properties file selects the mode in which the Sophora Server is started. There are four different modes: none, master, slave and stagingslave. You also have the option to select cluster as the replication mode and specify the Sophora Server mode with the additional property clusterMode. Valid cluster modes are master, slave and open (the Sophora Server starting first becomes master).

Sophora Server Modes

The property sophora.replication.mode in the sophora.properties file selects the mode in which the Sophora Server is started. There are the four different modes none, master, slave and stagingslave, and a fifth option of choosing the replication mode cluster.

None

The Sophora Server starts in a stand alone mode. No JMS broker is launched and no JMS connection to a broker is established. This mode is useful for test systems without any slaves. Another use case is to temporarily disconnect a Sophora Staging Server from its Sophora Primary Server. Normal Sophora Delivery Servers do not start without a connection to its Sophora Primary Server. To start the Sophora Server on the Delivery Server anyway, the Sophora Server can be started in mode none.

Sophora Primary Server

This is the normal mode for the main Sophora Server. In this mode, a JMS broker is launched within the Sophora Server process. With the help of this JMS broker, slaves can connect to the Sophora Primary Server and receive documents etc.

Slave

This mode is also called Replication Server or Backup Server. In this mode, the slave receives all data from the Sophora Primary Server. Thus, it is a complete copy of the Sophora Primary Server and can be used in cases where the Sophora Primary Server is not available. Only administrators (Sophora users with a role possessing the system permission ADMIN) can log on to the Sophora Server.

Slaves are connected to a persistent JMS queue in the Sophora Primary Server. Thus, no special synchronization is needed if the slave is temporarily disconnected from the Sophora Primary Server.

Sophora Staging Server

The mode stagingslave is used for the Sophora Servers in the delivery. In this mode, the slaves receive only published data from the Sophora Primary Server. When documents are put offline in the Sophora Primary Server, the corresponding documents on the Sophora Staging Server are marked as deleted. The version history of documents is not maintained on Sophora Staging Servers. Documents are only available in their last published Version.

When started, the Sophora Staging Servers always send a Sync-Request to the Sophora Primary Server. Based on the last modification date of a document on the slave, the Sophora Primary Server sends all new documents (and other data) to the slave.

Cluster

If you choose the replication mode cluster, you also have to set the additional property clusterMode. Possible values are master, slave and open. Choosing the cluster modes master or slave will basically have the same effect as choosing master or slave as the replication mode. If you set the cluster mode to open, the first server from the cluster that is started becomes the Sophora Primary Server. All other cluster Sophora Servers will serve as fallback slaves.

Getting the Sophora Server Mode

You can 'ask' any Sophora Server for its server mode. Calling the URL pattern http://<Hostname of the master>:<HTTP port>/serverMode will return a JSON snippet containing the server mode, for example:

{"serverMode":"MASTER"}

Possible values are: "STAGING_SLAVE", "REPLICATION_SLAVE", "MASTER" and "NONE".

Getting All Connected Slaves

You can 'ask' the Sophora Server for its connected Sophora Staging Servers. This function is only available, if the server has been started with the property

sophora.replication.mode=master

Calling the URL pattern http://<Hostname of the master>:<HTTP port of the master>/replicationSlaves/ will return a comma separated list of all currently connected slaves, for example:

MASTER:serverM
REPLICATION_SLAVE:
STAGING_SLAVE:staging1,staging2

In this example, the Sophora Primary Server has two connected Sophora Staging Servers (staging1 and staging2), but no Replication Server.

The returned list of Sophora Staging Servers contains the names of those servers which are connected to the Sophora Primary Server at that moment. The returned list of Replica Servers contains all Replication Servers which are currently or have been connected at some time. This means that Replication Servers in the returned list are not necessarily connected to the Sophora Primary Server right now.

To configure the name of a replication or Sophora Staging Server, you have to edit the following property in the sophora.properties file:

sophora.replication.slaveHostname=staging1

If this property is empty, the hostname is determined automatically. However, the property has to be present.

Shell Script to Determine the Slaves

The following shell script provides the function get_slaves which you can pass an URL and the desired type of slave. The function returns a list of slave names which you might want to iterate through. A corresponding example is given below.

#!/bin/bash
 
# get_slaves URL TYPE
function get_slaves() {
 wget -q -O - "${1}" |perl -ne "if (/^${2}:.+/) { s/^${2}://; print join(\"\\n\", split /,/); }"
}
 
get_slaves "http://master.subshell.com:1196/replicationSlaves" "STAGING_SLAVE" |while read slave ; do
 echo "slave: ${slave}"
done

Managing a JMS Connection Between Sophora Primary Server and Sophora Staging Server

It is possible to disconnect an active Sophora Staging Server from the Sophora Primary Server. Thus, the Sophora Staging Server will no longer receive JMS messages, and changes in the content are not recognized by the delivery. This behavior might be desired if there is maintenance to do at the Sophora Primary Server while the deliveries should continue their work. Therefore, it is also possible to reconnect the Sophora Primary Server and its slave. The first thing taking place afterwards is a synchronization.

Starting/Stopping the Sophora Staging Server via HTTP

Calling the URL pattern http://<Hostname of the slave>:<HTTP port of the slave>/stagingSlaveAdmin/<Operation> enables you to execute the subsequent operations remotely:

• /stop – Stops the JMS connection to the Sophora Primary Server .
• /start – Establishes a JMS connection and synchronizes the slaves.

Starting/Stopping the Sophora Staging Server via JMX

The start and stop operations may also be executed via the JMX interface by using the start/stop operations on the com.subshell.sophora/StagingSlaveAdmin MBean. The bean also provides the information whether staging is currently enabled or not.

Starting/Stopping the Sophora Staging Server via Shell Script

Starting the Staging

> cd cms-directory/sophora 
> ./sophora.sh startStaging

Stopping the Staging

> cd cms-directory/sophora 
> ./sophora.sh stopStaging