You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Andrew Kyle Purtell (Jira)" <ji...@apache.org> on 2022/06/15 20:57:00 UTC

[jira] [Resolved] (HBASE-7346) Restored snapshot replay problem

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

Andrew Kyle Purtell resolved HBASE-7346.
----------------------------------------
    Resolution: Fixed

> Restored snapshot replay problem
> --------------------------------
>
>                 Key: HBASE-7346
>                 URL: https://issues.apache.org/jira/browse/HBASE-7346
>             Project: HBase
>          Issue Type: Test
>          Components: Client, master, regionserver, snapshots, Zookeeper
>    Affects Versions: hbase-6055
>            Reporter: Jonathan Hsieh
>            Priority: Critical
>             Fix For: hbase-6055
>
>
> The situation is a coarse-grained problem. The key problem is that writes that shouldn't be replayed (since they don't belong to the restored image), would not normally get replayed, but would potentially get replayed if recovery was triggered.
> Previously, without restore, we could depend on the timestamps – if something was replayed but there was newer data, the newer data would win. In a restore situation, the "newer" data is has the old time stamps from before recovery, and new data that shouldn't get replayed could be.
> ex: 
> 1) write 100 rows
> 2) ss1 (with logs)
> 3) write 50 rows
> 4) restore ss1
> 5) crash
> 6) writes from 1 and 3 both get replayed in log splitting recovery. Oops.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)