You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<!-- Describe your change here -->
After rotation, we now reset the number of events to 1 (not 0),
because the checkpoint event is sourced on restart. This avoids
a mismatch between the rotation check on startup and during normal
operation.
That discrepancy was the cause of inconsistent rotation log ids after
restarts.
Also, we changed the rotation condition to use (>) instead of (>=),
preventing a follow up rotation on start up when the configured
threshold is 1
(since checkpointing would immediately trigger a new rotation).
Lastly, a checkpoint event id now matches the last persisted event id
from its preceding rotated log file, preserving sequential order of
event ids across logs.
This also makes it easier to identify which rotated log file was used to
compute the checkpoint,
as its event id matches the file name suffix.
---
<!-- Consider each and tick it off one way or the other -->
* [X] CHANGELOG updated or not needed
* [X] Documentation updated or not needed
* [X] Haddocks updated or not needed
* [X] No new TODOs introduced or explained herafter
Copy file name to clipboardExpand all lines: docs/docs/dev/architecture/event-sourcing.md
+27Lines changed: 27 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -36,3 +36,30 @@ When implementing an event source or sink, you might want to consider testing th
36
36
-[ ] Concurrent use of `sourceEvents` is possible
37
37
38
38
-[ ] General: allocated resources are released (use with/bracket pattern)
39
+
40
+
### Event Log Rotation
41
+
42
+
Long-living heads may produce a large number of persisted events, which can impact the restart time of the hydra-node as it needs to read in all the previous to recreate its state.
43
+
44
+
Event log rotation was introduced to improve recovery times by reducing the number of events that need to be replayed on startup. This is achieved by periodically replacing the current event log with a new one that starts from a checkpoint event, which captures the latest aggregated head state.
45
+
46
+
Only rotated log files are saved with an incrementing `logId` suffix in their names, while the main `state` log file remains unchanged to preserve backward compatibility. This `logId` suffix corresponds to the ID of the last event included in that file.
47
+
Rotation can be enabled via the optional `--persistence-rotate-after` command-line argument, which specifies the number of events after which rotation should occur.
48
+
> For example, with `--persistence-rotate-after 100`, you’ll get rotated files named: state-100, state-200, state-300, and so on, each containing 101 events. This is because event IDs start at 0, so state-100 includes 101 state changed events (0–100) without a checkpoint. Subsequent rotated files include a checkpoint plus 100 new state changed events.
49
+
50
+
Note that a checkpoint event id matches the last persisted event id from the previous rotated log file, preserving the sequential order of event ids across logs.
51
+
This also makes it easier to identify which rotated log file was used to compute the checkpoint, as its event id matches the file name suffix.
52
+
53
+
Depending on the rotation configuration used, the current `state` file may already contain more events than the specified threshold, causing a rotation to occur immediately on startup before any new inputs are processed.
54
+
55
+
Upon rotation, a server output is produced to notify external agents when a checkpoint occurs, allowing them to perform archival or cleanup actions without interrupting the Hydra Head.
56
+
57
+
The appropriate value for `--persistence-rotate-after` depends on your specific use case and the expected transaction volume.
58
+
59
+
> As a rough guideline, in a simple scenario (running a single party on devnet that repeatedly re-spends the same committed UTxO) we observed that setting `--persistence-rotate-after 10000` results in rotated log files of about 8 MB every 3 minutes.
60
+
>
61
+
> Keep in mind that the size and frequency of rotated files will vary depending on several factors:
62
+
> * Transaction sizes: Larger transactions result in larger event payloads.
63
+
> * Number of party members: More parties increase the number of L2 protocol messages per snapshot, generating more events.
64
+
> * Ledger UTxO size: A higher number of UTxOs increases the size of certain events like snapshots.
65
+
> * Transaction throughput (TPS): Higher TPS leads to more events being produced over time.
0 commit comments