You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Duo Zhang (Jira)" <ji...@apache.org> on 2023/07/13 13:35:00 UTC

[jira] [Resolved] (HBASE-27231) FSHLog should retry writing WAL entries when syncs to HDFS failed.

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

Duo Zhang resolved HBASE-27231.
-------------------------------
    Fix Version/s: 3.0.0-beta-1
     Hadoop Flags: Reviewed
       Resolution: Fixed

Pushed to master and branch-3.

Thanks [~comnetwork]!

> FSHLog should retry writing WAL entries when syncs to HDFS failed.
> ------------------------------------------------------------------
>
>                 Key: HBASE-27231
>                 URL: https://issues.apache.org/jira/browse/HBASE-27231
>             Project: HBase
>          Issue Type: Improvement
>          Components: wal
>    Affects Versions: 3.0.0-alpha-4
>            Reporter: chenglei
>            Assignee: chenglei
>            Priority: Major
>             Fix For: 3.0.0-beta-1
>
>
> Just as HBASE-27223 said, basically, if the {{WAL}} write to HDFS fails, we do not know whether the data has been persistent or not. The implementation for {{AsyncFSWAL}}, is to open a new writer and try to write the WAL entries again, and then adding logic in WAL split and replay to deal with duplicate entries. But for {{FSHLog}}, it does not have the same logic with {{AsyncFSWAL}}, when {{ProtobufLogWriter.append}} and {{ProtobufLogWriter.sync}} failed, {{FSHLog.sync}} immediately throws the exception thrown by {{ProtobufLogWriter.append}} and {{ProtobufLogWriter.sync}} , we should implement the same retry logic as {{AsyncFSWAL}}, so {{WAL.sync}} could only throw  {{TimeoutIOException}} and we could uniformly abort the RegionServer when  {{WAL.sync}} failed.
> The basic idea is because both {{FSHLog.RingBufferEventHandler}} and {{AsyncFSWAL.consumeExecutor}} are single-thread,  we could reuse the logic in {{AsyncWAL}} and move the most code in {{AsyncWAL}} upward to {{AbstractFSWAL}} , and just adapting the {{SyncRunner}} in {{FSHLog}} to the logic in {{AsyncWriter.sync}}. Once we do that, most logic in {{AsyncWAL}} and {{FSHLog}} are unified, just how to sync the {{writer}} is different.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)