[jira] [Resolved] (HBASE-26791) Memstore flush fencing issue for SFT

["Duo Zhang (Jira)" <ji...@apache.org>]

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

Duo Zhang resolved HBASE-26791.
-------------------------------
    Fix Version/s: 2.6.0
                   3.0.0-alpha-3
     Hadoop Flags: Reviewed
       Resolution: Fixed

Pushed to master and branch-2.
Thanks all for reivewing and helping!

> Memstore flush fencing issue for SFT
> ------------------------------------
>
>                 Key: HBASE-26791
>                 URL: https://issues.apache.org/jira/browse/HBASE-26791
>             Project: HBase
>          Issue Type: Sub-task
>    Affects Versions: 2.6.0, 3.0.0-alpha-3
>            Reporter: Szabolcs Bukros
>            Assignee: Duo Zhang
>            Priority: Major
>             Fix For: 2.6.0, 3.0.0-alpha-3
>
>
> The scenarios is the following:
>  # rs1 is flushing file to S3 for region1
>  # rs1 loses ZK lock
>  # region1 gets assigned to rs2
>  # rs2 opens region1
>  # rs1 completes flush and updates sft file for region1
>  # rs2 has a different “version” of the sft file for region1
> The flush should fail at the end, but the SFT file gets overwritten before that, resulting in potential data loss.
>  
> Potential solutions include:
>  * Adding timestamp to the tracker file names. This and creating a new tracker file when an rs open the region would allow us to list available tracker files before an update and compare the found timestamps to the one stored in memory to verify the store still owns the latest tracker file
>  * Using the existing timestamp in the tracker file content. This would also require us to create a new tracker file when a new rs opens the region, but instead of listing the available tracker files, we could try to load and de-serialize the last tracker file and compare the timestamp found in it to the one stored in memory.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)