There are two possibilities to recover a corrupted Master Live Server database.
Recovery with Master Live Server's backup
Stop the Master Live Server. The Replication Live Servers will still be running. However, no publications will be possible.
Restore the backup of the Master Live Server.
Restart the Master Live Server; since the Replication Live Servers do have a newer content base than the Master Live Server, no replication is possible and the Replication Live Servers have to be recovered as well.
Recover the Replication Live Servers as described in Section 3.10.4, “Restoring from Replication Live Server Backup”.
Because a backup for the Master Live Server has been restored, all publications executed in the time between creating and restoring the backup are not available on the Live side. You can use the tool republish (see Section 3.14.3.6, “Republish”) to repeat the publications automatically.
Fast Recovery with Replication Live Server's backup
Be aware, that it might be necessary to copy the database backup to other Replication Live Servers, as well (see step 2).
Stop the Master Live Server.
To select the Replication Live Server database from which you want to take the backup, you have to take the current sequence numbers of all Replication Live Servers. You get the sequence number by executing the following SQL statement on every Replication Live Server database:
SELECT * FROM system WHERE property='replicator_remote';The sequence number of some (or all)Replication Live Servers will be the same. If not, determine the most often occurring sequence number. In the following, this sequence number is called dedicated sequence number.
Choose one of the Replication Live Servers that has the dedicated sequence number.
In the following, this server is called the dedicated Replication Live Server. Its data will be used to recover the Master Live Server and all Replication Live Servers with a different sequence number than the dedicated sequence number.
It is important that the dedicated Replication Live Server is in a consistent state. To check this, the table
ReplicatorIdTablehas to be empty. When the table is not empty, the Replication Live Server is inconsistent. To see the table content, execute the following statement. If the server is inconsistent, choose another Replication Live Server as the dedicated Replication Live Server:SELECT * from ReplicatorIdTable;
Create a backup of the dedicated Replication Live Server's database using database tools. Note that the Replication Live Server needs not to be stopped.
If the passwords on the dedicated Replication Live Server have been encrypted via
cm encryptpasswords, the Rijndael key of the Replication Live Server in the fileWEB-INF/etc/keys/<databasename>.<dbuser>.rijndaelhas to be copied to the respective directory on the Master Live Server (<databasename>and<dbuser>have to be adjusted to the appropriate values of the Master Live Server database). If the directory does not exist on the Master Live Server, you must create it.
The file must also be copied to all Replication Live Servers with a different sequence number than the dedicated sequence number.
Delete the full Master Live Server database schema using database tools.
Import the database backup into the database of the Master Live Server using database tools.
On the Master Live Server, fetch the last changelog entry with the following SQL statement and note the values of
<sequenceno>and<idtag>:
SELECT * FROM changelog WHERE sequenceno = (SELECT max(sequenceno) FROM changelog);
On all Replication Live Servers with the same sequence number as the dedicated sequence number, adjust the replicator settings with the following SQL statement (note, that the Replication Live Servers do not have to be stopped, but make sure that the Master Live Server is still not running). Replace
<sequenceno>and<idtag>with the values obtained above:
UPDATE system SET content='<sequenceno>' WHERE property='replicator_remote';UPDATE system SET content='<sequenceno>' WHERE property='replicator_local';UPDATE system SET content='<idtag>' WHERE property='replicator_tag';
All Replication Live Servers with a different sequence number than the dedicated sequence number must be recovered. To recover, execute the steps 5., 6., and 8. (read Replication Live Server instead of Master Live Server).
Restart the Master Live Server and the Replication Live Servers. Now you can publish content from the Content Management Server, and Replication Live Servers can replicate the content.
Note, there might be some inconsistencies between Content Management Server and Master Live Server in respect of some publication events, that did not reach the dedicated Replication Live Server. This is the case
if the dedicated Replication Live Server is not the one with the highest sequence number,
if the dedicated Replication Live Server has not been connected to the Master Live Server for a longer time, that is that there were publication events that did not reach the Replication Live Server,
if the Master Live Server database crash did hinder the replication process between Master Live Server and Replication Live Servers.
In all these cases, you have to replay all affected publications on the Content Management Server. To detect the affected publications, you can use the Site Manager to query all publication events in the specific period.
 |  |  |
 |