[jira] [Updated] (IGNITE-19028) Implement safe-time propagation for meta-storage raft-group

["Ivan Bessonov (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-19028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivan Bessonov updated IGNITE-19028:
-----------------------------------
       Epic Link: IGNITE-18733
    Ignite Flags:   (was: Docs Required,Release Notes Required)

> Implement safe-time propagation for meta-storage raft-group
> -----------------------------------------------------------
>
>                 Key: IGNITE-19028
>                 URL: https://issues.apache.org/jira/browse/IGNITE-19028
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Ivan Bessonov
>            Priority: Major
>              Labels: ignite-3
>
> For the future implementation of schema-synchronization, we need to have a hybrid-timestamp, associated with the meta-storage.
> Database schema changes are always associated with time, and proper place to store them would be a meta-storage.
> We don't have an "action request processor" that would have been a single source of truth when it comes to new "write" commands. In case of meta-storage, all nodes may create write commands. Assigning a time from the _hlc_ wouldn't work - there's a chance of having out-of order events, which is really, really bad.
> In other words, timestamps should come in order. Does this mean that meta-storage should also have its own action request processor? That's one possibility.
> Another possibility is to make leader into a timestamp-generator. This would lead to changes in JRaft code, but still, this may be the right way to go. It simply requires less changes to the code. We should just remember to adjust the clock on leader's re-election, so that time would be monotonic.
> By the way, if we go with the second option, it would also fit safe time propagation in partitions.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)