This is an automated email from the ASF dual-hosted git repository.
asf-gitbox-commits pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/accumulo-website.git
The following commit(s) were added to refs/heads/asf-site by this push:
new f27e073fa Automatic Site Publish by Buildbot
f27e073fa is described below
commit f27e073fa4f79531bda01dcf4a5650078656f852
Author: buildbot <[email protected]>
AuthorDate: Tue Sep 22 11:33:58 2026 +0000
Automatic Site Publish by Buildbot
---
output/docs/4.x/getting-started/design.html | 86 ++++++++++++------------
output/docs/4.x/getting-started/features.html | 28 +++++---
output/docs/4.x/getting-started/quickstart.html | 18 ++---
output/feed.xml | 4 +-
output/images/accumulo-monitor-1.png | Bin 215277 -> 92089 bytes
5 files changed, 69 insertions(+), 67 deletions(-)
diff --git a/output/docs/4.x/getting-started/design.html
b/output/docs/4.x/getting-started/design.html
index fbfb64bbd..606f001c0 100644
--- a/output/docs/4.x/getting-started/design.html
+++ b/output/docs/4.x/getting-started/design.html
@@ -437,8 +437,7 @@ machines.</p>
<h2 id="components">Components</h2>
-<p>An instance of Accumulo includes many TabletServers, one Garbage Collector
process,
-one Manager server and many Clients.</p>
+<p>An instance of Accumulo includes one or more Managers, TabletServers,
Compactors, and GarbageCollectors and many clients.</p>
<h3 id="tablet-server">Tablet Server</h3>
@@ -450,7 +449,7 @@ values from all the files it has created and the sorted
in-memory
store.</p>
<p>TabletServers also perform recovery of a tablet
-that was previously on a server that failed, reapplying any writes
+that was previously on a Tablet Server that failed, reapplying any writes
found in the write-ahead log to the tablet.</p>
<h3 id="garbage-collector">Garbage Collector</h3>
@@ -462,22 +461,23 @@ They will perform leader election among themselves to
choose a single active ins
<h3 id="manager">Manager</h3>
-<p>The Accumulo Manager is responsible for detecting and responding to
TabletServer
-failure. It tries to balance the load across TabletServer by assigning tablets
carefully
+<p>The Accumulo Manager is responsible for managing Tablet, FaTE transaction,
and external
+compaction state across the cluster. It assigns and balances the Tablets
across TabletServers
and instructing TabletServers to unload tablets when necessary. The Manager
ensures all
tablets are assigned to one TabletServer each, and handles table creation,
alteration,
and deletion requests from clients. The Manager also coordinates startup,
graceful
shutdown and recovery of changes in write-ahead logs when Tablet servers
fail.</p>
-<p>Multiple managers may be run. The managers will choose among themselves a
single manager,
-and the others will become backups if the manager should fail.</p>
-
-<h3 id="tracer">Tracer</h3>
+<p>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 for
communicating with the Compactors
+to assign work, get status updates, and cancel running external
compactions.</p>
-<p>The Accumulo Tracer process supports the distributed timing API provided by
Accumulo.
-One to many of these processes can be run on a cluster which will write the
timing
-information to a given Accumulo table for future reference. See the
-<a href="/docs/4.x/troubleshooting/tracing">tracing documentation</a> for more
information.</p>
+<p>Multiple managers may be run concurrently. The managers will choose among
themselves a single manager
+to act as the primary manager and the other managers will act as assistant
managers. Clients will
+connect only to the primary manager. The assistant managers participate in the
execution and
+management of FaTE transactions. The primary manager also participates in the
execution and management
+of FaTE transactions, and also performs tablet management and compaction
coordinator functions.</p>
<h3 id="monitor">Monitor</h3>
@@ -493,27 +493,20 @@ for more information.</p>
forwarding of logs from remote hosts to the Monitor, only one Monitor process
should be active
at one time. Leader election will be performed internally to choose the active
Monitor.</p>
-<h3 id="compactor-experimental">Compactor (experimental)</h3>
+<h3 id="compactor">Compactor</h3>
-<p>The Accumulo Compactor process is an optional application that can be used
to run compactions
+<p>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
-completion status of the compaction. The Compactor process will continue to
perform compactions
-in situations where normal in-TabletServer compactions would fail, such as
TabletServer restart
-and Tablet re-hosting.</p>
+and communicates with the Compaction Coordinator in the primary Manager to
retrieve its work and to register the
+completion status of the compaction.</p>
-<h3 id="compaction-coordinator-experimental">Compaction Coordinator
(experimental)</h3>
-
-<p>The Accumulo Compaction Coordinator is an optional application that is
required to run compactions
-outside of the TabletServer. The Coordinator is responsible for communicating
with the
-TabletServers, to identify what external compaction work needs to be done, and
the Compactors
-to assign work, get status updates, and cancel running external
compactions.</p>
+<p>Compactors also perform the sorting phase of the 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. The Compactor looks for write-ahead log
sorting work before
+requesting the next Major Compaction job.</p>
-<p>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.</p>
-
-<h3 id="scan-server-experimental">Scan Server (experimental)</h3>
+<h3 id="scan-server">Scan Server</h3>
<p>The Accumulo Scan Server is an optional application that can be used to run
scans on a tablet’s data
outside of the Tablet Server. Many Scan Servers can be run on a cluster and
each Scan Server may run
@@ -525,6 +518,11 @@ Tablet Server. The Scan Server does not have any of the
Tablet data that may res
in-memory maps and the tablet may reference files that have been compacted as
tablet metadata can
be cached within the Scan Server (See Scan Server configuration
properties).</p>
+<p>Scan Servers can also perform the sorting phase of the 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. The server property <code
class="language-plaintext
highlighter-rouge">sserver.wal.sort.concurrent.max</code> controls
+the number of threads in the Scan Server that will perform the write-ahead log
sorting.</p>
+
<h3 id="client">Client</h3>
<p>Accumulo has a client library that can be used to write applications that
write and read
@@ -534,11 +532,11 @@ data to/from Accumulo. See the <a
href="/docs/4.x/getting-started/clients">Accum
<p>Accumulo stores data in tables, which are partitioned into tablets. Tablets
are
partitioned on row boundaries so that all of the columns and values for a
particular
-row are found together within the same tablet. The Manager assigns Tablets to
one
-TabletServer at a time. This enables row-level transactions to take place
without
+row are found together within the same tablet. When required, the Manager
assigns a Tablet to one
+TabletServer. This enables row-level transactions to take place without
using distributed locking or some other complicated synchronization mechanism.
As
clients insert and query data, and as machines are added and removed from the
-cluster, the Manager migrates tablets to ensure they remain available and that
the
+cluster, the Manager may migrate tablets to ensure they remain available and
that the
ingest and query load is balanced across the cluster.</p>
<p><img src="/images/docs/data_distribution.png" alt="data distribution" /></p>
@@ -576,18 +574,19 @@ locality group. The diagram below shows the logical view
and HDFS file view of a
<h2 id="compactions">Compactions</h2>
-<p>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
-are combined into one file. The previous files will eventually be removed by
the
-Garbage Collector. This also provides an opportunity to permanently remove
-deleted key-value pairs by omitting key-value pairs suppressed by a delete
entry
-when the new file is created. See the <a
href="/docs/4.x/getting-started/table_configuration#compaction">compaction
documentation</a>
-for more information.</p>
+<p>In order to manage the number of files per tablet the Manager will
periodically
+identify the tablets that need a Major Compaction and will give the highest
+priority job to a Compactor process when it requests the next job. The Major
+Compaction will merge data from an input set of RFiles into a single output
file.
+The previous files will eventually be removed by the Garbage Collector.
+This also provides an opportunity to permanently remove deleted key-value pairs
+by omitting key-value pairs suppressed by a delete entry when the new file is
+created. See the <a
href="/docs/4.x/getting-started/table_configuration#compaction">compaction
documentation</a> for more information.</p>
<h2 id="splitting">Splitting</h2>
-<p>When a table is created it has one tablet. As the table grows its initial
-tablet eventually splits into two tablets. It’s likely that one of these
+<p>When a table is created without split points it will have one tablet. As
the table grows its initial
+tablet eventually splits into two tablets. If hosted, it’s likely that one of
these
tablets will migrate to another tablet server. As the table continues to grow,
its tablets will continue to split and be migrated. The decision to
automatically split a tablet is based on the size of a tablets files. The
@@ -599,7 +598,8 @@ splitting.</p>
<p>As data is deleted from a table, tablets may shrink. Over time this can lead
to small or empty tablets. To deal with this, the <a
href="/docs/4.x/getting-started/table_configuration#merging-tablets">merging of
tablets</a>
-was introduced in Accumulo 1.4.</p>
+was introduced in Accumulo 1.4. Accumulo 4.0 introduces <a
href="/docs/4.x/administration/merging">automatic merging</a>
+of tablets to optionally automate merging of tablets based on configurable
thresholds.</p>
<h2 id="fault-tolerance">Fault-Tolerance</h2>
@@ -614,7 +614,7 @@ grouped by tablet. TabletServers can quickly apply the
mutations from the sorte
that are destined for the tablets they have now been assigned.</p>
<p>TabletServer failures are noted on the Manager’s monitor page, accessible
via
-<code class="language-plaintext
highlighter-rouge">http://manager-address:9995/monitor</code>.</p>
+<code class="language-plaintext
highlighter-rouge">http://monitor-address:9995</code>.</p>
<p><img src="/images/docs/failure_handling.png" alt="failure handling" /></p>
diff --git a/output/docs/4.x/getting-started/features.html
b/output/docs/4.x/getting-started/features.html
index 30c11c6ed..feb400fbc 100644
--- a/output/docs/4.x/getting-started/features.html
+++ b/output/docs/4.x/getting-started/features.html
@@ -474,9 +474,9 @@ can share a pool of datanodes.</p>
<h3 id="manager-fail-over">Manager fail over</h3>
<p>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
-and Zookeeper.</p>
+which manager is the primary manager. The remaining managers will attempt to
+take on the primary manager role if the current primary manager loses its lock.
+Current manager state is held in the metadata table and Zookeeper.</p>
<h3 id="logical-time">Logical time</h3>
@@ -715,14 +715,18 @@ See the <a
href="https://www.javadoc.io/static/org.apache.accumulo/accumulo-core
TinyLfuBlockCacheManager) that construct on-heap block caches. Users can
provide
alternate BlockCacheManager implementations using the property <code
class="language-plaintext
highlighter-rouge">tserver.cache.manager.class</code>.</p>
+<h3 id="on-demand-tablet-unloader">On-Demand Tablet Unloader</h3>
+
+<p>Tablets that have their availability set to on-demand can be unhosted.
Accumulo has a default
+implementation that unloads idle tablets after a configurable amount of
time.</p>
+
<h2 id="general-administration">General Administration</h2>
<h3 id="monitor-page">Monitor page</h3>
<p>The <a href="/docs/4.x/administration/monitoring-metrics">Accumulo
Monitor</a> provides basic information about the system health and
-performance. It displays table sizes, ingest and query statistics, server
-load, and last-update information. It also allows the user to view recent
-diagnostic logs and traces.</p>
+performance. It displays information about the server processes, table sizes,
ingest,
+query and compaction statistics, FaTE and recovery information, and
last-update information.</p>
<p><a class="p-3 border rounded d-block" href="/images/accumulo-monitor-1.png">
<img src="/images/accumulo-monitor-1.png" class="img-fluid rounded"
alt="monitor overview" />
@@ -796,9 +800,8 @@ used to accommodate new data patterns in an existing
table.</p>
<h3 id="tablet-merging">Tablet Merging</h3>
-<p>Tablet merging is a new feature. Merging of tablets can be requested in the
-shell; Accumulo does not merge tablets automatically. If desired, the METADATA
-tablets can be merged.</p>
+<p>Merging of tablets can be requested in the shell or tables can be
configured to
+merge tablets automatically.</p>
<h3 id="table-cloning">Table Cloning</h3>
@@ -823,6 +826,13 @@ imported.</p>
that fall completely within a range are simply dropped. Tablets overlapping the
beginning and end of the range are split, compacted, and then merged.</p>
+<h3 id="tablet-hosting">Tablet Hosting</h3>
+
+<p>User table tablets are hosted optionally be default. Users can configure
tablets
+for their tables to always or never be hosted. Optionally hosted tablets will
be
+assigned to a Tablet Server if needed to support a user operation and then
unhosted
+after a configurable period of time of inactivity.</p>
+
<div class="row mt-4">
<div class="col-md-12 d-flex justify-content-between">
diff --git a/output/docs/4.x/getting-started/quickstart.html
b/output/docs/4.x/getting-started/quickstart.html
index 8cc9f776a..4c53516eb 100644
--- a/output/docs/4.x/getting-started/quickstart.html
+++ b/output/docs/4.x/getting-started/quickstart.html
@@ -423,13 +423,7 @@ process name referenced in this documentation.</p>
<h2 id="setup-for-testing-or-development">Setup for testing or development</h2>
<p>If you are setting up Accumulo for <strong>testing or development,</strong>
consider using
-the following tools:</p>
-
-<ul>
- <li><a href="https://github.com/apache/fluo-uno";>Uno</a> sets up Accumulo on
a single machine for development</li>
- <li><a href="https://github.com/apache/fluo-muchos";>Muchos</a> sets up
Accumulo on a cluster (optionally launched in Amazon EC2 and
-Microsoft Azure VM)</li>
-</ul>
+<a href="https://github.com/apache/accumulo-uno";>Uno</a> to set up a single
instance Accumulo cluster.</p>
<p>If you are setting up Accumulo for a <strong>production</strong>
environment, follow the
instructions below.</p>
@@ -579,7 +573,7 @@ instance.</p>
<p>The following command will perform the initialization.</p>
-<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre
class="highlight"><code>accumulo init
+<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre
class="highlight"><code>accumulo inst init
</code></pre></div></div>
<p>The initialization command will prompt for the following information.</p>
@@ -624,7 +618,7 @@ production.</p>
command followed by the service name. For example, to start only the tserver,
run:</p>
-<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre
class="highlight"><code>accumulo tserver
+<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre
class="highlight"><code>accumulo proc tserver
</code></pre></div></div>
<p>The process will run in the foreground. Use ctrl-c to quit.</p>
@@ -673,11 +667,9 @@ few for fault tolerance.</li>
<li><a href="/docs/4.x/configuration/files#monitor">monitor</a> : Node where
Accumulo monitoring web server is run.</li>
<li><a href="/docs/4.x/configuration/files#tservers">tserver</a> : Accumulo
worker processes. List all of the nodes where tablet
servers should run.</li>
- <li><a href="/docs/4.x/configuration/files#sserver">sserver</a> : Optional.
List of all nodes where scan servers should run.</li>
- <li><a
href="/docs/4.x/configuration/files#compaction%20coordinator">compaction.coordinator</a>
: Optional. Must specify one node. Can specify a few
-for fault tolerance.</li>
- <li><a
href="/docs/4.x/configuration/files#compaction%20compactor">compaction.compactor</a>
: Optional. Accumulo external compactor processes. List of
+ <li><a
href="/docs/4.x/configuration/files#compaction%20compactor">compactor</a> :
Accumulo external compactor processes. List of
all nodes where compactors should run.</li>
+ <li><a href="/docs/4.x/configuration/files#sserver">sserver</a> : Optional.
List of all nodes where scan servers should run.</li>
</ul>
<p>The Accumulo, Hadoop, and Zookeeper software should be present at the same
diff --git a/output/feed.xml b/output/feed.xml
index b02371cc3..315d9b46f 100644
--- a/output/feed.xml
+++ b/output/feed.xml
@@ -6,8 +6,8 @@
</description>
<link>https://accumulo.apache.org/</link>
<atom:link href="https://accumulo.apache.org/feed.xml"; rel="self"
type="application/rss+xml"/>
- <pubDate>Fri, 18 Sep 2026 18:42:02 +0000</pubDate>
- <lastBuildDate>Fri, 18 Sep 2026 18:42:02 +0000</lastBuildDate>
+ <pubDate>Tue, 22 Sep 2026 11:33:51 +0000</pubDate>
+ <lastBuildDate>Tue, 22 Sep 2026 11:33:51 +0000</lastBuildDate>
<generator>Jekyll v4.4.1</generator>
diff --git a/output/images/accumulo-monitor-1.png
b/output/images/accumulo-monitor-1.png
index c6a711a49..6a83f3f25 100644
Binary files a/output/images/accumulo-monitor-1.png and
b/output/images/accumulo-monitor-1.png differ
