RSA AM 8.7 Update Question - Replicas & Replication

[msg9]

Working on a the RSA AM 8.7 Patch 4 update and had a failure to complete on the primary.

I confirmed replication status on the primary and replicas before beginning, and it was good, and showed recent times.  After the rollback, the Replicas couldn't sync.  Ended up restoring the VM snapshots and getting ready to try again, but wanted to post up here with some info I found and with a question.

Reviewing the log, I saw the following Replication related messages.  This is a snip.  There were prior "pending changesets" listed as well.

226496 2023-06-07 08:48:55,141 INFO: Processing all pending changesets from: /opt/rsa/am/replication/r2p_chgsets_to_apply...(19)
236497 2023-06-07 08:49:05,142 FATAL: Replication flush failed. Unable to process all pending changesets from: /opt/rsa/am/replication/r2p_chgsets_to_apply.
236517 2023-06-07 08:49:05,162 FATAL: 
Replication flush failed. Unable to process all pending changesets from: /opt/rsa/am/replication/r2p_chgsets_to_apply.
java.lang.AssertionError: Replication flush failed. Unable to process all pending changesets from: /opt/rsa/am/replication/r2p_chgsets_to_apply.

My question is - could this be related to a connectivity issue between the primary and replicas during the update process, or does Replication Status only need to show Normal just before initiating the update on the Primary?

I am familiar with the replication requirement from previous upgrades and updates, but am unsure whether there is a requirement for continued connectivity during the update process?

In a replicated deployment, all replica instances must be running and replicating successfully 
before you apply the update to the primary or replica instances.

To verify the replication status, log on to the primary instance Operations Console, and then 
click Deployment Configuration > Instances > Status Report.

[MichaelJones3 · Accepted solution]

20230609

Post redacted. See article 000047250 for assistance.

[EricaChalfin · Accepted solution]

@msg9 and @MichaelJones3,

While the commands provided are mostly correct, I am going to redact your post. I am doing this because the UPDATE command that you provided resets the out of synch flag for all replicas, not just the one that is out of synch. This could be problematic in a deployment with more than one or two replicas.

For anyone who is seeing an internal replication error should contact RSA support for assistance. and ask for assistance using the solution in article 000047250.