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

["Kirill Tkalenko (Jira)" <ji...@apache.org>]

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

Kirill Tkalenko updated IGNITE-19028:
-------------------------------------
    Reviewer: Kirill Tkalenko

> 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
>            Assignee: Semyon Danilov
>            Priority: Major
>              Labels: ignite-3
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> 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 "partition replica listener" 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 replica listener? 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)