[
https://issues.apache.org/jira/browse/IGNITE-26095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18021424#comment-18021424
]
Roman Puchkovskiy commented on IGNITE-26095:
--------------------------------------------
The patch looks good to me
> Add partition Raft log compatibility test
> -----------------------------------------
>
> Key: IGNITE-26095
> URL: https://issues.apache.org/jira/browse/IGNITE-26095
> Project: Ignite
> Issue Type: Improvement
> Reporter: Roman Puchkovskiy
> Assignee: Kirill Tkalenko
> Priority: Blocker
> Labels: ignite-3
> Fix For: 3.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Legend: v1 is original version (3.0), v2 is current version (version from
> main branch).
> It is supposed that data is written in v1, then the storage is flushed and
> the node is stopped, its binary is replaced with v2, the node is started.
> We must test the following scenarios:
> # Reapplication of a log (written in v1) on v2 goes correctly. We could do
> the following:
> ## Make sure the v1 log is complete (no prefix truncation happens)
> ## Delete partition files while the node is offline
> ## Start on v2 and make sure the table data becomes available after node
> recovery
> # Application of a log (written on v1) by a leader on v2 to another node (a
> follower) also on v2 goes correctly: that is, after it finishes, on the
> follower it is possible to read table data. We might need the following to
> test this:
> ## Make sure the v1 log is complete (no prefix truncation happens)
> ## Originally, while on v1, have just 1 node in the cluster, so the
> replication factor is 1
> ## After we start on v2, join two more nodes (on v2)
> ## Change replication factor to 3
> ## Wait for replication to finish
> ## Stop the original node
> ## Now query the table (as its partitions will still have majorities)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
