Sequence consistency

UPDATEtransactions that use sequences trigger by-value replication. That is, the net effect or sequence values in changed rows are captured; the SQL querying the sequence values is not replayed on the replica. This means that a replica always has the same row values as the primary when sequences are used.

All UPDATE transactions against replicated data (both by value and by SQL) replicate the latest state of all replicated database sequences. If you follow the procedure for a planned promotion of a new primary (that is, alter the old primary to take on the replica role, catch up to the old primary final CSN on the replica, and then promote the replica), the sequence numbers are consistent, and no duplicate values are generated.

Forcibly promoting a replica that has not applied the primary final CSN can cause a transaction fork. This is because for a single previous CSN, there are multiple next CSNs, each representing a different system evolution. Because all UPDATE transactions replicate the sequence state, the result is that some sequence state is missed, together with some primary UPDATE SQL. The sequence value on the new primary does not duplicate any value on the previous primary before the last applied (as opposed to final) CSN.

When there is a transaction fork, the software detects it and suspends replication. At this point, use the nzreplfork -analyze command to explain and select the evolution that you want. Then, use the nzreplfork -resolve command to pick the correct path forward; run this command on all NPS® nodes in the replication set. Finally, follow the recovery instructions as provided by the output of the nzreplfork -resolve command.