how does log data replication work in AM 8.3 between the primary server and the replica servers?
As replicas authenticate users (run time data) and encounter errors (system data) the replicas send this data as change files to the Primary. The Primary incorporates that data into the internal database, at which point you can run an Authentication activity or System Log activity report on the primary and see this data reflected in the report. This data would be in the internal database that is replicated from primary to replicas. Usually Admin activity is done on the primary, except that a Replica can handle new PIN mode so that type of admin activity on a replica would follow the same path at the runtime and system data to the primary where it would be incorporated into the database and then available to be reported on at the primary and replicated out as part of the internal database to the replicas.
Based on archive settings for the three types of data; runtime, system log and administrative activity, at some point today's log data will be purged from the internal database at which time it will no longer be reflected in reports, and written to archive files (typically digitally signed). These archive logs are only written to the primary or written to a remote Windows or NFS file share, they are not written to replicas, but the changes to the internal database are replicated, so older data is removed consistently across all AM servers.
One other point, I've been talking about change files as the means to replicate data, but if you see the [SYNC] button on the replica status page in the Operations Console, when you [SYNC] a replica you send the entire primary internal database at that point in time to that replica. This process can be tricky when the WAN links are not really good, because the way it was engineered was not to use a reliable transport mechanism built into the TCP protocol to only retransmit dropped packets, if a packet is dropped the entire database transfer will start over, sometimes it never finishes! So Engineering added the manual SYNC update somewhere back in an AM 8.2 SP1 patch, so you can use SFTP.
000035778 - RSA Authentication Manager 8.2 Service Pack 1 Patch 6 introduces manual synchronization
Thanks for the answer. Two follow up questions.
First, after the replica sends the log data to the primary is it cleared from the replica database ?
Second, is the primary consolidated log data replicated to all replicas in the AM deployment ?
First: as far as I know the replica log data is not stored in the replica's copy of the internal database
Second: If by consolidated you mean into the internal database, then yes, since log data is consolidated into the Postgres internal database, then those changes are replicated back out to the replicas.
This is confusing. First you state that replica log data is not stored in the replica’s copy of the internal database but then in the second answer you state that the consolidated log data is replicated back out to the replica.
What I am trying to do is determine if our reporting team can use the replica servers for running SQL queries for log data information.
no, do not use replicas for log data or sql queries.
a) replicas will immediately log to themselves, any current system, admin, or authentication activity
b) if replication is up, the replica will attempt to offload all logs to the primary, so replica will soon have no logs
c) busy replicas should have one or maybe a dozen events in it's own log system but that will disappear when replication catches up, which is essentially immediately
d) if replication is not working, or primary down, only then do replicas start to accumulate logs, but it still is not in a 'reportable' format., it is stored until replication is resumed, or until that replica is promoted to primary
Retrieving data ...