You can perform actions on the Primary and Standby servers in replication environments where very low latency exists between the servers. An example environment would be where a Primary and Standby server exist in the same data center, and an optional Tertiary Address Manager server in a separate data center for disaster recovery scenarios. In this environment, you can perform actions using the API and GUI of the Primary and Standby Servers.
The Primary server remains the active node and maintains the primary database. The Standby server maintains an up-to-date instance of the primary database in case of a failover. When actions are performed on the Standby through GUI or API interactions, the Standby server forwards all database requests to the database on the Primary server where it is processed on the primary database. This information is then replicated back to the Standby server so that the database on the Standby server remains up-to-date.
When using the Standby and Primary servers, actions are performed quicker on the Primary server, as the database processing the information is local to the system. BlueCat recommends only performing actions on the Primary and Standby servers when the latency between the servers is close to 0ms, with a maximum of 5ms. If the latency exceeds 5ms, you might experience a performance impact on the Standby Servers.
If a disaster recovery scenario occurs in the example scenario and you must fail over to the Tertiary server located in a separate data center, you must only perform actions on the new Primary server upon the successful failover. The latency between the two data centers would impact the performance of the servers.