This scenario describes a Master Live Server malfunction. This error influences two processes:
publication: Publications are canceled as defective, blocked or cannot be carried out because the Master Live Server is not reachable.
replication: Replication is disabled. The Replication Live Servers stay online and the connected CAEs continue to operate with the already replicated content base.
Possible errors are:
| Master Live Server Failure | |
|---|---|
| Error behavior |
The Replication Live Servers connected to the Master Live Server discontinues replication and attempts to log on again to the Master Live Server periodically in order to continue replication. Log attempts are written to the server log. Publications are no longer possible and the publication which was running at the time of disruption fails. You will see an error message if you try to start a publication or publication preview with CoreMedia Studio. |
| Error correction | In an environment without cluster, the watchdog of the Master Live Server detects the failure and restarts the server. In the cluster environment, the cluster software controls the watchdog (probedog). After server restart, the Replication Live Server log onto the Master Live Server and publications are possible again. |
Table 2.1. Master Live Server failure
|
Master Live Server Deadlock | |
|---|---|
|
Error behavior |
The clients hang up or receive error messages until the watchdog restarts the server. |
|
Error correction |
The watchdog detects the error and restarts the server. Restarting the server implies a brief server failure. Therefore, the further behavior of the clients corresponds to the behavior described under Live Server Failure. |
Table 2.2. Master Live Server deadlock
|
Master Live Server Database Failure | |
|---|---|
|
Error behavior |
Transactions which are active at the time of failure or which first notice the failure are terminated with an error. The error is passed to the server and clients. Further publications lead to errors. The Replication Live Servers detect the malfunction and attempt to reconnect. You can see the login attempts in the server log. Transactions started after the server has detected the database failure are blocked until a new database connection is created. Clients (replication of the Live Server, publication, etc.) remain paused. Appropriate messages are written to the server log. |
|
Error correction |
As soon as the database is available again the server creates new connections to the database (watch the server log) and blocked transactions are released. Note: Error-free operation after a database breakdown cannot be guaranteed, since external components are also affected (for example the JDBC driver). If an error occurs here, it is usually recognized by the watchdog and remedied by restarting the server. |
Table 2.3. Database failure
 |  |  |
 |