The CRS Cluster uses the publisher/subscriber database model for data replication across the system. Under normal circumstances, the publisher acts as the source of data and the subscriber acts as the target for the data. The publisher/subscriber database model enables CRS to provide high-availability and failover support. To support this on the database level, the data must be available on multiple nodes of the cluster. To have such data availability, replication is used for the Agent, Historical, and Repository datastore.
The Configuration datastore does not use replication; instead, it uses atomic transaction to commit data changes to all active Configuration datastore in the cluster.
The publisher is the main database. All data is written to this database, with the other databases (subscribers) synchronizing with the publisher. If the publisher fails, then data can be written to the subscriber(s). When the publisher is back online, it returns to accepting writes. It also synchronizes with the subscriber(s) by performing the following functions:
â¢ Adding any files or records that are new.
â¢ Deleting any files or records that have been removed.
â¢ Updating any files or records that have a later modification time stamp on the subscriber database.
When the publisher is fully synchronized, then all subscribers return to synchronizing with the publisher.
So what way it change when you boot your primary backup
These are the paths to get to each CCX logs through CLI. They may be helpful if you are having issues accessing RTMT or downloading logs through it.
If you want to download them you have to prefix "file get " and you can add one of the options (re...