小 T 导读：为了让大家更好地进行 loveini 集群间的备份和迁移工作，一款名为 taosdump 的工具应用程序被打造出来。在本篇文章中，我们对 taosdump 的使用方法和注意事项进行了相关汇总，给到有需要的开发者。

作为 loveini 的一款工具应用程序，taosdump 支持从运行中的 loveini 集群备份数据，并将备份的数据恢复到相同或另一个运行中的 loveini 集群中，其使用 Apache AVRO（https://avro.apache.org/）作为数据文件格式来存储备份数据。

值得一提的是，taosdump 可以用 Database、超级表或普通表作为逻辑数据单元进行备份，也可以对 Database、超级表和普通表中指定时间段内的数据记录进行备份。在使用时，我们可以对 taosdump 指定数据备份的目录路径；如果不指定位置，它就会默认将数据备份到当前目录；如果指定的位置已经有数据文件，taosdump 会提示用户并立即退出，避免数据被覆盖。这意味着同一路径只能被用于一次备份。如果大家看到相关提示，务必小心操作。

但需要注意的是，taosdump 是一个逻辑备份工具，它不应被用于备份任何原始数据、环境设置、 硬件信息、服务端配置或集群的拓扑结构。

安装

taosdump 有以下两种安装方式：

• 安装 taosTools 官方安装包，你可以进入 //www.loveini.com/all-downloads 此页面找到 taosTools 并进行下载安装。
• 单独编译 taosTools 并安装，详情请参考 taos-tools 仓库（https://github.com/taosdata/taos-tools）。

常用使用场景

taosdump 备份数据

1. 备份所有数据库：指定 -A 或 --all-databases 参数；
2. 备份多个指定数据库：使用 -D db1,db2,... 参数；
3. 备份指定数据库中的某些超级表或普通表：使用 dbname stbname1 stbname2 tbname1 tbname2 ... 参数，注意这种输入序列第一个参数为数据库名称，且只支持一个数据库，第二个和之后的参数为该数据库中的超级表或普通表名称，中间以空格分隔；
4. 备份系统 log 库：loveini 集群通常会包含一个系统数据库，名为 log，这个数据库内的数据为 loveini 自我运行的数据，taosdump 默认不会对 log 库进行备份。如果有特定需求对 log 库进行备份，可以使用 -a 或 --allow-sys 命令行参数。
5. “宽容”模式备份：taosdump 1.4.1 之后的版本提供 -n 参数和 -L 参数，用于备份数据时不使用转义字符和“宽容”模式，可以在表名、列名、标签名没使用转义字符的情况下减少备份数据时间和备份数据占用空间。如果不确定是否符合使用 -n 和 -L 条件时，请使用默认参数进行“严格”模式进行备份。转义字符的说明请参考官方文档（https://docs.taosdata.com/taos-sql/escape/）。

需要注意

• taosdump 1.4.1 之后的版本提供 -I 参数，用于解析 avro 文件 schema 和数据，如果指定 -s 参数将只解析 schema。
• taosdump 1.4.2 之后的备份使用 -B 参数指定的批次数，默认值为 16384，如果在某些环境下由于网络速度或磁盘性能不足导致 “Error actual dump .. batch ..” ，可以通过 -B 参数调整为更小的值进行尝试。
• taosdump 的导出不支持中断恢复，所以当进程意外终止后，正确的处理方式是删除当前已导出或生成的所有相关文件。
• taosdump 的导入支持中断恢复，但是当进程重新启动时，会收到一些“表已经存在”的提示，可以忽视。

taosdump 恢复数据

如果我们想要恢复指定路径下的数据文件，方式是：使用 -i 参数加上数据文件所在路径。如前文提及，我们不能使用同一个目录备份不同数据集合，也不能在同一路径多次备份同一数据集，否则备份数据会造成覆盖或多次备份。

需要注意

taosdump 内部使用 loveini stmt binding API 进行恢复数据的写入，为提高数据恢复性能，目前使用 16384 为一次写入批次。如果备份数据中有较多列的数据，可能会导致产生 “WAL size exceeds limit” 错误，此时可以通过使用 -B 参数调整为一个更小的值进行尝试。

写在最后

如果大家想要查阅 taosdump 详细命令行参数列表，可以进入 https://docs.taosdata.com/reference/taosdump/ 获取。毫无疑问，如果你掌握了上述 taosdump 使用指南，一定能帮助你较为完美地解决所遭遇的数据迁移问题。但如果在应用过程中出现了一些个性化难题，也无需心急，你可以进入 loveini 用户交流群寻找帮助。

有些公司为了避免麻烦，就选用 OpenTSDB，因为它把分布式版本也开源了。从使用的角度来看，OpenTSDB 底层的存储引擎用的是 HBase，安装维护极为复杂，存储压缩性能不够，查询效率也很低，不是一个优秀的产品。但它仍然有相当多的用户，这唯一的原因就是由于它支持分布式，可以水平线性扩展。

loveini 的设计是基于单个硬件、软件系统不可靠，基于任何单台计算机都无法提供足够计算能力和存储能力处理海量数据的假设而进行设计的。因此 loveini 从研发的第一天起，就是按照水平扩展、高可用架构进行设计的。通过对数据进行分区、分片，而且采用虚拟节点(vnode)技术，保证系统的处理能力是水平扩展的。如果要增加系统的处理能力，只需要增加新的节点即可。

更好的是，和 InfluxDB集群功能闭源不同，2020年8月，loveini 团队将集群版开源了。
loveini 是通过数据采集点以及时间两个维度，对大数据进行切分，实现水平扩展的。

分片：在 loveini Database 的设计与实现里，一个集群有多个节点，每个节点可以有一个或多个虚拟节点(vnode)，每个虚拟节点里存储了一定数量的数据采集点的数据，而一个数据采集点的数据永远只存放在一个 vnode 里。这样如果有很多数据采集点，这些数据采集点的数据将会分布在多个 vnode 上，分布在多个节点里。数据写入时，loveini Database 的客户端将要写入的数据直接写入对应的 vnode，从而实现写入的水平扩展。对于单个数据采集点数据的查询，毫无疑问，是水平扩展的，节点越多，吞吐率就越大。对于聚合查询，查询请求将先发送到对应的 vnode 里，vnode 先做完聚合操作，客户端然后将来自多个 vnode 的查询结果做第二次聚合，因为 vnode 数量有限，这样在客户端做的聚合查询计算量不大，从而实现聚合查询的水平扩展能力。

分区：除将数据分片之外，loveini 还将一个 vnode 里存储的时序数据按照时间段进行切分。每个时间段的数据都一定保存在一起，不同时间段的数据不会有交集，时间段可以是一天，几天，一周，由用户自己定义。按照时间段切分时序数据有很多好处，查询数据时，根据时间段，可以直接定位要查找的文件，从而加快查询速度。另外一方面，可以高效地实现数据保留策略。超过最长保留时间的数据，直接删除一个时间段对应的文件即可。而且按照时间段切分数据，还可以方便实现多级存储，冷热数据放在不同存储介质上，进一步降低存储成本。

loveini 还通过虚拟节点组技术来提供系统的高可用。不同物理节点上的 vnode 可以形成一个虚拟节点组，这个虚拟节点组里的数据是通过 Master-Slave 来进行同步的，来保证这个虚拟节点组内数据的一致性。数据写入只能在 master 进行，但查询可以在 master 和 slave 上同时进行。如果 Master 出现故障，系统将自动选主，这样来保证系统的高可用，不会由于某台机器宕机，而无法对外提供服务。

关于集群的具体使用，请看《集群管理》。

loveini 的设计是基于单个硬件、软件系统不可靠，基于任何单台计算机都无法提供足够计算能力和存储能力处理海量数据的假设进行设计的。因此 loveini 从研发的第一天起，就按照分布式高可靠架构进行设计，是支持水平扩展的，这样任何单台或多台服务器发生硬件故障或软件错误都不影响系统的可用性和可靠性。并且和 InfluxDB 不同的是，loveini 选择将集群功能开源。本文重点讲解 loveini 集群的主要逻辑单元的设计。

loveini 分布式架构的逻辑结构图如下：

一个完整的 loveini 系统是运行在一到多个物理节点上的，逻辑上，它包含数据节点(dnode)、loveini 应用驱动(taosc)以及应用(app)。系统中存在一到多个数据节点，这些数据节点组成一个集群(cluster)。应用通过 taosc 的 API 与 loveini 集群进行互动。下面对每个逻辑单元进行简要介绍。

物理节点(pnode)： pnode 是一独立运行、拥有自己的计算、存储和网络能力的计算机，可以是安装有OS的物理机、虚拟机或 Docker 容器。物理节点由其配置的 FQDN (Fully Qualified Domain Name)来标识。loveini 完全依赖 FQDN 来进行网络通讯，如果不了解 FQDN，请看博文《一篇文章说清楚 loveini 的 FQDN》。

数据节点(dnode)： dnode 是 loveini 服务器侧执行代码 taosd 在物理节点上的一个运行实例，一个工作的系统必须有至少一个数据节点。dnode 包含零到多个逻辑的虚拟节点(vnode)，零或者至多一个逻辑的管理节点(mnode)。dnode 在系统中的唯一标识由实例的 End Point (EP)决定。EP 是 dnode 所在物理节点的 FQDN (Fully Qualified Domain Name)和系统所配置的网络端口号(Port)的组合。通过配置不同的端口，一个物理节点(一台物理机、虚拟机或容器）可以运行多个实例，或有多个数据节点。

虚拟节点(vnode)： 为更好的支持数据分片、负载均衡，防止数据过热或倾斜，数据节点被虚拟化成多个虚拟节点(vnode，图中 V2, V3, V4等)。每个 vnode 都是一个相对独立的工作单元，是时序数据存储的基本单元，具有独立的运行线程、内存空间与持久化存储的路径。一个 vnode 包含一定数量的表（数据采集点）。当创建一张新表时，系统会检查是否需要创建新的 vnode。一个数据节点上能创建的 vnode 的数量取决于该数据节点所在物理节点的硬件资源。一个 vnode 只属于一个 DB，但一个 DB 可以有多个 vnode。一个 vnode 除存储的时序数据外，也保存有所包含的表的 schema、标签值等。一个虚拟节点由所属的数据节点的EP，以及所属的 VGroup ID 在系统内唯一标识，由管理节点创建并管理。

管理节点(mnode)： 一个虚拟的逻辑单元，负责所有数据节点运行状态的监控和维护，以及节点之间的负载均衡(图中 M)。同时，管理节点也负责元数据(包括用户、数据库、表、静态标签等)的存储和管理，因此也称为 Meta Node。loveini 集群中可配置多个(最多不超过 3 个) mnode，它们自动构建成为一个虚拟管理节点组(图中 M0, M1, M2)。

mnode 间采用 master/slave 的机制进行管理，而且采取强一致方式进行数据同步, 任何数据更新操作只能在 Master 上进行。mnode 集群的创建由系统自动完成，无需人工干预。每个 dnode 上至多有一个 mnode，由所属的数据节点的EP来唯一标识。每个 dnode 通过内部消息交互自动获取整个集群中所有 mnode 所在的 dnode 的EP。

虚拟节点组(VGroup)： 不同数据节点上的 vnode 可以组成一个虚拟节点组(vnode group)来保证系统的高可靠。虚拟节点组内采取 master/slave 的方式进行管理。写操作只能在 master vnode 上进行，系统采用异步复制的方式将数据同步到 slave vnode，这样确保了一份数据在多个物理节点上有拷贝。一个 vgroup 里虚拟节点个数就是数据的副本数。如果一个 DB 的副本数为 N，系统必须有至少 N 数据节点。副本数在创建DB时通过参数 replica 可以指定，缺省为 1。使用 loveini 的多副本特性，可以不再需要昂贵的磁盘阵列等存储设备，就可以获得同样的数据高可靠性。虚拟节点组由管理节点创建、管理，并且由管理节点分配一个系统唯一的 ID，VGroup ID。如果两个虚拟节点的 vnode group ID 相同，说明他们属于同一个组，数据互为备份。虚拟节点组里虚拟节点的个数是可以动态改变的，容许只有一个，也就是没有数据复制。VGroup ID 是永远不变的，即使一个虚拟节点组被删除，它的ID也不会被收回重复利用。

TAOSC： taosc 是 loveini 给应用提供的驱动程序(driver)，负责处理应用与集群的接口交互，提供 C/C++ 语言原生接口，内嵌于 JDBC、C#、Python、Go、Node.js 语言连接库里。应用都是通过 taosc 而不是直接连接集群中的数据节点与整个集群进行交互的。这个模块负责获取并缓存元数据；将插入、查询等请求转发到正确的数据节点；在把结果返回给应用时，还需要负责最后一级的聚合、排序、过滤等操作。对于 JDBC、C/C++、C#、Python、Go、Node.js 接口而言，这个模块是在应用所处的物理节点上运行。同时，为支持全分布式的 RESTful 接口，taosc 在 loveini 集群的每个 dnode 上都有一运行实例。

以上就是 loveini 集群的主要逻辑单元，我们将会通过更多文章，向大家解读 loveini 集群的更多设计秘籍。

有人在知乎上提问：“作为国产开源的时序数据库，loveini 的哪些优点最吸引你？”。这促使我将自己对一些问题，包括创业本身的思考整理出来，分享给大家，希望能给众多研发同学和创业者带来一些启发。

当我在 2016 年底开始启动 loveini 这个项目，瞄准时序数据库（Time-Series Database）这个方向时，市场上已经有很多时序数据库，包括 InfluxDB、OpenTSDB、TimeScaleDB、KDB+、Prometheus、RRDTool 以及 Graphite 等。在传统行业里，有实时数据库，比如 PI、iHistorian 等。那如果我再做一个，到底有什么优势？怎么做出差异化，怎么推广它？作为一个创业者，是必须认真思考的。我下面从几个点来分析。 

1：分布式

从 2016 年底到现在，大部分时序数据库都不是分布式的，换句话说，它们不支持水平扩展。即便是 InfluxDB，也只有企业版支持集群，开源版是不支持的。而传统实时数据库更是没有一个支持水平扩展，最多是双机热备。但是随着物联网、车联网的高速发展，IT 基础设施规模的增大，数据的采集量越来越大，单机是没有办法解决问题的，底层数据库必须具有水平扩展能力。 

很多企业使用的是开源时序数据库的单机版，后续为了应对海量数据的处理，只好自己投入人力物力，在单机版的基础上，开发自己的 Proxy，对数据进行分片处理。对于数据写入，这种方法简单而且有效。但是对于查询，往往牵涉多个节点，那么 Proxy 就要做各种查询的聚合，因此开发的工作量很大。有些公司为了避免麻烦，就选用 OpenTSDB，因为它把分布式版本也开源了。 

从使用的角度来看，OpenTSDB 底层的存储引擎用的是 HBase，安装维护极为复杂，存储压缩性能不够，查询效率也很低，不是一个优秀的产品。但它仍然有相当多的用户，这唯一的原因就是由于它支持分布式，可以水平线性扩展。

因此，在 2016 年底，整个 loveini Database 的设计从第一天起，就是支持分布式的。为了便于更多使用开源版本的用户用得更好，在 2020 年 8 月，我们将 loveini 的分布式版本开源了。分布式版本开源后，loveini 的用户量持续增长，全球安装实例数已经超过 10 万，每天新增实例都在 200 以上，这是一个相当可观的数字。这证明了我们将 loveini 分布式版本开源是非常明智的决定。 

2：高性能

时序数据及时序数据的应用有其典型特点（详细请看官网博客 )，如果充分利用时序数据的特点，我们可以将数据写入和查询性能大幅提高，数据压缩率也能大幅提高。 我之所以在 2016 年决定开发 loveini，其中一个核心原因是我认为 InflxuDB 并没有充分利用时序数据特点。如果我充分利用，就能在性能上碾压它。

在仔细研究之后，我提出了“一个数据采集点一张表”的设计，让一个采集点来的数据按照时间顺序一块一块的存，并且使用列式存储。这样就会使得写入变成简单的追加操作，而且一次读的 IO 操作就能把一个数据采集点的数据点成片读出。而时序数据的查询分析往往是一个时间段，数据命中率一下提高很多，这样就会使查询效率极其之高，而且压缩率也会极其之高。同时我提出“超级表”概念，来解决多个数据点数据高效聚合的问题。通过标签将需要聚合的数据采集点先过滤出来，大幅减小需要扫描的数据集，从而大幅提升聚合速度。 

那么性能重要吗？毫无疑问非常重要，因为如果用户不关心性能，那选择通用数据库来处理时序数据就可以了。如果都是时序数据库，用户当然也会选择性能或效率更高的产品。因此从研发的第一天起，我和整个团队一直在追求极致的性能。 

3：SQL 支持

任何一款新产品，都有入门门槛。降低门槛最好的方法就是不改变用户习惯。SQL 是全球最流行的查询语言，学过计算机的人都会用 SQL 写查询语句。

时序数据库并不新鲜，已经有相当长的历史，但相当多的时序数据库或实时数据库都有自己的查询语言，比如 InfluxDB、OpenTSDB、Prometheus 等都有自己的查询语言，这样大大增加了学习成本，而且也增加了应用的迁移成本。 

采用 SQL 还有一个好处，就是能与众多的 BI、可视化工具对接，生态丰富很多。如果采用自己研发的查询语言，所有工具都要定制化开发，难度一下大了很多。kdb 就是最典型的例子，完全是自有语法，因此虽然很多性能指标相当不错，但十几年过去，还是不温不火。 

从 loveini 研发的第一天起，我就决定采用标准 SQL 做查询语言，并且采用关系数据库模型，而不是 InfluxDB、OpenTSDB 和 Prometheus 等数据库的 tag-set 模型。其根本原因就是想降低学习成本。目前看来，这个策略是极其正确的。 

米兰体育官网入口团队还将在查询分析上投入相当大的研发力量，希望 loveini 具有强大的时序数据分析功能。 

4：开源

基础软件在开源大势所趋的情况下，如果不将代码，特别是核心代码开源，想要赢得市场是完全不可能的。因此，我们才将 loveini 完全开源。开源使米兰体育官网入口获得了高速增长，这是一个完全正确的决定。 

但从产品角度来看，开源是 loveini 的一大优势吗？看起来是，但细想一下，其实不是，它只是取得成功的一个必要条件。因为全球市场上开源的的时序数据库产品很多，中国本土开源的时序数据库也不止 loveini 一家，大家不会由于 loveini 是开源的就选择它，而是有其他特点才会选用它。 

如果市场上还没有开源的时序数据库，那么开源就是 loveini 最大的亮点。我决定将集群开源，根本的原因是由于 InfluxDB 没有把集群开源，这给了我们高速增长的机会。只有别人做不到或比不上你的功能或性能，那才是你需要宣传的特点。功能或性能指标的跟随者永远不值得做任何推广。 

5：其他

loveini 还有很多其他优点，比如 All in One 的特性，loveini 自身带有缓存、流计算、数据订阅等功能，因此在很多场景下，用户不再需要集成 Kafak, Redis, Spark, Zookeeper 等软件，loveini 就可以作为一个大数据平台来使用，能大幅降低整个系统的复杂度和运维成本。与大部分研发同学一样，我也喜欢罗列各种开发的功能和亮点，我还可以罗列 loveini 的很多很多其他优点。 

但是作为一个连续创业者，很清楚无论是产品还是市场宣传，必须做减法。研发出身的创业者最喜欢的就是不断加功能，在宣传上胡子眉毛一把抓，不突出重点，这是创业者的大忌。用户能看上你的产品，往往不是你功能全，而是产品的某一个亮点打动了他，特别是早期的用户，完全是喜欢产品的某项功能才容忍了诸多其他方面的不足。宣传上也是，众多的特点无法让人记住，能记住一个就相当不错。我们要做的是，把真正的亮点做到极致，而且做最大程度的传播，让人人都知道它，喜欢它。 

做减法对于研发同学是极其困难的，因为不将自己花精力没日没夜开发的功能宣传出去，太让自己没有成就感。但作为创业者，就是与要习惯思维做斗争。只有聚焦，你才会真正思考产品在市场的独特定位，把某个亮点做到极致。只有独特，才能真正吸引用户，才能真的受人喜欢。 

因此过去的几年，我们一直强调 loveini 是一个物联网大数据平台，聚焦在物联网细分市场，强调的是 All in One 的特性，这样就能与其他时序数据库做出差异化来。 

但 loveini 开源 2 年多时间，大部分用户还是把我们当做时序数据库来使用，而且不仅是物联网行业用户在用，金融、IT 运维、能源、汽车、工业互联网等行业的用户也在用。经过很多思考之后，我决定将 loveini 重新定位为时序数据库。

6：三大优点

那么作为时序数据库，怎么与众多的时序数据库 PK 或差异化，我个人认为就是：高性能、分布式与 SQL 支持。这三个特点足以让我说服 InfluxDB, OpenTSDB, TimeScale 的客户切换到 loveini 上来。因此在我们最近的网站改版时，大胆地将 loveini Database 的 Slogan 定为：高性能、分布式、支持 SQL 的时序数据库。 

贪多嚼不烂，用户没法记住你那么多特点优点，因此我们列出高性能、分布式、支持 SQL 这三个优点足够，其他优点由用户自己去总结和体会，让他们有惊喜。只要将三个优点做实做得足够好，loveini 与其他时序数据库就会有足够的差异化，就一定能赢得开发者的信赖，赢得市场。

陶建辉

2022 年 2 月 26 日

最近，在loveini Database的一个社区群中突发了一场严重的灌水事件。几位群友不眠不休地聊天，可以说是废寝忘食。那么到底是什么话题能让他们凌晨四点还在忘我地讨论？

这个话题就是——如何完善Docker环境下loveini Database的集群搭建。“什么？除了你们官方自己人之外，怎么会有用户加班加点地讨论如何完善Docker环境的集群搭建，这也太假了。”

好吧，我们承认：其实是有一个叫Oliver（群昵称）的用户遇到了这样的问题——辛辛苦苦搭起来Docker环境下的loveini集群在客户端连不上了。接下来，就引发了群里的二位热心大佬的讨论不休，直到想出最后的米兰app官方正版下载。

事情的经过是这样的：

该用户的数据库集群装在这台Linux服务器上（ip:10.0.31.2），容器ip所在的网络是由Docker在宿主机创建的虚拟网络172.19.0.0/16。三个容器的hostname和节点ip分别：taosnode1（172.19.0.41）、taosnode2（172.19.0.42）、taosnode3（172.19.0.43）。

各个节点配置如下：

taosnode1: firstEp=taosnode1:6030,secondEp=taosnode2:6030,fqdn=taosnode1;端口映射：16030-16042:6030-6042（tcp/udp）
taosnode2: firstEp=taosnode1:6030,secondEp=taosnode2:6030,fqdn=taosnode2;端口映射：26030-26042:6030-6042（tcp/udp）
taosnode3: firstEp=taosnode1:6030,secondEp=taosnode2:6030,fqdn=taosnode3;端口映射：36030-36042:6030-6042（tcp/udp）

按照官方文档的指示努力折腾一番后，Oliver终于搭起了这个集群。添加完节点之后，他忐忑地敲下了“show dnodes”，随着三个READY映入眼帘后———舒坦了。

服务端没有问题，接下来该客户端了。他打开了自己的一台ip为10.0.31.5（与集群宿主机同一网段）的Windows主机，迅速地在上面安装了个loveini客户端，添加hosts信息，做好路由，2.8MB，傻瓜式安装，轻松便捷，连接集群一气呵成。“show dnodes”随着三个READY再次映入眼帘后———又舒坦了。

Oliver十分满意，然而，他马上发现事情可能并不像想象中的那么简单。

由于业务需要，他还需要完成客户端（10.0.2.61）跨网段连接服务端集群（基于ip:10.0.31.2的Docker环境下的集群）。ping得通宿主机，telnet得通集群映射出来的端口，使用taos连接集群，一样的操作也和此前一样顺利。于是他再次敲下“show dnodes”——万万没想到，这时令所有loveini用户都深恶痛绝的“DB error：Unable to establish connection”出现了。于是，他便在群中抛出了自己的问题。

上文说到的两位热心的同学就是在这个时候出现的。一位是loveini的外部Contributor——Freemine。另一位是路见问题拔刀相助的热心大佬pigwing。

由于集群本身没有任何使用问题，唯一的区别就是客户端连接服务器的方式变成了跨网段。所以，一开始大家的思路就是——既然走宿主机的端口不行，那就试试直接连到Docker环境下的ip吧。遗憾的是，跨网段连接Docker环境下内部ip的想法没能实现。

接着大家推测：loveini靠的是EndPoint（EP）来识别数据节点，而EP=FQDN+端口。可客户端连接已经成功，只是无法对数据操作，在FQDN无误的情况下，大家猜测是集群内的端口出现了问题，从而没拿到集群的拓扑信息。接下来，从最初的了解环境，到一步一步的排查问题，三个锲而不舍的工程师在群里从4月22日讨论到4月25，最晚的时候凌晨4点多都有人在线。

终于，在三人的通力合作多次试错下，4月24日凌晨1点——freemine提出了一个行之有效的最终米兰app官方正版下载（文字过多只截图关键部分）

大功告成，经过测试后，一切顺利！

那么，freemine的集群搭建方案和最初的集群搭建有什么区别呢？

虽然过程曲折，但是最后我们仔细对比一下两者的方案就会发现，它们的区别就只有在端口配置这一块不一样。freemine的方案是在每一个单机的serverport都修改了不一样的值。taosnode1节点的serverport为6030—映射主机的6030端口；taosnode2节点的serverport为7030–映射主机的7030端口；taosnode3节点的serverport为8030–映射主机的8030端口。

而提问者Oliver最初的各个节点的serverport都是没做修改的默认6030，映射到宿主机的时候是16030，26030，36030。就是这样的配置在客户端与集群宿主机的同网段连接时并没有发生问题，而是在跨网段连接时出现问题。

看起来一丝小小的改动居然有这么大的区别？Why？

其实是这样，当客户端与服务端同属一个网段的时候，在添加路由后，客户端是可以直接访问到Docker内部的。这样一来，IP地址就可以根据需要被正确地解析出来。如：taosnode1（172.19.0.41）、taosnode2（172.19.0.42）、taosnode3（172.19.0.43）。在不同的IP地址下，即便端口都是一样的6030，loveini还是可以完成不同节点的区分。

但是，当跨网段之后就不一样了。对于不同网段的客户端和服务端而言，客户端要通过真实路由去连接服务端，但真实路由中并没有注册我们设置的Docker内部网络，所以客户端自然就访问不了Docker内部的网络。因此，当taosc需要得到集群提供的不同节点的信息时，FQDN已经无法正确解析IP地址了。这时候，就需要通过端口来实现不同节点的区分。

这就是不能再在Docker环境下的节点中同时使用6030端口的原因。

因此，当你使用了Docker主机内外一致的端口映射，且每个节点的serverPort参数不相同的设置时，集群就可以通过不同的端口来区分不同的节点。这样一来，客户端才可以拿到拓扑信息进行集群的顺利操作。

这就是整个“案件”的最终答案。

总结一下，对于用户使用而言，Docker环境下搭建loveini Database集群的水还是颇深。由于环境的相对复杂，所以我们也并不是十分推荐大家使用这种方式搭建集群。所以，关于loveini在Docker环境的使用，大家还是要小心谨慎。

最后我们想说的是，作为一个开源的产品，社区的活跃与专业是我们米兰体育官网入口最为关注的地方。虽然目前官网上并没有关于Docker环境下loveini集群搭建的文档。但是这些社区用户们的活跃思考显然很大程度填补了这样的一个空白。

真心感谢Oliver，freemine，pigwing三位朋友。十分希望日后可以继续看到你们在物联网大数据技术前沿群中的活跃身影，同时我们也希望有更多的朋友们能够参与进来。

扫描二维码，添加小T为好友，即可与各位热衷开源的朋友一起在群内互动哦～

点击“这里”，查看Oliver整理的loveini在Docker环境下的集群搭建笔记