This is an automated email from the ASF dual-hosted git repository.
zhaijia pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/bookkeeper.git
The following commit(s) were added to refs/heads/master by this push:
new fd27e99 ISSUE #485: Change 'segment' to 'fragment' in docs
fd27e99 is described below
commit fd27e99ecbb152ef7bbf05a36a9d85c8997d3744
Author: Arvin <[email protected]>
AuthorDate: Fri Sep 1 08:12:57 2017 +0800
ISSUE #485: Change 'segment' to 'fragment' in docs
Descriptions of the changes in this PR:
Change 'segment' to 'fragment' in docs, and make some relative code more
clearer
Author: Arvin <[email protected]>
Reviewers: Jia Zhai <None>, Sijie Guo <[email protected]>
This closes #486 from ArvinDevel/issue_485, closes #485
---
.../apache/bookkeeper/client/LedgerChecker.java | 16 ++++++++--------
.../bookkeeper/client/BookKeeperAdminTest.java | 8 ++++----
site/docs/4.5.0/admin/autorecovery.md | 22 +++++++++++-----------
site/docs/latest/admin/autorecovery.md | 22 +++++++++++-----------
4 files changed, 34 insertions(+), 34 deletions(-)
diff --git
a/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java
b/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java
index c9481bd..a90a366 100644
---
a/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java
+++
b/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java
@@ -200,16 +200,16 @@ public class LedgerChecker {
curEnsemble = e.getValue();
}
- /* Checking the last segment of the ledger can be complicated in some
cases.
+ /* Checking the last fragment of the ledger can be complicated in some
cases.
* In the case that the ledger is closed, we can just check the
fragments of
- * the segment as normal, except in the case that no entry was ever
written,
+ * the ledger as normal, except in the case that no entry was ever
written,
* to the ledger, in which case we check no fragments.
* In the case that the ledger is open, but enough entries have been
written,
- * for lastAddConfirmed to be set above the start entry of the
segment, we
+ * for lastAddConfirmed to be set above the start entry of the
fragment, we
* can also check as normal.
* However, if lastAddConfirmed cannot be trusted, such as when it's
lower than
* the first entry id, or not set at all, we cannot be sure if there
has been
- * data written to the segment. For this reason, we have to send a
read request
+ * data written to the fragment. For this reason, we have to send a
read request
* to the bookies which should have the first entry. If they respond
with
* NoSuchEntry we can assume it was never written. If they respond
with anything
* else, we must assume the entry has been written, so we run the
check.
@@ -221,9 +221,9 @@ public class LedgerChecker {
lastEntry = curEntryId;
}
- final Set<LedgerFragment> finalSegmentFragments = new
HashSet<LedgerFragment>();
+ final Set<LedgerFragment> finalFragments = new
HashSet<LedgerFragment>();
for (int i = 0; i < curEnsemble.size(); i++) {
- finalSegmentFragments.add(new LedgerFragment(lh, curEntryId,
+ finalFragments.add(new LedgerFragment(lh, curEntryId,
lastEntry, i));
}
@@ -237,7 +237,7 @@ public class LedgerChecker {
new GenericCallback<Boolean>() {
public void
operationComplete(int rc, Boolean result) {
if (result) {
-
fragments.addAll(finalSegmentFragments);
+
fragments.addAll(finalFragments);
}
checkFragments(fragments, cb);
}
@@ -250,7 +250,7 @@ public class LedgerChecker {
}
return;
} else {
- fragments.addAll(finalSegmentFragments);
+ fragments.addAll(finalFragments);
}
}
diff --git
a/bookkeeper-server/src/test/java/org/apache/bookkeeper/client/BookKeeperAdminTest.java
b/bookkeeper-server/src/test/java/org/apache/bookkeeper/client/BookKeeperAdminTest.java
index 68956d8..e9cd823 100644
---
a/bookkeeper-server/src/test/java/org/apache/bookkeeper/client/BookKeeperAdminTest.java
+++
b/bookkeeper-server/src/test/java/org/apache/bookkeeper/client/BookKeeperAdminTest.java
@@ -193,7 +193,7 @@ public class BookKeeperAdminTest extends
BookKeeperClusterTestCase {
/*
* since one of the bookie is killed, ensemble change happens when next
- * write is made.So new segment will be created for those 2 ledgers.
+ * write is made.So new fragment will be created for those 2 ledgers.
*/
for (int j = numOfEntries; j < 2 * numOfEntries; j++) {
lh1.addEntry(j, "data".getBytes());
@@ -201,14 +201,14 @@ public class BookKeeperAdminTest extends
BookKeeperClusterTestCase {
}
/*
- * Here lh1 and lh2 have multiple segments and are writeclosed. But
lh3 and lh4 are
- * not writeclosed and contains only one segment.
+ * Here lh1 and lh2 have multiple fragments and are writeclosed. But
lh3 and lh4 are
+ * not writeclosed and contains only one fragment.
*/
lh1.close();
lh2.close();
/*
- * If the last segment of the ledger is underreplicated and if the
+ * If the last fragment of the ledger is underreplicated and if the
* ledger is not closed then it will remain underreplicated for
* openLedgerRereplicationGracePeriod (by default 30 secs). For more
* info. Check BOOKKEEPER-237 and BOOKKEEPER-325. But later
diff --git a/site/docs/4.5.0/admin/autorecovery.md
b/site/docs/4.5.0/admin/autorecovery.md
index 64c6beb..bd11a88 100644
--- a/site/docs/4.5.0/admin/autorecovery.md
+++ b/site/docs/4.5.0/admin/autorecovery.md
@@ -37,7 +37,7 @@ $ bookkeeper-server/bin/bookkeeper
org.apache.bookkeeper.tools.BookKeeperTools \
When you initiate a manual recovery process, the following happens:
1. The client (the process running ) reads the metadata of active ledgers from
ZooKeeper.
-1. The ledgers that contain segments from the failed bookie in their ensemble
are selected.
+1. The ledgers that contain fragments from the failed bookie in their ensemble
are selected.
1. A recovery process is initiated for each ledger in this list and the
rereplication process is run for each ledger.
1. Once all the ledgers are marked as fully replicated, bookie recovery is
finished.
@@ -106,11 +106,11 @@ When the auditor sees that a bookie has disappeared, it
immediately scans the co
Each replication worker watches for tasks being published by the auditor on
the `/underreplicated/` 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.
-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 (du [...]
+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 underreplicated [...]
-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.
+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.
-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 started [...]
+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 starte [...]
You can configure this grace period using the
[`openLedgerRereplicationGracePeriod`](../../reference/config#openLedgerRereplicationGracePeriod)
parameter.
@@ -118,11 +118,11 @@ You can configure this grace period using the
[`openLedgerRereplicationGracePeri
The ledger rereplication process happens in these steps:
-1. The client goes through all ledger segments in the ledger, selecting those
that contain the failed bookie.
-1. A recovery process is initiated for each ledger segment in this list.
- 1. 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.
- 1. The client reads entries that belong to the ledger segment from other
bookies in the ensemble and writes them to the selected bookie.
- 1. Once all entries have been replicated, the zookeeper metadata for the
segment is updated to reflect the new ensemble.
- 1. The segment is marked as fully replicated in the recovery tool.
-1. Once all ledger segments are marked as fully replicated, the ledger is
marked as fully replicated.
+1. The client goes through all ledger fragments in the ledger, selecting those
that contain the failed bookie.
+1. A recovery process is initiated for each ledger fragment in this list.
+ 1. 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.
+ 1. The client reads entries that belong to the ledger fragment from other
bookies in the ensemble and writes them to the selected bookie.
+ 1. Once all entries have been replicated, the zookeeper metadata for the
fragment is updated to reflect the new ensemble.
+ 1. The fragment is marked as fully replicated in the recovery tool.
+1. Once all ledger fragments are marked as fully replicated, the ledger is
marked as fully replicated.
diff --git a/site/docs/latest/admin/autorecovery.md
b/site/docs/latest/admin/autorecovery.md
index d572346..b1dd078 100644
--- a/site/docs/latest/admin/autorecovery.md
+++ b/site/docs/latest/admin/autorecovery.md
@@ -37,7 +37,7 @@ $ bookkeeper-server/bin/bookkeeper shell recover \
When you initiate a manual recovery process, the following happens:
1. The client (the process running ) reads the metadata of active ledgers from
ZooKeeper.
-1. The ledgers that contain segments from the failed bookie in their ensemble
are selected.
+1. The ledgers that contain fragments from the failed bookie in their ensemble
are selected.
1. A recovery process is initiated for each ledger in this list and the
rereplication process is run for each ledger.
1. Once all the ledgers are marked as fully replicated, bookie recovery is
finished.
@@ -106,11 +106,11 @@ When the auditor sees that a bookie has disappeared, it
immediately scans the co
Each replication worker watches for tasks being published by the auditor on
the `/underreplicated/` 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.
-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 (du [...]
+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 underreplicated [...]
-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.
+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.
-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 started [...]
+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 starte [...]
You can configure this grace period using the
[`openLedgerRereplicationGracePeriod`](../../reference/config#openLedgerRereplicationGracePeriod)
parameter.
@@ -118,11 +118,11 @@ You can configure this grace period using the
[`openLedgerRereplicationGracePeri
The ledger rereplication process happens in these steps:
-1. The client goes through all ledger segments in the ledger, selecting those
that contain the failed bookie.
-1. A recovery process is initiated for each ledger segment in this list.
- 1. 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.
- 1. The client reads entries that belong to the ledger segment from other
bookies in the ensemble and writes them to the selected bookie.
- 1. Once all entries have been replicated, the zookeeper metadata for the
segment is updated to reflect the new ensemble.
- 1. The segment is marked as fully replicated in the recovery tool.
-1. Once all ledger segments are marked as fully replicated, the ledger is
marked as fully replicated.
+1. The client goes through all ledger fragments in the ledger, selecting those
that contain the failed bookie.
+1. A recovery process is initiated for each ledger fragment in this list.
+ 1. 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.
+ 1. The client reads entries that belong to the ledger fragment from other
bookies in the ensemble and writes them to the selected bookie.
+ 1. Once all entries have been replicated, the zookeeper metadata for the
fragment is updated to reflect the new ensemble.
+ 1. The fragment is marked as fully replicated in the recovery tool.
+1. Once all ledger fragments are marked as fully replicated, the ledger is
marked as fully replicated.
--
To stop receiving notification emails like this one, please contact
['"[email protected]" <[email protected]>'].
