influx-proxy无侵入式InfluxDB高可用方案测试

背景描述

目前因公司微服务发展需要,构建基于 Influxdb 的监控体系。由于 Influxdb 官方提供的 集群模式为闭源收费版本,不足以满足前期的公司监控体系的发展需要。因此我们寻找到基于官方提供的 Influx-Play 的代理服务的二次开发版本 Influx-Proxy。Influx-Proxy提供了以下功能: 基于一致性 Hash 的自动分片,多环多写实现完成数据备份,数据重平衡机制,故障恢复机制以及数据同步的实现,满足我们目前的使用需求: 无侵入式Influxdb集群化,数据备份,故障恢复。

但是我们在对 Influx-Proxy 进行代码审计的过程中发现几个问题:

  1. 在根据 query 对 measurement 的解析过程中我们发现,获取到的 measurement 名 并不是 我们的 真是的表名,而是 我们 Influxdb 中针对 当前 库 设置的 Retention Policies 的名。这将导致我们所有的分片查找最后都在一个 Influxdb 实例上。
  2. 我们发现了多个地方的 Data Race。导致 Data Race 的地方主要有: ① 代码中对于某个实例的健康检查状态,后台定时任务会一直检查实例的活性,但有其他任务在同时读取实例的活性,两边的操作均未加锁,导致 data race,加锁字段为: HttpBackend 结构体中的 Active ; ② Influxdb 实例结构体中 对于 是否在进行 重写操作时, 对 rewriteRuning 进行判断,但同样在 取值以及赋值时未加锁,导致 data race; ③ 在 CacheBuffer 结构体中,用于存储 DB 缓冲区 行数的字段 Counter, 未加锁; ④ 在 FlushBuffer 中,针对: 缓冲区的 清空 未执行锁操作导致 data race.

我们针对上述情况进行了 修复,并将修复前与修复后的代码进行了压测测试。在压测测试中,我们使用了 双环双机器 进行压测实验。

测试说明:

  1. 压测中的一律使用 机器 构建 Influxdb 二进制
  2. 除 压测 之外,所有的测试均使用 Docker 部署 多实例 Influxdb 测试方案。

测试准备

压测准备

机器准备

机器名 操作系统版本 CPU 内存
192.168.2.80 Ubuntu 18.04.5 LTS x86_64 , 8 核 16 Gi
192.168.2.97 Ubuntu 18.04.5 LTS x86_64 ,4 核 8 Gi

实例准备

Influxdb 版本: 1.8.0

部署方式: 二进制部署

操作数据库: msp

开放数据端口: 8086

数据源准备

  • Influx-Proxy 修改前的源程序: 位于 /home/taosheng/influx-proxy-gitsrc

  • Influx-Proxy 修改后的源程序: 位于 /home/taosheng/influx-proxy-sunyang

  • msp_backend 进行压测的数据源提供,增加 四张表随机性的写入

  • 准备 两台 Influxdb 实例,开放 8086 口, 并创建好 msp 库

其他测试

机器准备

机器名 操作系统版本 Docker版本 Influxdb镜像
10.20.1.100 Ubuntu 18.04.5 LTS 19.03.12 harbor.oneitfarm.com/cidata/influxdb:1.8.3-alpine
10.20.4.132 Ubuntu 18.04.5 LTS 19.03.12 harbor.oneitfarm.com/cidata/influxdb:1.8.3-alpine

实例准备,默认数据库: msp

实例名 部署方式 实例镜像 所在机器
inlfux-1 容器部署 harbor.oneitfarm.com/cidata/influxdb:1.8.3-alpine [100 132]
inlfux-2 容器部署 harbor.oneitfarm.com/cidata/influxdb:1.8.3-alpine [100 132]
inlfux-3 容器部署 harbor.oneitfarm.com/cidata/influxdb:1.8.3-alpine [100 132]

数据准备

  • msp_backend 进行压测的数据源提供,增加 四张表随机性的写入

  • Influx-Proxy 修改前的源程序: 位于 /home/taosheng/influx-proxy-gitsrc

  • Influx-Proxy 修改后的源程序: 位于 /home/taosheng/influx-proxy-sunyang

测试过程

压测结果

修改前

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Concurrency Level:      20
Time taken for tests: 2.887 seconds
Complete requests: 100000
Failed requests: 0
Total transferred: 7500000 bytes
HTML transferred: 0 bytes
Requests per second: 34632.79 [#/sec] (mean)
Time per request: 0.577 [ms] (mean)
Time per request: 0.029 [ms] (mean, across all concurrent requests)
Transfer rate: 2536.58 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 5
Processing: 0 0 0.2 0 17
Waiting: 0 0 0.2 0 11
Total: 0 1 0.2 1 17

Percentage of the requests served within a certain time (ms)
50% 1
66% 1
75% 1
80% 1
90% 1
95% 1
98% 1
99% 1
100% 17 (longest request)

结果:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
> select sum(count) from test_udp_proxy_4;
name: test_udp_proxy_4
time sum
---- ---
0 33249
> select sum(count) from test_udp_proxy_3;
name: test_udp_proxy_3
time sum
---- ---
0 597
> select sum(count) from test_udp_proxy_2;
name: test_udp_proxy_2
time sum
---- ---
0 35010
> select sum(count) from test_udp_proxy_1;
name: test_udp_proxy_1
time sum
---- ---
0 31144

执行 10万 请求,当前 Influxdb 实例实际写入数据 共计 10 万

修改后

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Concurrency Level:      20
Time taken for tests: 2.776 seconds
Complete requests: 100000
Failed requests: 0
Total transferred: 7500000 bytes
HTML transferred: 0 bytes
Requests per second: 36021.93 [#/sec] (mean)
Time per request: 0.555 [ms] (mean)
Time per request: 0.028 [ms] (mean, across all concurrent requests)
Transfer rate: 2638.32 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 4
Processing: 0 0 0.3 0 10
Waiting: 0 0 0.3 0 10
Total: 0 1 0.3 1 10

Percentage of the requests served within a certain time (ms)
50% 1
66% 1
75% 1
80% 1
90% 1
95% 1
98% 1
99% 1
100% 10 (longest request)

结果:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
> select sum(count) from test_udp_proxy_1;
name: test_udp_proxy_1
time sum
---- ---
0 7081
> select sum(count) from test_udp_proxy_2;
name: test_udp_proxy_2
time sum
---- ---
0 24
> select sum(count) from test_udp_proxy_3;
name: test_udp_proxy_3
time sum
---- ---
0 35820
> select sum(count) from test_udp_proxy_4;
name: test_udp_proxy_4
time sum
---- ---
0 57074

执行 10万 请求,当前 Influxdb 实例实际写入数据 共计 99999 条。

压测结论

  1. 相比较修改前, 我们在 原来的基础上,修复了 influx-proxy 存在的 DataRace , 数据表获取异常等 BUG,且在性能上并无影响,提高了整个程序的健壮性。
  2. 在不考虑时间精度的影响下,influx-proxy的数据转发能力达到 100%

重平衡机制

重平衡的目的:当 influxdb 实例无法承载当前数据量时,需要扩充新的 influxdb 实例,或者当前所有 influxdb 实例硬件资源严重过剩,需要缩减 influxdb 实例,则需要进行扩缩容操作:

  1. 为了高可用性,不停机,扩容时我们需要 一个 circle 接一个 circle 进行操作;
  2. 我们修改 proxy 配置文件
  3. 调用 /rebalance 接口

我们调用 /rebalance 接口后,我们重平衡的目标 circle 变成 write only 状态,此时不影响 数据的写入,但是无法在进行 查询。直至重平衡完成,当前的 circle 的状态恢复。

扩容完成后,我们需要清理迁移之前的旧数据。参考 API: /cleanup

说明

  1. 重平衡只针对目标 circle,不影响 其他的 circle

  2. 如果我们进行重平衡时,面对大量数据的时候,执行重平衡操作,迁移性能低下,耗时长,建议方案如下:

    使用官方 influx_inspect export -out 导出所有的数据,在使用 influx -import -path , 导入到 influx-proxy , 此方案效率会高于 rebalance 操作。

    以数据为单位,导出全部数据,如果只需要导出数据库部分 measurements 数据,此方案不妥。

    使用 influx-tool -dir 工具导出部分 measurements数据,再使用 influx -import -path 导入到 influx proxy,此方案效率会高于 rebalance 操作.

    • 支持指定 measurement 列表或范围导出
    • 支持 -measurements 指定 measurements 列表导出,以英文逗号分隔或者
    • -range 指定 measurements 起始范围导出,形如 start,end 格式
    • -float-fields 指定 string 类型的 field 列表,强转为 float 类型
    • 将同时具有 string 和 float 类型的 field 自动转换为 float 类型

测试1:扩容

测试场景:

在双环双实例下,随着业务场景的增长,环内单实例已不足以满足使用需求,需要对 InfluxDB 进行扩容,扩展为双环四实例。

我们先往 influx-1写入10万+ 的数据:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
> show measurements;
name: measurements
name
----
test_udp_proxy_1
test_udp_proxy_2
test_udp_proxy_3
test_udp_proxy_4
> select sum(count) from test_udp_proxy_1;
name: test_udp_proxy_1
time sum
---- ---
0 34953
> select sum(count) from test_udp_proxy_2
name: test_udp_proxy_2
time sum
---- ---
0 27721
> select sum(count) from test_udp_proxy_3
name: test_udp_proxy_3
time sum
---- ---
0 20291
> select sum(count) from test_udp_proxy_4
name: test_udp_proxy_4
time sum
---- ---
0 17035

现在,我们针对circle-0来增加一个实例,在proxy.yaml 中增加一台实例节点:

1
2
3
4
5
- name: influxdb-1-2
url: 'http://10.20.1.100:8087'
username: root
password: '123456'
auth_secure: false

重启,influx-proxy,在调用 /rebalance 接口。

1
2
2020/12/01 00:40:49.772069 /opt/project/go/src/influx-proxy/backend/config.go:183: circle 0: 2 backends loaded
2020/12/01 00:40:49.772073 /opt/project/go/src/influx-proxy/backend/config.go:183: circle 1: 1 backends loaded

可以看到,在circle-0里面,我们加载了两个 Backend,调用接口。

1
2
3
curl -X POST 'http://127.0.0.1:80/rebalance?circle_id=0&operation=add'

response: accepted

说明成功执行了重平衡操作。

现在,我们需要查询当前的重平衡的状态,去判断是否完成,调用接口:/transfer/stats

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
curl 'http://127.0.0.1:80/transfer/stats?circle_id=0&type=rebalance&pretty=true'

response:
{
"http://10.20.1.100:8086": {
"database_total": 1,
"database_done": 1,
"measurement_total": 4,
"measurement_done": 4,
"transfer_count": 1,
"inplace_count": 3
},
"http://10.20.1.100:8087": {
"database_total": 1,
"database_done": 1,
"measurement_total": 0,
"measurement_done": 0,
"transfer_count": 0,
"inplace_count": 0
}
}

现在我们去查我们增加的实例中的 measurement,从上述结果中,我们可以看到的是在 10.20.1.100:8086这个实例里面有一张表进行了 transfer 操作,我们需要去 新的实例里面看一下是否真的存在一张表,且表的数据与原表数据保持一致.

1
2
3
4
5
6
7
8
9
10
> show measurements;
name: measurements
name
----
test_udp_proxy_1
> select sum(count) from test_udp_proxy_1;
name: test_udp_proxy_1
time sum
---- ---
0 34953

我们在 新的实例中又看到表: test_udp_proxy_1,这在一开始是没有的,而且数据上,与原来是一致的。说明数据并没有丢失。

我们先来在写入 10万+ 的数据。先看 新增节点里面的表数据:

1
2
3
4
5
6
7
8
9
10
> select sum(count) from test_udp_proxy_1;
name: test_udp_proxy_1
time sum
---- ---
0 34953
> select sum(count) from test_udp_proxy_1;
name: test_udp_proxy_1
time sum
---- ---
0 42056

数据是已经成功写入了。再看 influx-1 节点

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
> select sum(count) from test_udp_proxy_1
name: test_udp_proxy_1
time sum
---- ---
0 34953
> select sum(count) from test_udp_proxy_2
name: test_udp_proxy_2
time sum
---- ---
0 51415
> select sum(count) from test_udp_proxy_3
name: test_udp_proxy_3
time sum
---- ---
0 49447
> select sum(count) from test_udp_proxy_4
name: test_udp_proxy_4
time sum
---- ---
0 57082

现在 表 test_udp_proxy_1 的分片数据都写入到了 influx-1,满足我们的要求,再来看我们的数据的丢失情况,我们将 test_udp_proxy_1/2/3/4 表的数据累加起来,结果是正好是 20万,说明我们的数据 100% 写入了。此时,我们的扩容成功。

测试2:缩容

扩容我们可以看到是 OK 的,现在我们现在测试一下缩容。

测试场景:

由于某些原因,导致公司的 circle-0 中的 influx-1 节点必须要下线了,因此我们需要进行缩容。按照步骤,我们在 扩容后的基础上来进行测试,按照我们的想法,目前有两点疑问:

  1. 在进行缩容时,influx-1节点的数据是否能够完整的无丢失的写入到 influx-2节点?
  2. 由于 influx-2 是在 扩容后 添加进来的,里面的数据是否会有影响?

我们修改proxy.yaml配置文件,去掉 inlfux-1节点,重启 influx-proxy后执行 /rebalance

1
2
2020/12/01 01:11:28.830531 /opt/project/go/src/influx-proxy/backend/config.go:183: circle 0: 1 backends loaded
2020/12/01 01:11:28.830535 /opt/project/go/src/influx-proxy/backend/config.go:183: circle 1: 1 backends loaded

现在开始调用/rebalance接口,执行重平衡操作。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
curl --location --request POST 'http://192.168.48.115:80/rebalance?circle_id=0&operation=rm' \
--header 'Content-Type: application/json' \
--data '{
"backends": [
{
"name": "influxdb-1-1",
"url": "http://127.0.0.1:8086",
"username": "root",
"password": "123456",
"auth_secure": false
}
]
}'
accepted

开始查询状态:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
curl 'http://127.0.0.1:80/transfer/stats?circle_id=0&type=rebalance&pretty=true'
{
"http://10.20.1.100:8086": {
"database_total": 1,
"database_done": 1,
"measurement_total": 4,
"measurement_done": 4,
"transfer_count": 4,
"inplace_count": 0
},
"http://10.20.1.100:8087": {
"database_total": 1,
"database_done": 1,
"measurement_total": 1,
"measurement_done": 1,
"transfer_count": 0,
"inplace_count": 1
}
}

可以看到,目前在 influx-1 中发生了 transfer 的表数一共有 4 个, 说明了 我们之前 扩容时的那张表也过来了。在数据上会有什么变化,可以再看下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
> select sum(count) from test_udp_proxy_1;
name: test_udp_proxy_1
time sum
---- ---
0 42056
> select sum(count) from test_udp_proxy_2;
name: test_udp_proxy_2
time sum
---- ---
0 51415
> select sum(count) from test_udp_proxy_3;
name: test_udp_proxy_3
time sum
---- ---
0 49447
> select sum(count) from test_udp_proxy_4;
name: test_udp_proxy_4
time sum
---- ---
0 57082

可以看到也是一样的,数据没丢失。

之前对于重平衡,有提及到如果存在数据量大的情况下,使用 /rebalance 会导致效率低下,建议使用原生的,这一块就暂时不在这边进行测试了。

故障恢复机制

当出现 influxdb 实例机器故障,甚至无法恢复的情形下,需要对故障机器所在的 circle 进行数据恢复。步骤如下:

  1. 确定故障 circle 中需要恢复的 influxdb 的实例列表
  2. 修改 proxy.yaml , 重启 proxy
  3. 调用接口 /recovery

与 重平衡 方式相同,在故障恢复的过程中,待 恢复 的 circle 状态被修改为 write only 状态。

recovery 操作是将一个健康 circle 的数据恢复到一个故障 circle 中的部分或全部 influxdb 实例,是 circle circle 之间的单向操作

测试场景:

在双环四实例的情况下,我们的 监控体系在正常的运行,但是由于某些原因,导致了influx-1节点宕机了,在同事的努力下,我们加紧恢复了宕机的实例,现在,需要进行 故障恢复。

现在先让数据正常写入 20 万+ 的数据。

现在我们新写入的数据已经完全写入了,在 influx-1实例中有test_udp_proxy_2/3/4 三张 measurements ,

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
> select sum(count) from test_udp_proxy_2
name: test_udp_proxy_2
time sum
---- ---
0 54150
> select sum(count) from test_udp_proxy_3
name: test_udp_proxy_3
time sum
---- ---
0 44186
> select sum(count) from test_udp_proxy_4
name: test_udp_proxy_4
time sum
---- ---
0 38392

influx-2 中有 ``test_udp_proxy_1。现在某些原因导致 influx-1宕机了。此时我们的influx-proxy` 的控制台会有许多的 错误信息输出:

1
http error: Get "http://10.20.1.100:8086/ping": dial tcp 10.20.1.100:8086: connect: connection refused

说明此时服务的确宕机了。

现在先看下,influx-2measurement test_udp_proxy_1 的数据量 :

1
2
3
4
5
6
7
8
9
10
> show measurements;
name: measurements
name
----
test_udp_proxy_1
> select sum(count) from test_udp_proxy_1;
name: test_udp_proxy_1
time sum
---- ---
0 63272

现在我们再来写入10万+ 的数据,写入后,看到这个 measurement

1
2
3
4
5
 select sum(count) from test_udp_proxy_1;
name: test_udp_proxy_1
time sum
---- ---
0 82684

现在我们记得总数是 30万。

同时,我们可以看到 influx-proxy 的控制台:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2020/12/01 02:08:42.085847 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 339534
2020/12/01 02:08:42.157719 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 644522
2020/12/01 02:08:42.179808 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 686160
2020/12/01 02:08:42.238606 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 864648
2020/12/01 02:08:42.311226 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 1167014
2020/12/01 02:08:42.374178 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 1472186
2020/12/01 02:08:42.432237 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 1744100
2020/12/01 02:08:42.455364 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 1771432
2020/12/01 02:08:42.500429 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 1922550
2020/12/01 02:08:42.513067 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 1926284
2020/12/01 02:08:42.568242 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 2113926
2020/12/01 02:08:42.623643 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 2357458
2020/12/01 02:08:42.666539 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 2563086
2020/12/01 02:08:42.738340 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 2764160
2020/12/01 02:08:42.780365 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 2827556
2020/12/01 02:08:42.828035 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 3049376
2020/12/01 02:08:42.875487 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 3247690
2020/12/01 02:08:42.907580 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 3341124
2020/12/01 02:08:42.973571 /opt/project/go/src/influx-proxy/backend/file.go:169: write meta: influxdb-1-1, 0

现在重启 influx-1 实例,

1
2
3
4
5
6
7
8
9
10
11
12
13
root@influxdb-1:/home/ubuntu# docker stop influx-1
influx-1
root@influxdb-1:/home/ubuntu# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ce7b209e044a harbor.oneitfarm.com/cidata/influxdb:1.8.3-alpine "/entrypoint.sh infl…" 4 days ago Up 4 days 0.0.0.0:8087->8086/tcp influx-2
55359b67637e harbor.oneitfarm.com/cidata/influxdb:1.8.3-alpine "/entrypoint.sh infl…" 4 days ago Up 4 days 0.0.0.0:8088->8086/tcp influx-3
root@influxdb-1:/home/ubuntu# docker start influx-1
influx-1
root@influxdb-1:/home/ubuntu# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ce7b209e044a harbor.oneitfarm.com/cidata/influxdb:1.8.3-alpine "/entrypoint.sh infl…" 4 days ago Up 4 days 0.0.0.0:8087->8086/tcp influx-2
28d6ac38adde harbor.oneitfarm.com/cidata/influxdb:1.8.3-alpine "/entrypoint.sh infl…" 4 days ago Up 2 seconds 0.0.0.0:8086->8086/tcp influx-1
55359b67637e harbor.oneitfarm.com/cidata/influxdb:1.8.3-alpine "/entrypoint.sh infl…" 4 days ago Up 4 days 0.0.0.0:8088->8086/tcp influx-3

重启后,我们看一下 influx-1 里面的 measurement,

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
> use msp;
Using database msp
> select sum(count) from test_udp_proxy_2
name: test_udp_proxy_2
time sum
---- ---
0 79730
> select sum(count) from test_udp_proxy_3
name: test_udp_proxy_3
time sum
---- ---
0 57644
> select sum(count) from test_udp_proxy_4
name: test_udp_proxy_4
time sum
---- ---
0 79942

这里我们重启后,我们发现 表中的 数据被更新了。经过求和,我们发现 最后的总数是在 30万。

数据同步机制

由于环境的不同,会有概率出现各个 circle 数据不一致的情况、导致脏读问题,因此需要定期做数据同步,以达到数据一致性,实现方案是对所有 circle 的数据进行互相同步。步骤:

  1. 确定开始同步的时间点(10位时间戳),将同步此时间点及之后的数据
  2. 调用接口 /resync

resync 操作是所有 circle 直接互相同步数据的操作

结论

  1. Influx Proxy 是一个基于高可用、一致性哈希的 InfluxDB 集群代理服务;
  2. 针对 InfluxDB 高可用集群无侵入式部署方案,且支持 influxdb 原生的 写入与 查询功能,进过改进,增加了 UDP 的写入形式;
  3. 具有动态扩/缩容、故障恢复、数据同步等能力;
  4. 在不考虑时间精度的影响下,influx-proxy的数据转发能力达到 100%
  5. 完全满足目前公司针对 InfluxDB 的集群化要求。

API

接口 /rebalance

定义

1
POST http://127.0.0.1:80/rebalance

Params

查询参数 可选/必须 描述
circle_id=0 必须 circle 的 id,从索引 0 开始
operation= 必须 操作类型,可选值为 add 或 rm
dbs= 可选 数据库列表,以英文逗号 ‘,’ 分隔,为空时将默认为全部数据库
worker=1 可选 迁移数据用到的最大线程数,默认为 1
batch=25000 可选 迁移数据时一批的写入点数,默认为 25000
limit=1000000 可选 迁移数据时一次查询的限制行数,默认为 1000000
ha_addrs= 必须 (若至少有两个正在运行的 influx proxy 实例时) 所有正在运行的 influx proxy 实例的高可用地址列表 (host1:port1,host2:port2...),以英文逗号 ‘,’ 分隔,单实例时此参数将被忽略
u= 可选 (若未启用认证) 设置认证用户,若启用认证
p= 可选 (若未启用认证) 设置认证密码,若启用认证

Body

operationrm 的时候,必须添加被移除的 influxdb 实例的配置信息,以 json 格式放入到请求 body

1
2
3
4
5
6
7
8
9
10
11
{
"backends": [
{
"name": "influxdb-1-1",
"url": "http://127.0.0.1:8086",
"username": "root",
"password": "123456",
"auth_secure": false
}
]
}

接口 /recovery

将指定 circle 的全量数据恢复到故障的 circle 的全部或部分实例

定义

1
POST http://127.0.0.1:80/recovery

Params

查询参数 可选/必须 描述
from_circle_id=0 必须 来源 circle 的 id,从索引 0 开始
to_circle_id=1 必须 待恢复 circle 的 id,从索引 0 开始
backend_urls= 可选 待恢复的 influxdb 实例 url 列表,以英文逗号 ‘,’ 分隔,为空时将默认为待恢复 circle 的全部 influxdb 实例 url 列表
dbs= 可选 数据库列表,以英文逗号 ‘,’ 分隔,为空时将默认为全部数据库
worker=1 可选 迁移数据用到的最大线程数,默认为 1
batch=25000 可选 迁移数据时一批的写入点数,默认为 25000
limit=1000000 可选 迁移数据时一次查询的限制行数,默认为 1000000
ha_addrs= 必须 (若至少有两个正在运行的 influx proxy 实例时) 所有正在运行的 influx proxy 实例的高可用地址列表 (host1:port1,host2:port2...),以英文逗号 ‘,’ 分隔,单实例时此参数将被忽略
u= 可选 (若未启用认证) 设置认证用户,若启用认证
p= 可选 (若未启用认证) 设置认证密码,若启用认证

示例

1
2
# 从 circle 0 恢复所有数据到 circle 1
curl -X POST 'http://127.0.0.1:80/recovery?from_circle_id=0&to_circle_id=1'

接口 /transfer/stats

查询迁移进度统计信息

定义

1
GET http://127.0.0.1:80/transfer/stats

Params

查询参数 可选/必须 描述
circle_id=0 必须 circle 的 id,从索引 0 开始
type= 必须 状态统计类型,可选值为 rebalance、recovery、resync 或 cleanup
pretty=true 可选 以美化的 json 格式输出
u= 可选 (若未启用认证) 设置认证用户,若启用认证
p= 可选 (若未启用认证) 设置认证密码,若启用认证

接口 /cleanup

对指定的 circle 中不该存储在对应实例的错误数据进行清理

定义

1
POST http://127.0.0.1:80/cleanup

Params

查询参数 可选/必须 描述
circle_id=0 必须 circle 的 id,从索引 0 开始
worker=1 可选 迁移数据用到的最大线程数,默认为 1
batch=25000 可选 迁移数据时一批的写入点数,默认为 25000
limit=1000000 可选 迁移数据时一次查询的限制行数,默认为 1000000
ha_addrs= 必须 (若至少有两个正在运行的 influx proxy 实例时) 所有正在运行的 influx proxy 实例的高可用地址列表 (host1:port1,host2:port2...),以英文逗号 ‘,’ 分隔,单实例时此参数将被忽略
u= 可选 (若未启用认证) 设置认证用户,若启用认证
p= 可选 (若未启用认证) 设置认证密码,若启用认证

接口 /resync

所有 circle 互相同步数据

定义

1
POST http://127.0.0.1:80/resync

Params

查询参数 可选/必须 描述
tick= 可选 所有 circle 互相同步从 时间点开始(10位时间戳,包含该点)的数据,默认为 0,表示同步所有历史数据
dbs= 可选 数据库列表,以英文逗号 ‘,’ 分隔,为空时将默认为全部数据库
worker=1 可选 迁移数据用到的最大线程数,默认为 1
batch=25000 可选 迁移数据时一批的写入点数,默认为 25000
limit=1000000 可选 迁移数据时一次查询的限制行数,默认为 1000000
ha_addrs= 必须 (若至少有两个正在运行的 influx proxy 实例时) 所有正在运行的 influx proxy 实例的高可用地址列表 (host1:port1,host2:port2...),以英文逗号 ‘,’ 分隔,单实例时此参数将被忽略
u= 可选 (若未启用认证) 设置认证用户,若启用认证
p= 可选 (若未启用认证) 设置认证密码,若启用认证

接口 /debug/pprof

生成用于性能瓶颈排障定位的采样文件

定义

1
curl http://127.0.0.1:80/debug/pprof/

示例

1
curl -o <path/to/pprof-cpu>  http://127.0.0.1:80/debug/pprof/profile
1
curl -o <path/to/pprof-heap> http://127.0.0.1:80/debug/pprof/heap