This is an automated email from the ASF dual-hosted git repository.
jojochuang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/ozone-site.git
The following commit(s) were added to refs/heads/master by this push:
new ad95fd77fe HDDS-15767. Update system internal docs since pull
replication is removed (#489)
ad95fd77fe is described below
commit ad95fd77feaba8ccc3eb8f0415db5e426b9f6b1b
Author: Ethan Rose <[email protected]>
AuthorDate: Wed Jul 15 14:46:16 2026 -0400
HDDS-15767. Update system internal docs since pull replication is removed
(#489)
---
.../02-data/02-containers/08-replication.md | 40 ++++++----------------
1 file changed, 11 insertions(+), 29 deletions(-)
diff --git
a/docs/07-system-internals/04-replication/02-data/02-containers/08-replication.md
b/docs/07-system-internals/04-replication/02-data/02-containers/08-replication.md
index 465400a1a5..3c1ccdbb47 100644
---
a/docs/07-system-internals/04-replication/02-data/02-containers/08-replication.md
+++
b/docs/07-system-internals/04-replication/02-data/02-containers/08-replication.md
@@ -10,20 +10,14 @@ Container replication is a critical mechanism in Apache
Ozone that ensures data
## Replication Mode
-Apache Ozone supports **Push Replication** by **default**, where the source
Datanode actively pushes the container to the target Datanode. The replication
mode is controlled by the configuration property `hdds.scm.replication.push`
(default: `true`). When set to `false`, the system uses pull replication where
the target Datanode pulls from source Datanodes.
+Apache Ozone uses **Push Replication**, where the source Datanode (client)
actively pushes or uploads the container to the target Datanode (server).
-**Push Replication :** `PushReplicator` class handles push replication by:
+**Push Replication:** `PushReplicator` class handles push replication by:
- Using `OnDemandContainerReplicationSource` to prepare the container
- Using `GrpcContainerUploader` to upload the container via gRPC stream
- Streaming the container data directly to the target Datanode
-:::note
-
-Both regular container replication and EC container replication respect the
same `hdds.scm.replication.push` configuration setting. EC container
replication scenarios (decommissioning, under-replication, maintenance mode,
mis-replication) will use push mode when the configuration is `true` (default)
or pull mode when set to `false`.
-
-:::
-
---
## Detailed Replication Process
@@ -48,7 +42,7 @@ The source Datanode streams the tarball to the destination
via gRPC:
- Establishes gRPC stream connection
- Streams data in chunks via `SendContainerRequest` messages
- Destination writes chunks to temporary file in the temp dir of the volume
chosen: `<volume-root>/tmp/container-copy/`.
- That way, Datanode parallelizes container download, and does not block on
the system root drive.
+ That way, Datanode parallelizes container transfer, and does not block on
the system root drive.
Before receiving, the destination selects a volume, **reserves space (2x
container size)** to accommodate both the tarball and the extracted files, and
creates the temporary directory.
@@ -80,7 +74,7 @@ Import progress is tracked to prevent concurrent imports. If
import fails or con
After successful import, all temporary files are cleaned up:
-1. **Delete Tarball**: The downloaded tarball file is deleted from the
temporary directory
+1. **Delete Tarball**: The uploaded tarball file is deleted from the temporary
directory
2. **Release Reserved Space**: The reserved space on the volume is released
3. **Cleanup on Failure**: If any step fails, temporary files are deleted and
reserved space is released
@@ -88,7 +82,7 @@ After successful import, all temporary files are cleaned up:
## Advantages of Push Replication
-Push replication offers several advantages:
+Push replication (where the client uploads the container to the server) offers
several advantages:
- **Better Load Distribution**: Source Datanode controls transfer rate and
timing, managing its own load while simplifying target operations
- **Improved Network Efficiency**: Direct streaming with gRPC flow control
adapts to network conditions, reducing latency
@@ -99,7 +93,7 @@ Push replication offers several advantages:
## EC Container Replication Scenarios
-Erasure Coded (EC) containers have specific replication requirements and
scenarios where replication is necessary.
+Erasure Coded (EC) containers usually have their durability restored using
reconstruction since each replica is unique. However, there are specific
scenarios where replication is necessary.
### Scenario 1: Decommissioning
@@ -112,7 +106,7 @@ When a Datanode enters the decommissioning state, all EC
container replicas stor
2. **Index Identification**: The handler identifies which EC indexes are only
present on decommissioning Datanodes (`decommissioningOnlyIndexes()`)
3. **One-to-One Replication**: For each decommissioning index, a replication
command is created to copy that specific index to a new Datanode
4. **Target Selection**: New target Datanodes are selected based on placement
policies
-5. **Replication Execution**: Each index is replicated independently using the
configured replication mode (push by default, configurable to pull via
`hdds.scm.replication.push`)
+5. **Replication Execution**: Each index is replicated independently by
pushing the replica from the source to the target Datanode
**Example:**
@@ -122,19 +116,7 @@ For an EC container with replication config `RS-6-3-1024k`:
- If index 2 is only on a decommissioning Datanode, only index 2 needs to be
replicated
- The replication command includes `replicaIndex=2` to specify which index to
copy
-### Scenario 2: Under-Replication
-
-**When it occurs:**
-When an EC container has fewer replicas than required for a specific index,
that index needs to be replicated.
-
-**How it works:**
-
-1. **Replica Count Analysis**: `ECContainerReplicaCount` analyzes the current
replica distribution
-2. **Missing Index Detection**: Identifies indexes that have fewer replicas
than required
-3. **Source Selection**: Selects healthy source replicas for the missing
indexes
-4. **Replication Commands**: Creates replication commands to restore
redundancy using the configured replication mode (push by default)
-
-### Scenario 3: Maintenance Mode
+### Scenario 2: Maintenance Mode
**When it occurs:**
When Datanodes enter maintenance mode, EC container replicas on those
Datanodes may need additional copies to maintain redundancy during maintenance.
@@ -144,9 +126,9 @@ When Datanodes enter maintenance mode, EC container
replicas on those Datanodes
Similar to decommissioning, but with different redundancy requirements:
- Maintenance mode allows for reduced redundancy
(`maintenanceRemainingRedundancy` config)
-- Replication ensures minimum redundancy is maintained during maintenance
using the configured replication mode (push by default)
+- Replication ensures minimum redundancy is maintained during maintenance
-### Scenario 4: Mis-Replication
+### Scenario 3: Mis-Replication
**When it occurs:**
When EC container replicas are placed on Datanodes that violate placement
policies (e.g., too many replicas in the same rack).
@@ -155,5 +137,5 @@ When EC container replicas are placed on Datanodes that
violate placement polici
1. **Placement Validation**: `ECMisReplicationHandler` validates replica
placement against policies
2. **Violation Detection**: Identifies replicas that violate placement
constraints
-3. **Replication to Correct Placement**: Creates replication commands to move
replicas to compliant locations using the configured replication mode (push by
default)
+3. **Replication to Correct Placement**: Creates replication commands to move
replicas to compliant locations
4. **Old Replica Deletion**: After successful replication, old replicas are
deleted
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
