close

Filter

loading table of contents...

Content Server Manual / Version 2310

Table Of Contents

3.9.5 Restoring from Master Live Server Backup

If you are a skilled administrator, you do not need to create backups from Replication Live Server. Instead, you can use a backup from the Master Live Server. However, this procedure requires that you execute some SQL statements. To restore a Replication Live Server database from a Master Live Server backup you have to do the following:

Caution

Caution

If you have a client connected with your Replication Live Server that uses the timestamp of the server (for example, the CAE Feeder) you have to find the last "sequenceno" in the "ChangeLog" table of the Master Live Server and Replication Live Server where both servers where in sync. You also have to check, if the client has already processed this event. Do this, before you replace the Replication Live Server database.

Finding the last common sequence number

Finding this sequence number is a bit tricky, because the numbers are different on different Content Servers. Therefore, you have to find the last common event in the ChangeLog (see Section 2.5, “Changelog”) tables of both Content Servers. To do so, proceed as follows:

  1. Find the last event in the ChangeLog table of the Replication Live Server that has been processed. The event should not have "code=15" because this indicates a local event:

SELECT * FROM ChangeLog WHERE sequenceno = (SELECT max(sequenceno)
 FROM ChangeLog WHERE code != 15);
  1. To find this event in the ChangeLog table of the Master Live Server you need the values of the following table columns: Code, I1, I2, I3, B1, B2, S1, S2, S3. Execute the following SQL statement on the Master Live Server's database, replace the values in angle brackets with the according values from the Replication Live Server, :

SELECT sequenceno FROM ChangeLog WHERE code=<ReplicationCode>
AND I1=<ReplicationI1> AND I2=<ReplicationI2> AND I3=<ReplicationI3>
AND B1=<ReplicationB1> AND B2=<ReplicationB2> AND S1=<ReplicationS1>
AND S2=<ReplicationS2> AND S3=<ReplicationS3>

This gives you the sequence number for further processing in "Clients and Timestamps" below.

Now, you have to check if the client has already processed the event with this timestamp. Otherwise, you might lose events. In the case of the CAE Feeder execute the following SQL script on the CAE Feeder's database:

SELECT * FROM pcproperties;

This returns a result as shown in the following example:

com.coremedia.amaro.persistentcache.propertystore.PropertyVerifier
-application caefeeder
com.coremedia.amaro.cae.feeder.IndexVerifier CAEFEEDER:1252067316056
ContentDependencyInvalidator-timestamp 442525:1:866469822
com.coremedia.cap.persistentcache.proactive.content.ContentTrigger.
timestamp.trigger 442366:6:866469822

Take the content of the properties with "timestamp" in their name. The first number in the content of these properties is the sequence number of the last event. These numbers must be equal or larger than the common sequence number you have found above. If it is smaller, you have to look for a smaller common sequence number, otherwise you would lose events in the CAE Feeder.

Restore the database
  1. Stop the Replication Live Servers.

  2. If the database does not allow you to take online backups ensure that all publications are finished and that the last publication was successful. Freeze the content of the Master Live Server, so that no new publications are allowed. If possible, stop the Master Live Server.

  3. Create a backup of the Master Live Server database with the database backup tool.

    Note

    Note

    When you dump the database content you will get Workflow Server view tables which lead to problems during the replay of the dump. Since these tables are not required on a Replication Live Server you can exclude them from the dump. The table names are:

    • mls.WFVPIStates

    • mls.WfVTIStates

    • mls.WfVTokens

    With the MySQL dump tool, for example, you can use the parameters --ignore-table, to exclude specific tables.

  4. If the passwords on the Master Live Server are encrypted with cm encryptpasswords, the Rijndael key of the Master Live Server in the file $INSTALL_DIR/etc/keys/<databasename>.<dbuser>.rijndael has to be copied to the respective directory on the Replication Live Servers (<databasename> and <dbuser> have to be adjusted to the appropriate values of the Replication Live Server database). If the directory does not exist on the Replication Live Servers, it has to be created.

  5. If stopped, start the Master Live Server. You may continue to start publications again.

  6. Delete the full Replication Live Server database schema, if existent.

  7. Restore the database of the Replication Live Servers with the backup.

  8. On the Replication 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);
  1. On the Replication Live Server, adjust the replicator settings with the following SQL statement. Replace <sequenceno> and <idtag> with the values obtained above:

INSERT INTO System (property, content) VALUES ('replicator_remote',
 '<sequenceno>');
INSERT INTO System (property, content) VALUES ('replicator_local',
 '<sequenceno>');
INSERT INTO System (property, content) VALUES ('replicator_tag',
 '<idtag>');
  1. Remove the content of the named license tracking table:

DELETE FROM CmLicenses
  1. Set the proper server type.

UPDATE System SET content='live' WHERE property=
'repository_server_type' AND content='publication'
  • As a result you must see: Updated 1 rows

  1. Restart the Replication Live Server.

Clients and Timestamps

The CoreMedia systems uses timestamps to synchronize servers and clients. If you replace the database of a Replication Live Server with the database of a Master Live Server, the timestamp of the Replication Live Server will be replaced by the one of the Master Live Server. Every client, that connects with the Replication Live Server and that stores and uses the timestamp - such as the CAE Feeder - will stop working because the stored timestamp is different from the new timestamp of the Replication Live Server.

In order to synchronize client and server again, you have to replace the timestamp stored by the client with the timestamp of the server. To do this for the CAE Feeder, proceed as follows (replace the angle brackets with the appropriate value):

  1. Find a sequenceno that originates from before the stop of the Replication Live Server as described above and that has been processed by the client.

  2. Execute the following SQL statement on the Master Live Server database:

SELECT * FROM ChangeLog WHERE sequenceno=<No from step 1>
  1. Extract the timestamp from this information. The timestamp has the format: SEQUENCENO:1:IDTAG with the values taken from the row of the user publisher. This timestamp will be called Master Timestamp below.

  2. Stop the client.

  3. Execute the following SQL statements on the clients database:

UPDATE pcproperties SET content='<Master Timestamp>' WHERE
property='com.coremedia.cap.persistentcache.proactive.
content.ContentTrigger.timestamp.trigger';
  1. Check if the property "ContentDependencyInvalidator-timestamp" exists. If it exists, execute the following statement.

UPDATE pcproperties SET content='<Master Timestamp>' WHERE
property='ContentDependencyInvalidator-timestamp';
  1. Start the CAE Feeder again.

Now, the feeder starts working again. Log errors like "Illegal transition for feeder:coremedia:///cap/content/701282:add" are harmless. They only say, that this content has been fed before.

Search Results

Table Of Contents
warning

Your Internet Explorer is no longer supported.

Please use Mozilla Firefox, Google Chrome, or Microsoft Edge.