When the primary server is in control, both the primary and the secondary server log alarm and point data into their separate databases. As a result, if the primary fails the secondary computer can continue to log data without loss of information.
When you bring a server back on line after a failure, a datamerge.exe utility:
Executes a merge from the primary to the secondary server.
Executes a merge from the secondary to the primary server.
See Recovery Procedures in this documentation for more information.
The ability to conduct an accurate merge begins with your configuration.
Guidelines for Redundant
Logged Database Identification
When you set up your redundant logged database configuration, you have to make sure that both the primary and secondary servers know where to log their own data. You also have to make sure that the primary server knows where the secondary server is logging data, in case it needs to access the secondary logged database after a failure.
When setting up redundant logged databases:
Set up the same database on the primary and secondary servers so you will have two actual databases that, under normal operation, will be identical.
Give the database on each redundant server:
The same name as the database on
the other server
A different name Data Source Name
(DSN) from the corresponding DSN on the other server
Set up the primary server to point to:
Its own database
The database on the secondary
server
Set up the secondary server to point to
Its own database.
The database on the primary
server.
See Server Redundancy Configuration Procedures in this documentation for configuration details.
Important: Viewer applications, such as
Trending, that use logged data from a server will not fail over to
the database on the redundant server.
|
|
Configuration details. |
|
|
Automatic redundancy operation overview. |
