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 -->
- Event log rotation enable hydra heads to resume faster by reducing
replay time.
- Rotating an event log means replacing the current state file with a
new one that starts from a checkpoint event, while moving the old file
to the next state-logId.
- A Checkpoint event captures the latest HeadState, computed by
aggregating all previous StateChanged events.
- File-based persistence rotates event log files using an increasing
index named logId, based on latest StateChanged event id + 1.
- Added a new run option to enable rotation after a given number of
events:
_"The number of Hydra events to trigger rotation (default: no
rotation)"_
- On startup, depending on the rotation config used, the event log file
might be rotated and the `logId` index will be incremented.
- Added new server output to allow 3rd party agents to detect the
checkpoint and trigger any appropriate archival / backup / cleanup
needed, without interrupting the hydra head.
---
<!-- 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
---------
Co-authored-by: Sebastian Nagel <[email protected]>
Co-authored-by: Sebastian Nagel <[email protected]>
Copy file name to clipboardExpand all lines: docs/docs/dev/architecture/index.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -53,7 +53,7 @@ The `hydra-node` component exposes an [asynchronous API](https://hydra.family/he
53
53
54
54
### Persistence
55
55
56
-
All API server outputs and the `hydra-node` state are preserved on disk. The persistence layer is responsible for loading historical messages and the Hydra state from disk, as well as storing them. Currently, there hasn't been a need to increase the complexity of this layer or use a database.
56
+
The `hydra-node` state is preserved on disk. The persistence layer is responsible for loading historical messages and Hydra state from disk, as well as storing them in so-called event log files. Depending on the rotation configuration used at startup, these event log files will be rotated to improve restart times. So far, there hasn’t been a need to increase the complexity of this layer or to use a database.
If the hydra-node has breaking changes in regards to reading the files it stores in the `persistence` folder, it used to be recommended to just delete the entire folder.
49
49
50
-
Now, because of etcd, it is important to only delete the `hydra-node` specific files; not the files associated with `etcd`. In particular you may like to delete the following file:
50
+
Now, because of etcd, it is important to only delete the `hydra-node` specific files; not the files associated with `etcd`. In particular you may like to delete the following files:
51
51
52
-
-`persistence/state`
52
+
-`persistence/state*`
53
53
54
54
Note that, as with any adjustments of this kind, it is good practice to make a backup first!
0 commit comments