This repository has been archived by the owner on Jun 1, 2021. It is now read-only.
Potentially Inconsistent EventLogClock snapshot in Cassandra backend in case of disaster recovery #393
Comments
volkerstampa
added a commit
that referenced
this issue
Jun 28, 2017
When writing the adjusted event log clock after disaster recovery also update the index up to the last sequence nr to ensure that the written event log clock snapshot is consistent with the index. Closes #393
cstub
pushed a commit
that referenced
this issue
Jun 29, 2017
When writing the adjusted event log clock after disaster recovery also update the index up to the last sequence nr to ensure that the written event log clock snapshot is consistent with the index. Closes #393
cstub
pushed a commit
that referenced
this issue
Jun 29, 2017
When writing the adjusted event log clock after disaster recovery also update the index up to the last sequence nr to ensure that the written event log clock snapshot is consistent with the index. Closes #393
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
At the end of disaster recovery the current sequence number of the recovered log is set to the maximum of the its current value and the log's entry in the current version vector to compensate for potentially unrecovered (lost) events from filtered replication connections. To ensure that this adjustment survives restarts it is immediately persisted in form of an
EventLogClock-snapshot. However in case of the Cassandra backend this snapshot is also used as indication up to which sequence number events are already indexed (stored in the corresponding aggregate table). So after the adjustment events that have not been indexed yet are basically lost for the corresponding aggregates.The text was updated successfully, but these errors were encountered: