Updated 4.x design, features, and quickstart user manual pages - #487
Updated 4.x design, features, and quickstart user manual pages#487dlmarion wants to merge 1 commit into
Conversation
phrocker
left a comment
There was a problem hiding this comment.
Looks good otherwise. take a look at the comments and use your judgement. I wasn't sure about the design.md changes I made a suggestion, but I don't know if that's a good way of putting it.
| In order to manage the number of files per tablet, periodically the TabletServer | ||
| performs Major Compactions of files within a tablet, in which some set of RFiles | ||
| In order to manage the number of files per tablet, periodically the Manager will | ||
| instruct a Compactor to perform a Major Compaction of files within a tablet, in which some set of RFiles |
There was a problem hiding this comment.
This sort of pull , right? "the Manager identifies the compaction work to be done and a Compactor requests and executes it."
|
|
||
| ``` | ||
| accumulo init | ||
| accumulo inst init |
There was a problem hiding this comment.
I'm not seeing it here, but is there an example for the group keyed maps? I looked at the raw ? I have something like this on my deployments:
tserver:
default:
servers_per_host: 2
hosts:
- host1
- host2
| Multiple Coordinators may be run. The Coordinators will choose among themselves a single active Coordinator, | ||
| and the others will become backups if the active Coordinator should fail. | ||
| Compactors also perform recovery of a tablet | ||
| that was previously on a Tablet Server that failed, reapplying any writes |
There was a problem hiding this comment.
Is it worth saying something like this? The paragraphs below and this are identical, so maybe similar wording for both?
"Compactors also perform the sorting phase of write-ahead log recovery for tablets that were on a Tablet Server that failed. Once sorting completes, the tablet is assigned to a Tablet Server, which replays the sorted mutations."
| [sserver]: {% durl configuration/files#sserver %} | ||
| [Uno]: https://github.com/apache/fluo-uno | ||
| [Uno]: https://github.com/apache/accumulo-uno | ||
| [Muchos]: https://github.com/apache/fluo-muchos |
There was a problem hiding this comment.
| [Muchos]: https://github.com/apache/fluo-muchos | |
| [Muchos]: https://github.com/apache/accumulo-muchos |
This repo is deprecated now so not sure if we still want to point to it or not
| Multiple managers can be configured. Zookeeper locks are used to determine | ||
| which manager is active. The remaining managers simply wait for the current | ||
| manager to lose its lock. Current manager state is held in the metadata table | ||
| which manager is the primary manager. The remaining managers simply wait for the current |
There was a problem hiding this comment.
I know we say it elsewhere but to me, "remaining managers simply wait" make it sound like they do nothing else besides wait.
| ### Tracer | ||
| The Compaction Coordinator is a function that the primary Manager performs to coordinate | ||
| the completion of major compactions using Compactor processes. The Coordinator is responsible | ||
| for identifying what external compaction work needs to be done, and the Compactors |
There was a problem hiding this comment.
| for identifying what external compaction work needs to be done, and the Compactors | |
| for identifying what external compaction work needs to be done, and for communicating with the Compactors |
| The Accumulo Compactor process is an application that can be used to run compactions | ||
| outside of the TabletServer. One to many Compactors can be run on a cluster and each Compactor | ||
| process performs one compaction at a time. The Compactor registers its existence in ZooKeeper | ||
| and communicates with the Compaction Coordinator to retrieve its work and to register the |
There was a problem hiding this comment.
Searching for "Compaction Coordinator" and "CompactionCoordinator" yields a few more spots that can be cleaned up
No description provided.