You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@bookkeeper.apache.org by gi...@apache.org on 2017/09/01 00:16:18 UTC
[bookkeeper] branch asf-site updated: Updated site at revision
fd27e99
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 <bu...@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" <co...@bookkeeper.apache.org>'].