influx-proxy扩容问题，支持热部署

[slzheng2017]

你好，在测试扩容功能时，有些疑问

假设：influx-proxy配置了

• circle-0: influxdb-1，influxdb-2
• circle-1: influxdb-3，influxdb-4

同时，有两个influx-proxy

• influx-proxy-1 port7076
• influx-proxy-2 port7077

前端用ha-proxy做负载均衡，持续往两个influx-proxy写入数据

我的扩容步骤如下：

1. 启动influxdb-5
2. 修改influx-proxy-1的proxy.json，增加circle-0的节点，使得circle-0拥有节点：influxdb-1、influxdb-2、influxdb-5
3. 按照文档的扩容步骤扩容

3.1 重启influx-proxy-1

3.2 执行rebalance命令，会使得circle-0 变为只写状态。因为有两个influx-proxy，所以指定ha_addr=influx-proxy-1:7076,inflxu-proxy-2:7077

我这里有两个疑惑，还请解答：

1. 操作步骤3.1到操作步骤3.2之间的时间里，如果有数据通过influx-proxy-1写入circle-0，假设数据会写入到influxdb-5节点中，结果是失败，因为influxdb-5节点中连database都没有建，这个机制就是这样吗？当然，我可以手动在influxdb-5建好database，这样influx-proxy-1就可以写入circle-0点influxdb-5节点了

2. rebalance的内部逻辑是怎么做的？数据是持续写入，influx-proxy-1的rebalance操作，和数据写入是同时进行的。假设数据是通过influx-proxy-1写入circle-0，那没有问题，数据会写入新的节点inflxudb-5，但存在数据写入是通过influx-proxy-2写入circle-0的，这时influx-proxy-2并没有配置circle-0的influxdb-5节点，假设他的一致性hash会写入influxdb-1，那这部分新写入的数据会被rebalance吗？感觉有点绕，有点晕

[chengshiwen]

操作步骤3.1到操作步骤3.2之间的时间里，如果有数据通过influx-proxy-1写入circle-0，假设数据会写入到influxdb-5节点中，结果是失败，因为influxdb-5节点中连database都没有建，这个机制就是这样吗？当然，我可以手动在influxdb-5建好database，这样influx-proxy-1就可以写入circle-0点influxdb-5节点了

原因：如果裸的influxdb-5刚启动，并且proxy.json修改完、influx-proxy重新启动后，在执行rebalance命令之前的这段时间里，influxdb-5必然会因为database没有创建而写入失败。因此最好的方案：是先在influxdb-5创建好相应的数据库，文档我优化下

rebalance的内部逻辑是怎么做的？数据是持续写入，influx-proxy-1的rebalance操作，和数据写入是同时进行的。假设数据是通过influx-proxy-1写入circle-0，那没有问题，数据会写入新的节点inflxudb-5，但存在数据写入是通过influx-proxy-2写入circle-0的，这时influx-proxy-2并没有配置circle-0的influxdb-5节点，假设他的一致性hash会写入influxdb-1，那这部分新写入的数据会被rebalance吗？感觉有点绕，有点晕

1. rebalance的内部逻辑：只在同一个circle里进行rebalance，扫描扫描所有measurement，重新计算其正确存储的influxdb，然后将measurement的数据写到该正确的influxdb。新数据由于按照新的分配方式，所以和老数据不会产生冲突
2. 双influx-proxy的问题：目前的最佳实践是，同时停掉influx-proxy，并完成proxy.json变更和重启，否则就会出现proxy.json配置不一致导致写数据出现不在正确位置的问题
3. ”那这部分新写入的数据会被rebalance吗“这个取决于circle-0后台异步对每个measurement执行rebalance的顺序，建议在双proxy的情况下，proxy.json变更和proxy重启都完成后，再执行rebalance操作
4. 目前influx-proxy的设计架构是Shared-nothing architecture（无共享架构)，维护简单，在多influx-proxy的情况下，也会带来一致性问题。最近我在基于 influxdb 1.8.10 开发 influxdb cluster（和 influxdb enterprise 方案基本相同），预计3月份完成，上述问题都能更好地解决

[slzheng2017]

操作步骤3.1到操作步骤3.2之间的时间里，如果有数据通过influx-proxy-1写入circle-0，假设数据会写入到influxdb-5节点中，结果是失败，因为influxdb-5节点中连database都没有建，这个机制就是这样吗？当然，我可以手动在influxdb-5建好database，这样influx-proxy-1就可以写入circle-0点influxdb-5节点了

原因：如果裸的influxdb-5刚启动，并且proxy.json修改完、influx-proxy重新启动后，在执行rebalance命令之前的这段时间里，influxdb-5必然会因为database没有创建而写入失败。因此最好的方案：是先在influxdb-5创建好相应的数据库，文档我优化下

rebalance的内部逻辑是怎么做的？数据是持续写入，influx-proxy-1的rebalance操作，和数据写入是同时进行的。假设数据是通过influx-proxy-1写入circle-0，那没有问题，数据会写入新的节点inflxudb-5，但存在数据写入是通过influx-proxy-2写入circle-0的，这时influx-proxy-2并没有配置circle-0的influxdb-5节点，假设他的一致性hash会写入influxdb-1，那这部分新写入的数据会被rebalance吗？感觉有点绕，有点晕

1. rebalance的内部逻辑：只在同一个circle里进行rebalance，扫描扫描所有measurement，重新计算其正确存储的influxdb，然后将measurement的数据写到该正确的influxdb。新数据由于按照新的分配方式，所以和老数据不会产生冲突
2. 双influx-proxy的问题：目前的最佳实践是，同时停掉influx-proxy，并完成proxy.json变更和重启，否则就会出现proxy.json配置不一致导致写数据出现不在正确位置的问题
3. ”那这部分新写入的数据会被rebalance吗“这个取决于circle-0后台异步对每个measurement执行rebalance的顺序，建议在双proxy的情况下，proxy.json变更和proxy重启都完成后，再执行rebalance操作
4. 目前influx-proxy的设计架构是Shared-nothing architecture（无共享架构)，维护简单，在多influx-proxy的情况下，也会带来一致性问题。最近我在基于 influxdb 1.8.10 开发 influxdb cluster（和 influxdb enterprise 方案基本相同），预计3月份完成，上述问题都能更好地解决

1. 同时停掉proxy的话，业务会中断的-_-||
2. 目前的强需求功能就是需要分measurement，降低series维度

[hw2499]

这个influx-proxy如果能支持热部署就完美了，比如通过API去重新加载proxy.json中的配置内容以实现同步最新配置。

[chengshiwen]

1. 同时停掉proxy的话，业务会中断的-_-||
2. 目前的强需求功能就是需要分measurement，降低series维度

这个influx-proxy如果能支持热部署就完美了，比如通过API去重新加载proxy.json中的配置内容以实现同步最新配置。

@slzheng2017 @hw2499 最近推动下热部署

[hw2499]

1. 同时停掉proxy的话，业务会中断的-_-||
2. 目前的强需求功能就是需要分measurement，降低series维度

这个influx-proxy如果能支持热部署就完美了，比如通过API去重新加载proxy.json中的配置内容以实现同步最新配置。

@slzheng2017 @hw2499 最近推动下热部署

强，发布后，我会第一时间体验。

[chengshiwen]

@slzheng2017 @hw2499 目前最新dev分支的 f04604e 已经支持 配置文件热加载 hot-reloading，只要修改配置文件就会自动加载，也不用通过 api 去调用重新加载，因为这个版本加了 互斥锁，涉及到大量逻辑，以及性能和线程安全的平衡，我目前做了测试暂时没有发现问题，可能还需要一段时间观察，稳定后发版 v2.6.0 版本，欢迎多测试

[slzheng2017]

@slzheng2017 @hw2499 目前最新dev分支的 f04604e 已经支持 配置文件热加载 hot-reloading，只要修改配置文件就会自动加载，也不用通过 api 去调用重新加载，因为这个版本加了 互斥锁，涉及到大量逻辑，以及性能和线程安全的平衡，我目前做了测试暂时没有发现问题，可能还需要一段时间观察，稳定后发版 v2.6.0 版本，欢迎多测试

ok，之后看看先。
看这段描述，有个疑问。这个设计：只要修改配置文件就会自动加载，也不用通过 api 去调用重新加载
个人总觉得，保险一点的做法，应该是修改完配置文件后，通过 api 调用去重新加载，不知道少掉这一步，做成自动化加载的初衷是什么？

[chengshiwen]

之前的想法是减少一步操作、提升体验，曾经比较过调用 /reload 接口 和自动加载文件，现在评估了下，做成 api 接口会更好些

[chengshiwen]

dev 分支 5218646 目前已经调整为调用 /reload 接口来手动重载配置，目前有以下几个配置项是无法在运行期间修改的：
listen_addr, idle_timeout, https_enabled, https_cert, https_key

[slzheng2017]

嗯嗯，只是个人感觉/reload这样更保险，哈哈

[hw2499]

dev 分支 5218646 目前已经调整为调用 /reload 接口来手动重载配置，目前有以下几个配置项是无法在运行期间修改的： listen_addr, idle_timeout, https_enabled, https_cert, https_key

这个分支是否已经编译好并release出来了?有个细节想沟通下，我现在有A,B两台influxdb服务器，正在写10000条数据，当写到5000条数据时，我修改了配置文件增加了C服务器，并调用了reload进行加载热部署，此时C服务器是不是从第5001条记录开始写入新的数据呢？关于这个新部署，我感觉应该是在每次向服务器批写入时去读缓存中的目标服务器列表（flush_size应该是批更新所以有机会去读缓存服务器列表，reload这个api就是实时去更新这个服务器列表），有哪些服务器列表就去写哪些，这样就不用担心listen_addr是否修改的问题了。

[chengshiwen]

这个分支是否已经编译好并release出来了?

目前没有release，我先提供 2.6.0-preview 版本

• influx-proxy-2.6.0-preview-darwin-amd64.tar.gz
• influx-proxy-2.6.0-preview-darwin-arm64.tar.gz
• influx-proxy-2.6.0-preview-linux-amd64.tar.gz
• influx-proxy-2.6.0-preview-linux-arm64.tar.gz
• influx-proxy-2.6.0-preview-windows-amd64.tar.gz

第二个问题

influx-proxy 修改完配置 reload 后，根据新配置创建了新的若干 backend 实例（用于请求实际的 influxdb 数据、重写等），之前老的的 backend 实例会完成数据 flush 后才会关闭销毁。所以这个问题，是可以理解为第 5001 条数据会写到新的 backend 里，但实际情况下，是以写入到 buffer 的界线为准，reload 会开新的 buffer

缓存中的目标服务器

没用缓存的这个方案，使用的读写锁来解决，老的 backend 实例 flush 完之前的 buffer 就销毁掉。backend 实例要做实际 influxdb 请求(查询/写入)、文件缓存、重写等，所以缓存目标服务器的方案，相对 backend 整个能力来讲，是小头，用不用缓存都可以，主要还是解决整个能力的正常重新加载

listen_addr

listen_addr 是 influx-proxy 监听的接口，因为 influx-proxy 已经启动，现在还没办法修改它监听的端口

[slzheng2017]

在我个人的理解中，reload功能并没有解决在线扩容的问题：
假设集群为：一个influx-proxy + circle-0（2节点） + circle-1（2节点）
现在需要对circle-0扩容，即增加一个节点
目前的方式是：

1. 增加一个influxdb（并建好库），并在influx-proxy配置文件中增加新的节点：new-node
2. 执行reload，热加载配置文件
3. 写请求，会把数据写入到new-node（如果数据正好hash到该节点的话）

问题在于：
当读请求到来时，他也许会从circle-0中读取数据，那么只会读到circle-0的new-node节点上的部分数据（比如：count、sum、select 所有数据，这些情况），导致数据不准确

所以我的想法是：

1. 修改所有influx-proxy的配置文件（如果有多个influx-proxy的话）：增加circle-0节点
2. 修改所有的influx-proxy配置文件，配置文件中增加writeonly= true：标识circle-0只写（新增配置项，但writeonly属性原本在influx-proxy中就有）
3. 执行reload
   以上操作后，可以保证读操作会从circle-1中读取数据
4. 执行rebalance，对circle-0进行数据迁移
5. rebalance完成后会自动将writeonly属性置为false

以上方案，是基于有2个集群的高可用的情况下进行的，利用了circle-1在扩容变更阶段的完整性

类似的，重复上述步骤，对cirlce-1进行扩容

作者看下，这种在线扩容方案有没有问题

[chengshiwen]

@slzheng2017 /reload 只是做了 重载 的事情，上述提到的思路是对的，没有问题，而且 write_only 配置是支持的（在 backends 的每个 influxdb 实例级别上），因此上述提到的扩缩容方案是支持的