bookkeeper-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From git-site-r...@apache.org
Subject [bookkeeper] branch asf-site updated: Updated site at revision fd27e99
Date Fri, 01 Sep 2017 00:16:18 GMT
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 <builds@apache.org>
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
['"commits@bookkeeper.apache.org" <commits@bookkeeper.apache.org>'].

Mime
View raw message