[
https://issues.apache.org/jira/browse/IGNITE-26096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-26096:
---------------------------------------
Description:
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.
Here is the scenario:
# Originally, while on v1, have just 1 node in the cluster, so the replication
factor is 1
# Make sure the log is truncated while still on v1 (so that any node later
will need a Raft snapshot to be installed to it to get the partition data)
# While still on v2, join one more node
# Change replication factor to 2
# Wait for replication via Raft snapshot to start; don't let it finish the
data transfer
# Stop the receiving node
# Start both nodes on v2
# Verify that the new node will still get all the data from the original node
was:
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)
> Verify interrupted Raft snapshot installation compatibility
> -----------------------------------------------------------
>
> Key: IGNITE-26096
> URL: https://issues.apache.org/jira/browse/IGNITE-26096
> Project: Ignite
> Issue Type: Improvement
> Reporter: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
>
> 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.
> Here is the scenario:
> # Originally, while on v1, have just 1 node in the cluster, so the
> replication factor is 1
> # Make sure the log is truncated while still on v1 (so that any node later
> will need a Raft snapshot to be installed to it to get the partition data)
> # While still on v2, join one more node
> # Change replication factor to 2
> # Wait for replication via Raft snapshot to start; don't let it finish the
> data transfer
> # Stop the receiving node
> # Start both nodes on v2
> # Verify that the new node will still get all the data from the original node
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
