1 week after setting up fault tolerance, we stopped getting new events, except for the following 2, which we receive daily.
0x10c0a Landscape 0x5000000 on SpectroSERVER xxx port 0xbeef at precedence 20 is a secondary to SpectroSERVER yyy port 0xbeef at precedence 10. 0x10c34 Landscape 0x5000000 on SpectroSERVER xxx at precedence 20 deleted 31698 events at Secondary startup.
These messages show that the Fault tolerant secondary SpectroSERVER is active and being displayed in OneClick. What is the cause of 0x000010c34?
When Secondary server loses contact with Primary server, a fail over state occurs and the secondary SpectroSERVER takes over the monitoring. If the Archive Manager on the primary is also not available, the events will be stored as local events on the secondary SSDB (SS/events.db), or in the DDMDB of the secondary if the secondary Archive Manager is enabled.
Generally startup events should be preserved, except in the case where the Secondary is started and the primary is already running, such as an Online Backup. If "delete_secondary_startup_events" is set to true, then event 0x10c34 will be generated. The Secondary Startup events are things like model activation, etc and re unnecessary so are deleted by default. These "deleted" events have nothing to do with any of the regular Spectrum monitoring events.
The following entries need to be added to the .vnmrc of the secondary and the secondary SpectroSERVER restarted.
The value for secondary_polling will depend on the readiness level of fault tolerance you desire. See below for more information.
A secondary SpectroSERVER is considered to be at one of three different levels of readiness. Readiness depends on server configuration and status. The readiness levels are defined as follows:
The secondary SpectroSERVER is running and is available to take over immediately upon failure of the primary SpectroSERVER because it is already polling. To configure a secondary SpectroSERVER for this level of readiness, add the following line to the .vnmrc file: secondary_polling=yes. This statement causes the standby to commence polling and processing traps whenever it starts, regardless of its connection status with the primary SpectroSERVER.
The secondary SpectroSERVER is running, but the server can take a short time to become fully available. The secondary SpectroSERVER has not been configured to start polling until it loses contact with the primary SpectroSERVER. For example, it has no secondary_polling entry in the .vnmrc file, or the entry is set to no.
If the secondary_polling entry is not in the .vnmrc file or the entry is set to no, the secondary SpectroSERVER does not process traps while in standby mode.
The secondary SpectroSERVER is not running and must be started when there is a failure of the primary SpectroSERVER. In this case, it is irrelevant whether the secondary SpectroSERVER is configured for secondary polling.