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

Siyao Meng reassigned HDDS-17101:
---------------------------------

    Component/s: SCM
       Assignee: Siyao Meng
    Description: 
When a QUASI_CLOSED Ratis container is force closed, its sequence ID is the 
highest one reported by any replica. After that, ReplicationManager counts 
every QUASI_CLOSED replica with a different sequence ID as unhealthy and 
deletes it once the container has enough CLOSED replicas. So which replicas 
survive depends on the report of a single replica. Origin IDs cannot tell the 
replicas apart either, because a copy made by replication reports the origin of 
the replica it was copied from. Separately, the container report handler still 
raises the sequence ID of a CLOSED container when a replica reports a higher 
one (it only logs an error).

This change:
* Keeps a QUASI_CLOSED replica of a CLOSED container while it is on its origin 
datanode, whatever its sequence ID. ReplicationManager does not select it for 
deletion and leaves it out of the replica counts, the placement check and the 
health state, so it does not cause healthy replicas to be removed or added and 
the container stays HEALTHY. Its datanode is excluded as a target for new 
replicas. An empty kept replica does not stop an empty container from being 
deleted. Copies on other datanodes are handled as before.
* Stops the container report handler from raising the sequence ID of a CLOSED 
container.

*Compatibility*
* No protocol, layout or configuration change.
* After a force close, replicas that lag behind stay on their origin datanodes 
instead of being deleted, so such a container can keep up to two extra replicas 
until it is deleted.

  was:Keep QUASI_CLOSED replicas of a CLOSED container on their origin datanode.


> Keep QUASI_CLOSED replicas of a CLOSED container on their origin datanode
> -------------------------------------------------------------------------
>
>                 Key: HDDS-17101
>                 URL: https://issues.apache.org/jira/browse/HDDS-17101
>             Project: Apache Ozone
>          Issue Type: Improvement
>          Components: SCM
>            Reporter: Siyao Meng
>            Assignee: Siyao Meng
>            Priority: Major
>
> When a QUASI_CLOSED Ratis container is force closed, its sequence ID is the 
> highest one reported by any replica. After that, ReplicationManager counts 
> every QUASI_CLOSED replica with a different sequence ID as unhealthy and 
> deletes it once the container has enough CLOSED replicas. So which replicas 
> survive depends on the report of a single replica. Origin IDs cannot tell the 
> replicas apart either, because a copy made by replication reports the origin 
> of the replica it was copied from. Separately, the container report handler 
> still raises the sequence ID of a CLOSED container when a replica reports a 
> higher one (it only logs an error).
> This change:
> * Keeps a QUASI_CLOSED replica of a CLOSED container while it is on its 
> origin datanode, whatever its sequence ID. ReplicationManager does not select 
> it for deletion and leaves it out of the replica counts, the placement check 
> and the health state, so it does not cause healthy replicas to be removed or 
> added and the container stays HEALTHY. Its datanode is excluded as a target 
> for new replicas. An empty kept replica does not stop an empty container from 
> being deleted. Copies on other datanodes are handled as before.
> * Stops the container report handler from raising the sequence ID of a CLOSED 
> container.
> *Compatibility*
> * No protocol, layout or configuration change.
> * After a force close, replicas that lag behind stay on their origin 
> datanodes instead of being deleted, so such a container can keep up to two 
> extra replicas until it is deleted.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to