Resynchronising a newly restored ObjectServer
After an ObjectServer has been recovered, the next step is to resynchronize its data contents with the rest of the system so that it may resume normal service.
master_store.tab
and table_store.tab files, it is possible that operators might see the appearance
of old events from the time that the backup was taken. Restoring the ObjectServer through the
original SQL solution delivery files or the nco_osreport SQL files will avoid the
reappearance of old events.- Collection layer ObjectServer
An ObjectServer running at the Collection layer runs in isolation in that it does not have a connected backup counterpart. In the event of a catastrophic failure that has resulted in the ObjectServer being restored from a previous backup, there is no counterpart from which it can resynchronize. If there were any Probes connected to the ObjectServer prior to its outage, those Probes would have failed over to the counterpart and replayed any event data that was not forwarded to the Aggregation layer. Hence it is not necessary to restore the data contents of a Collection ObjectServer in the case of an outage.
- Aggregation layer ObjectServer
An ObjectServer running at the Aggregation layer runs as part of a primary-backup pair. In the event of a catastrophic failure of one of the members that has resulted in the ObjectServer being restored from a previous backup, the ObjectServer will automatically be resynchronised with its counterpart via the failover bidirectional ObjectServer Gateway.
- Display layer ObjectServer
An ObjectServer running at the Display layer runs in isolation in that it does not have a connected backup counterpart. Display layer ObjectServers, however, run as a replica of the acting Aggregation primary. In the event of a catastrophic failure that has resulted in the ObjectServer being restored from a previous backup therefore, a Display layer ObjectServer will simply resynchronize itself with the Aggregation layer and continue normal operation, if restarted.