86 lines
3.1 KiB
Markdown
86 lines
3.1 KiB
Markdown
---
|
|
title: InfluxDB Enterprise startup process
|
|
description: >
|
|
On startup, InfluxDB Enterprise starts all subsystems and services in a deterministic order.
|
|
menu:
|
|
enterprise_influxdb_1_9:
|
|
weight: 10
|
|
name: Startup process
|
|
parent: Concepts
|
|
---
|
|
|
|
On startup, InfluxDB Enterprise starts all subsystems and services in the following order:
|
|
|
|
1. [TSDBStore](#tsdbstore)
|
|
2. [Monitor](#monitor)
|
|
3. [Cluster](#cluster)
|
|
4. [Precreator](#precreator)
|
|
5. [Snapshotter](#snapshotter)
|
|
6. [Continuous Query](#continuous-query)
|
|
7. [Announcer](#announcer)
|
|
8. [Retention](#retention)
|
|
9. [Stats](#stats)
|
|
10. [Anti-entropy](#anti-entropy)
|
|
11. [HTTP API](#http-api)
|
|
|
|
A **subsystem** is a collection of related services managed together as part of a greater whole.
|
|
A **service** is a process that provides specific functionality.
|
|
|
|
## Subsystems and services
|
|
|
|
### TSDBStore
|
|
The TSDBStore subsystem starts and manages the TSM storage engine.
|
|
This includes services such as the points writer (write), reads (query),
|
|
and [hinted handoff (HH)](/enterprise_influxdb/v1.9/concepts/clustering/#hinted-handoff).
|
|
TSDBSTore first opens all the shards and loads write-ahead log (WAL) data into the in-memory write cache.
|
|
If `influxd` was cleanly shutdown previously, there will not be any WAL data.
|
|
It then loads a portion of each shard's index.
|
|
|
|
{{% note %}}
|
|
#### Index versions and startup times
|
|
If using `inmem` indexing, InfluxDB loads all shard indexes into memory, which,
|
|
depending on the number of series in the database, can take time.
|
|
If using `tsi1` indexing, InfluxDB only loads hot shard indexes
|
|
(the most recent shards or shards currently being written to) into memory and
|
|
stores cold shard indexes on disk.
|
|
Use `tsi1` indexing to see shorter startup times.
|
|
{{% /note %}}
|
|
|
|
### Monitor
|
|
The Monitor service provides statistical and diagnostic information to InfluxDB about InfluxDB itself.
|
|
This information helps with database troubleshooting and performance analysis.
|
|
|
|
### Cluster
|
|
The Cluster service provides implementations of InfluxDB OSS v1.8 interfaces
|
|
that operate on an InfluxDB Enterprise v1.8 cluster.
|
|
|
|
### Precreator
|
|
The Precreator service creates shards before they are needed.
|
|
This ensures necessary shards exist before new time series data arrives and that
|
|
write-throughput is not affected the creation of a new shard.
|
|
|
|
### Snapshotter
|
|
The Snapshotter service routinely creates snapshots of InfluxDB Enterprise metadata.
|
|
|
|
### Continuous Query
|
|
The Continuous Query (CQ) subsystem manages all InfluxDB CQs.
|
|
|
|
### Announcer
|
|
The Announcer service announces a data node's status to meta nodes.
|
|
|
|
### Retention
|
|
The Retention service enforces [retention policies](/enterprise_influxdb/v1.9/concepts/glossary/#retention-policy-rp)
|
|
and drops data as it expires.
|
|
|
|
### Stats
|
|
The Stats service monitors cluster-level statistics.
|
|
|
|
### Anti-entropy
|
|
The Anti-entropy (AE) subsystem is responsible for reconciling differences between shards.
|
|
For more information, see [Use anti-entropy](/enterprise_influxdb/v1.9/administration/anti-entropy/).
|
|
|
|
### HTTP API
|
|
The InfluxDB HTTP API service provides a public facing interface to interact with
|
|
InfluxDB Enterprise and internal interfaces used within the InfluxDB Enterprise cluster.
|
|
|