You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Roman Puchkovskiy (Jira)" <ji...@apache.org> on 2022/10/13 14:49:00 UTC
[jira] [Commented] (IGNITE-17254) Storage API for RAFT snapshot streaming
[ https://issues.apache.org/jira/browse/IGNITE-17254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17617111#comment-17617111 ]
Roman Puchkovskiy commented on IGNITE-17254:
--------------------------------------------
Thank you!
> Storage API for RAFT snapshot streaming
> ---------------------------------------
>
> Key: IGNITE-17254
> URL: https://issues.apache.org/jira/browse/IGNITE-17254
> Project: Ignite
> Issue Type: Improvement
> Reporter: Roman Puchkovskiy
> Assignee: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Current PartitionStorage has a method for taking snapshots (and a method for restoring from them). TheĀ methods work with files. In IGNITE-17253, we are going to switch to streaming protocol (which does not use files at all). So we need streaming snapshot-related methods on MvPartitionStorage.
> h3. UPDATE
> From my understanding, we basically need two more methods in the MV partition storage to manipulate data:
> {code:java}
> // This one represents a combination of "addWrite" and "commitWrite", but a faster one.
> // It will be used in incoming snapshot copier to write data.
> void addWriteCommitted(RowId rowId, BinaryRow row, HybridTimestamp commitTimestamp);
> // This one will be used to get all versions of a particular row and form a SnapshotMvDataResponse message.
> Cursor<ReadResult> scanVersionsEx(RowId rowId);{code}
> Both of them are very simple and, for the most part, match their counterparts in every storage.
> What's not as simple is the fail-over scenario. We shouldn't treat partially-downloaded partition as a valid set of data. So, the easiest was (in My opinion) to achieve this is to:
> * set "lastAppliedIndex" value to "-1" before writing any the data
> * drop old data (these two steps may be swapped, it's not that important)
> * download and write everything
> * set valid value for "lastAppliedIndex"
> This is a crude solution, but should work well, especially if properly documented.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)