This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/bookkeeper.git
The following commit(s) were added to refs/heads/asf-site by this push:
new b9ff565 Updated site at revision fd27e99
b9ff565 is described below
commit b9ff565cbbb2cc362a14524df0230d7ab36d3a17
Author: jenkins <[email protected]>
AuthorDate: Fri Sep 1 00:16:16 2017 +0000
Updated site at revision fd27e99
---
content/docs/4.5.0/admin/autorecovery/index.html | 22 +++++++++++-----------
content/docs/latest/admin/autorecovery/index.html | 22 +++++++++++-----------
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/content/docs/4.5.0/admin/autorecovery/index.html
b/content/docs/4.5.0/admin/autorecovery/index.html
index 5c4b5e7..ef667c6 100644
--- a/content/docs/4.5.0/admin/autorecovery/index.html
+++ b/content/docs/4.5.0/admin/autorecovery/index.html
@@ -479,7 +479,7 @@
<ol>
<li>The client (the process running ) reads the metadata of active ledgers
from ZooKeeper.</li>
- <li>The ledgers that contain segments from the failed bookie in their
ensemble are selected.</li>
+ <li>The ledgers that contain fragments from the failed bookie in their
ensemble are selected.</li>
<li>A recovery process is initiated for each ledger in this list and the
rereplication process is run for each ledger.</li>
<li>Once all the ledgers are marked as fully replicated, bookie recovery is
finished.</li>
</ol>
@@ -557,11 +557,11 @@
<p>Each replication worker watches for tasks being published by the auditor on
the <code class="highlighter-rouge">/underreplicated/</code> znode in
ZooKeeper. When a new task appears, the replication worker will try to get a
lock on it. If it cannot acquire the lock, it will try the next entry. The
locks are implemented using ZooKeeper ephemeral znodes.</p>
-<p>The replication worker will scan through the rereplication task’s ledger
for segments of which its local bookie is not a member. When it finds segments
matching this criterion, it will replicate the entries of that segment to the
local bookie. If, after this process, the ledger is fully replicated, the
ledgers entry under /underreplicated/ is deleted, and the lock is released. If
there is a problem replicating, or there are still segments in the ledger which
are still underreplicated [...]
+<p>The replication worker will scan through the rereplication task’s ledger
for fragments of which its local bookie is not a member. When it finds
fragments matching this criterion, it will replicate the entries of that
fragment to the local bookie. If, after this process, the ledger is fully
replicated, the ledgers entry under /underreplicated/ is deleted, and the lock
is released. If there is a problem replicating, or there are still fragments in
the ledger which are still underreplica [...]
-<p>If the replication worker finds a segment which needs rereplication, but
does not have a defined endpoint (i.e. the final segment of a ledger currently
being written to), it will wait for a grace period before attempting
rereplication. If the segment needing rereplication still does not have a
defined endpoint, the ledger is fenced and rereplication then takes place.</p>
+<p>If the replication worker finds a fragment which needs rereplication, but
does not have a defined endpoint (i.e. the final fragment of a ledger currently
being written to), it will wait for a grace period before attempting
rereplication. If the fragment needing rereplication still does not have a
defined endpoint, the ledger is fenced and rereplication then takes place.</p>
-<p>This avoids the situation in which a client is writing to a ledger and one
of the bookies goes down, but the client has not written an entry to that
bookie before rereplication takes place. The client could continue writing to
the old segment, even though the ensemble for the segment had changed. This
could lead to data loss. Fencing prevents this scenario from happening. In the
normal case, the client will try to write to the failed bookie within the grace
period, and will have start [...]
+<p>This avoids the situation in which a client is writing to a ledger and one
of the bookies goes down, but the client has not written an entry to that
bookie before rereplication takes place. The client could continue writing to
the old fragment, even though the ensemble for the fragment had changed. This
could lead to data loss. Fencing prevents this scenario from happening. In the
normal case, the client will try to write to the failed bookie within the grace
period, and will have sta [...]
<p>You can configure this grace period using the <a
href="../../reference/config#openLedgerRereplicationGracePeriod"><code
class="highlighter-rouge">openLedgerRereplicationGracePeriod</code></a>
parameter.</p>
@@ -570,16 +570,16 @@
<p>The ledger rereplication process happens in these steps:</p>
<ol>
- <li>The client goes through all ledger segments in the ledger, selecting
those that contain the failed bookie.</li>
- <li>A recovery process is initiated for each ledger segment in this list.
+ <li>The client goes through all ledger fragments in the ledger, selecting
those that contain the failed bookie.</li>
+ <li>A recovery process is initiated for each ledger fragment in this list.
<ol>
- <li>The client selects a bookie to which all entries in the ledger
segment will be replicated; In the case of autorecovery, this will always be
the local bookie.</li>
- <li>The client reads entries that belong to the ledger segment from
other bookies in the ensemble and writes them to the selected bookie.</li>
- <li>Once all entries have been replicated, the zookeeper metadata for
the segment is updated to reflect the new ensemble.</li>
- <li>The segment is marked as fully replicated in the recovery tool.</li>
+ <li>The client selects a bookie to which all entries in the ledger
fragment will be replicated; In the case of autorecovery, this will always be
the local bookie.</li>
+ <li>The client reads entries that belong to the ledger fragment from
other bookies in the ensemble and writes them to the selected bookie.</li>
+ <li>Once all entries have been replicated, the zookeeper metadata for
the fragment is updated to reflect the new ensemble.</li>
+ <li>The fragment is marked as fully replicated in the recovery tool.</li>
</ol>
</li>
- <li>Once all ledger segments are marked as fully replicated, the ledger is
marked as fully replicated.</li>
+ <li>Once all ledger fragments are marked as fully replicated, the ledger is
marked as fully replicated.</li>
</ol>
diff --git a/content/docs/latest/admin/autorecovery/index.html
b/content/docs/latest/admin/autorecovery/index.html
index 324fffb..bd23171 100644
--- a/content/docs/latest/admin/autorecovery/index.html
+++ b/content/docs/latest/admin/autorecovery/index.html
@@ -479,7 +479,7 @@
<ol>
<li>The client (the process running ) reads the metadata of active ledgers
from ZooKeeper.</li>
- <li>The ledgers that contain segments from the failed bookie in their
ensemble are selected.</li>
+ <li>The ledgers that contain fragments from the failed bookie in their
ensemble are selected.</li>
<li>A recovery process is initiated for each ledger in this list and the
rereplication process is run for each ledger.</li>
<li>Once all the ledgers are marked as fully replicated, bookie recovery is
finished.</li>
</ol>
@@ -557,11 +557,11 @@
<p>Each replication worker watches for tasks being published by the auditor on
the <code class="highlighter-rouge">/underreplicated/</code> znode in
ZooKeeper. When a new task appears, the replication worker will try to get a
lock on it. If it cannot acquire the lock, it will try the next entry. The
locks are implemented using ZooKeeper ephemeral znodes.</p>
-<p>The replication worker will scan through the rereplication task’s ledger
for segments of which its local bookie is not a member. When it finds segments
matching this criterion, it will replicate the entries of that segment to the
local bookie. If, after this process, the ledger is fully replicated, the
ledgers entry under /underreplicated/ is deleted, and the lock is released. If
there is a problem replicating, or there are still segments in the ledger which
are still underreplicated [...]
+<p>The replication worker will scan through the rereplication task’s ledger
for fragments of which its local bookie is not a member. When it finds
fragments matching this criterion, it will replicate the entries of that
fragment to the local bookie. If, after this process, the ledger is fully
replicated, the ledgers entry under /underreplicated/ is deleted, and the lock
is released. If there is a problem replicating, or there are still fragments in
the ledger which are still underreplica [...]
-<p>If the replication worker finds a segment which needs rereplication, but
does not have a defined endpoint (i.e. the final segment of a ledger currently
being written to), it will wait for a grace period before attempting
rereplication. If the segment needing rereplication still does not have a
defined endpoint, the ledger is fenced and rereplication then takes place.</p>
+<p>If the replication worker finds a fragment which needs rereplication, but
does not have a defined endpoint (i.e. the final fragment of a ledger currently
being written to), it will wait for a grace period before attempting
rereplication. If the fragment needing rereplication still does not have a
defined endpoint, the ledger is fenced and rereplication then takes place.</p>
-<p>This avoids the situation in which a client is writing to a ledger and one
of the bookies goes down, but the client has not written an entry to that
bookie before rereplication takes place. The client could continue writing to
the old segment, even though the ensemble for the segment had changed. This
could lead to data loss. Fencing prevents this scenario from happening. In the
normal case, the client will try to write to the failed bookie within the grace
period, and will have start [...]
+<p>This avoids the situation in which a client is writing to a ledger and one
of the bookies goes down, but the client has not written an entry to that
bookie before rereplication takes place. The client could continue writing to
the old fragment, even though the ensemble for the fragment had changed. This
could lead to data loss. Fencing prevents this scenario from happening. In the
normal case, the client will try to write to the failed bookie within the grace
period, and will have sta [...]
<p>You can configure this grace period using the <a
href="../../reference/config#openLedgerRereplicationGracePeriod"><code
class="highlighter-rouge">openLedgerRereplicationGracePeriod</code></a>
parameter.</p>
@@ -570,16 +570,16 @@
<p>The ledger rereplication process happens in these steps:</p>
<ol>
- <li>The client goes through all ledger segments in the ledger, selecting
those that contain the failed bookie.</li>
- <li>A recovery process is initiated for each ledger segment in this list.
+ <li>The client goes through all ledger fragments in the ledger, selecting
those that contain the failed bookie.</li>
+ <li>A recovery process is initiated for each ledger fragment in this list.
<ol>
- <li>The client selects a bookie to which all entries in the ledger
segment will be replicated; In the case of autorecovery, this will always be
the local bookie.</li>
- <li>The client reads entries that belong to the ledger segment from
other bookies in the ensemble and writes them to the selected bookie.</li>
- <li>Once all entries have been replicated, the zookeeper metadata for
the segment is updated to reflect the new ensemble.</li>
- <li>The segment is marked as fully replicated in the recovery tool.</li>
+ <li>The client selects a bookie to which all entries in the ledger
fragment will be replicated; In the case of autorecovery, this will always be
the local bookie.</li>
+ <li>The client reads entries that belong to the ledger fragment from
other bookies in the ensemble and writes them to the selected bookie.</li>
+ <li>Once all entries have been replicated, the zookeeper metadata for
the fragment is updated to reflect the new ensemble.</li>
+ <li>The fragment is marked as fully replicated in the recovery tool.</li>
</ol>
</li>
- <li>Once all ledger segments are marked as fully replicated, the ledger is
marked as fully replicated.</li>
+ <li>Once all ledger fragments are marked as fully replicated, the ledger is
marked as fully replicated.</li>
</ol>
--
To stop receiving notification emails like this one, please contact
['"[email protected]" <[email protected]>'].
