During normal operation, Rhino’s in-memory state can sometimes be slightly ahead of its persisted management and key/value store state. This is caused by asynchronous writes, query batching, and similar implementation details designed to minimise unnecessary or blocking database interactions. Any unpersisted state is usually only seconds ahead of the persisted state, excepting exceptional error cases such as database connection failures where unpersisted state may accumulate until connection restoration.
A graceful termination of a Rhino node (e.g. via the shutdown command) will implicitly perform appropriate persistence operations for any in-memory state which has yet to be persisted, but it can be useful in some cases to explicitly trigger persistence:
-
where a Rhino node needs to be forcefully terminated and guarantees regarding persisted state are required; or
-
where external automated tooling needs certainty regarding configuration changes which have been applied via management APIs.
Rhino offers two housekeeping functions that assist with these cases by manually initiating persistence and blocking until completion.
These procedures are:
