InfluxDB企业集群功能

权利

启动influxd-meta或influxd需要有效的许可证密钥。许可证密钥限制可以添加到集群中的数据节点数量以及数据节点可以使用的CPU核心数。没有有效的许可证，进程将中止启动。

通过 /debug/vars 端点访问您的许可证到期日期。

$ curl http://localhost:8086/debug/vars | jq '.entitlements'
{
  "name": "entitlements",
  "tags": null,
  "values": {
    "licenseExpiry": "2022-02-15T00:00:00Z",
    "licenseType": "license-key"
  }
}

查询管理

查询管理在整个集群中工作。具体而言， SHOW QUERIES 和 KILL QUERY 可以在任何数据节点上运行。 SHOW QUERIES 将报告在整个集群中运行的所有查询及其运行查询的节点。 KILL QUERY 可以中止在本地节点或任何其他远程数据节点上运行的查询。有关在 InfluxDB 企业集群上使用 SHOW QUERIES 和 KILL QUERY 的详细信息， 请参阅 查询管理。

订阅

Kapacitor使用的订阅在集群中工作。对任何节点的写入将被转发给所有支持的订阅协议的订阅者。

连续查询

集群的配置和操作考虑事项

了解如何配置 InfluxDB Enterprise 及其对连续查询 (CQ) 引擎行为的影响是很重要的：

• 数据节点配置 [continuous queries] run-interval – InfluxDB 检查 CQ 是否需要运行的间隔时间。将此选项设置为您的 CQs 运行的最低间隔。例如，如果您最频繁的 CQ 每分钟运行一次，请将 run-interval 设置为 1m。
• 元节点配置 [meta] lease-duration – 数据节点从元节点获得的租约的默认持续时间。当租约持续时间到期后，租约自动失效。租约确保在给定时间内只有一个数据节点在运行某个任务。例如，连续查询使用租约，以确保所有数据节点不会同时运行相同的连续查询。
• CQ 的执行时间 – CQ 是顺序执行的。根据它们为完成所需完成的工作量，上述配置参数可能会对 CQ 的观察行为产生影响。

CQ服务在每个节点上运行，但在任何一个时间点，只有一个节点被授予独占访问权限以执行CQ。 然而，每当run-interval结束（并假设一个节点当前没有执行CQ），一个节点会尝试获取CQ租约。 默认情况下，run-interval为一秒，因此数据节点积极检查是否可以获取租约。 在所有CQ在lease-duration（默认是1m）内执行的集群中，最先获取租约的数据节点在run-interval结束时仍然持有租约的可能性很大。 其他节点将被拒绝租约，当持有租约的节点再次请求时，租约将以lease-duration延长。 因此，在典型情况下，我们观察到一个数据节点获取CQ租约并保持不变。 它有效地成为CQ的执行者，直到它被回收（由于任何原因）。

现在考虑以下情况，CQs的执行时间比lease-duration更长，所以当租约到期时， 大约1秒后另一个数据节点请求并获得了租约。原租约持有者正在忙于顺序执行最初交给它的CQs列表，而现在持有租约的数据节点开始从列表的顶部执行CQs。

基于这个场景，可能看起来CQs是在“并行执行”，因为多个数据节点本质上是在注册的CQs中“顺序滚动”，租约也在节点之间滚动。这里的“长杆”实际上是你最复杂的CQ——这可能意味着在某些时刻，所有节点都在尝试执行相同的复杂CQ（并且可能在资源上竞争，因为它们覆盖了在每个执行该查询的节点生成的点——可能有一些阶段性的偏移）。

为了避免这种行为，这是可取的，因为它减少了集群的整体负载，您应该将租约持续时间设置为大于您正在运行的所有 CQs 的总执行时间。

根据当前配置CQs执行的方式，处理并行性的方法是使用 Kapacitor来运行更复杂的CQs。 将Kapacitor视为连续查询引擎。 然而，您可以将更简单且高性能的CQs保留在数据库中 - 但要确保租约持续时间大于它们的总执行时间，以确保 “额外”负载不会不必要地引入到您的集群中。

PProf 端点

元节点暴露 /debug/pprof 端点用于性能分析和故障排除。

分片移动

• Copy shard 支持 - 将一个分片从一个节点复制到另一个节点
• 复制分片状态 - 查询复制分片请求的状态
• Kill copy shard - 杀死正在运行的碎片副本
• 移除分片 - 从节点中移除一个分片（这将删除数据）
• 截断分片 - 立即截断所有活动分片组并开始新的分片（在添加节点或更改复制因子时，这非常有用。）

此功能通过元服务上的API以及influxd-ctl子命令公开。

OSS 转换

支持将OSS单一服务器作为第一个数据节点导入。

请参阅 OSS to cluster migration 以获取 逐步说明。

查询路由

查询引擎会跳过持有查询所需分片的失败节点。 如果另一个节点上有副本，它将会在该节点上重试。

备份和恢复

InfluxDB 企业集群从版本 0.7.1 开始支持备份和恢复功能。 请参阅 备份和恢复 以获取更多信息。

被动节点设置（实验性）

被动节点充当负载均衡器——它们接受写调用，执行分片查找和RPC调用（在活动数据节点上），并将写入分发到活动数据节点。它们不拥有分片或接受写入。

当您的复制因子（RF）为2或更多，并且CPU使用率始终超过80％时，请使用此功能。使用被动功能可以在您无法再进行垂直扩展时扩展集群。特别是在您经历大量提示转交增长时非常有用。被动节点将提示转交队列写入自己的磁盘，然后定期与适当的节点进行通信，直到可以将队列内容发送到那里。

使用主动-被动节点设置的最佳实践：

• 当您有一个大型集群设置时使用，通常是8个或更多节点。
• 保持活跃节点与被动节点的比例在1:1和2:1之间。
• 被动节点应该接收所有写操作。

有关更多信息，请参见如何将被动节点添加到集群。