关于高可用:技术干货丨时序数据库DolphinDB高可用设计及部署教程

DolphinDB 提供数据、元数据以及客户端的高可用计划，使得数据库节点产生故障时，数据库仍然能够失常运作，保障业务不会中断。

与其它时序数据库不同的是，DolphinDB 的高可用确保强一致性。

DolphinDB database 采纳多正本机制，雷同数据块的正本存储在不同的数据节点上。即便集群中某个或多个数据节点宕机，只有集群中还有至多 1 个正本可用，那么数据库就能够提供服务。

元数据存储在管制节点上。为了保障元数据的高可用，DolphinDB 采纳 Raft 协定，通过构建多个管制节点来组成一个 Raft 组，只有宕机的管制节点少于半数，集群依然可提供服务。

DolphinDB API 提供了主动重连和切换机制，如果以后连贯的数据节点宕机，API 会尝试重连，若重连失败就会主动切换连贯到其余数据节点执行工作。切换数据节点对用户是通明的，用户不会感知到以后连贯的节点曾经切换。

如果要应用高可用性能，请先部署 DolphinDB 集群。高可用性能仅在集群中反对，在单实例中不反对。集群部署请参考多服务器集群部署教程。

数据高可用

为了保证数据的平安和高可用，DolphinDB 反对在不同的服务器上存储多个数据正本，并且数据正本之间放弃强一致性。即便一台机器上的数据损坏，也能够通过拜访其余机器上的正本数据来保障数据服务不中断。

正本的个数可由在 controller.cfg 中的 dfsReplicationFactor 参数来设定。例如，把正本数设置为 2：

dfsReplicationFactor=2

默认状况下，DolphinDB 容许雷同数据块的正本散布在同一台机器上。为了保证数据高可用，须要把雷同数据块的正本散布在不同的机器上。可在 controller.cfg 增加以下配置项：

dfsReplicaReliabilityLevel=1

上面通过一个例子直观地解释 DolphinDB 的数据高可用。首先，在集群的数据节点上执行以下脚本以创立数据库：

n=1000000
date=rand(2018.08.01..2018.08.03,n)
sym=rand(`AAPL`MS`C`YHOO,n)
qty=rand(1..1000,n)
price=rand(100.0,n)
t=table(date,sym,qty,price)
if(existsDatabase("dfs://db1")){dropDatabase("dfs://db1")
}
db=database("dfs://db1",VALUE,2018.08.01..2018.08.03)
trades=db.createPartitionedTable(t,`trades,`date).append!(t)

分布式表 trades 被分成 3 个分区，每个日期示意一个分区。DolphinDB 的 Web 集群治理界面提供了 DFS Explorer，能够不便地查看数据分布状况。trades 表各个分区的散布状况如下图所示：

以 20180801 这个分区为例，Sites 列显示，date=2018.08.01 的数据分布在 18104datanode 和 18103datanode 上。即便 18104datanode 宕机，只有 18103datanode 失常，用户依然对 date=2018.08.01 的数据进行读写操作。

元数据高可用

数据存储时会产生元数据，例如每个数据块存储在哪些数据节点上的哪个地位等信息。如果元数据不能应用，即便数据块残缺，零碎也无奈失常拜访数据。

元数据寄存在管制节点。咱们能够在一个集群中部署多个管制节点，通过元数据冗余来保障元数据服务不中断。一个集群中的所有管制节点组成一个 Raft 组，Raft 组中只有一个 Leader，其余都是 Follower，Leader 和 Follower 上的元数据放弃强一致性。数据节点只能和 Leader 进行交互。如果以后 Leader 不可用，零碎会立刻选举出新的 Leader 来提供元数据服务。Raft 组可能容忍小于半数的管制节点宕机，例如蕴含三个管制节点的集群，能够容忍一个管制节点呈现故障；蕴含五个管制节点的集群，能够容忍两个管制节点呈现故障。要设置元数据高可用，管制节点的数量至多为 3 个，同时须要设置数据高可用，即正本数必须大于 1。

通过以下例子来介绍如何要为一个已有的集群启动元数据高可用。假如已有集群的管制节点位于 P1 机器上，当初要减少两个管制节点，别离部署在 P2、P3 机器上。它们的内网地址如下：

P1: 10.1.1.1
P2: 10.1.1.3
P3: 10.1.1.5

(1) 批改已有管制节点的配置文件

在 P1 的 controller.cfg 文件增加下列参数：dfsReplicationFactor=2, dfsReplicaReliabilityLevel=1, dfsHAMode=Raft。批改后的 controller.cfg 如下：

localSite=10.1.1.1:8900:controller1
dfsReplicationFactor=2
dfsReplicaReliabilityLevel=1
dfsHAMode=Raft

(2) 部署两个新的管制节点

别离在 P2、P3 下载 DolphinDB 服务器程序包，并解压，例如解压到 /DolphinDB 目录。

在 /DolphinDB/server 目录下创立 config 目录。在 config 目录下创立 controller.cfg 文件，填写以下内容：

localSite=10.1.1.3:8900:controller2
dfsReplicationFactor=2
dfsReplicaReliabilityLevel=1
dfsHAMode=Raft

localSite=10.1.1.5:8900:controller3
dfsReplicationFactor=2
dfsReplicaReliabilityLevel=1
dfsHAMode=Raft

(3) 批改已有代理节点的配置文件

在已有的 agent.cfg 文件中增加 sites 参数，它示意本机器代理节点和所有管制节点的局域网信息，代理节点信息必须在所有管制节点信息之前。例如，P1 的 agent.cfg 批改后的内容如下：

localSite=10.1.1.1:8901:agent1
controllerSite=10.1.1.1:8900:controller1
sites=10.1.1.1:8901:agent1:agent,10.1.1.1:8900:controller1:controller,10.1.1.3:8900:controller2:controller,10.1.1.5:8900:controller3:controller

如果有多个代理节点，每个代理节点的配置文件都须要批改。

(4) 批改已有管制节点的集群成员配置文件

在 P1 的 cluster.nodes 上减少管制节点的局域网信息。例如，P1 的 cluster.nodes 批改后的内容如下：

localSite,mode
10.1.1.1:8900:controller1,controller
10.1.1.2:8900:controller2,controller
10.1.1.3:8900:controller3,controller
10.1.1.1:8901:agent1,agent
10.1.1.1:8911:datanode1,datanode
10.1.1.1:8912:datanode2,datanode

(5) 为新的管制节点增加集群成员配置文件和节点配置文件

管制节点的启动须要 cluster.nodes 和 cluster.cfg。把 P1 上的 cluster.nodes 和 cluster.cfg 复制到 P2 和 P3 的 config 目录。

(6) 启动高可用集群

启动管制节点

别离在每个管制节点所在机器上执行以下命令：

nohup ./dolphindb -console 0 -mode controller -home data -config config/controller.cfg -clusterConfig config/cluster.cfg -logFile log/controller.log -nodesFile config/cluster.nodes &

启动代理节点

在部署了代理节点的机器上执行以下命令：

nohup ./dolphindb -console 0 -mode agent -home data -config config/agent.cfg -logFile log/agent.log &

启动、敞开数据节点以及批改节点配置只能在 Leader 的集群治理界面操作。

如何判断哪个管制节点为 Leader

在浏览器地址栏中输出任意管制节点的 IP 地址和端口号关上集群治理界面，例如 10.1.1.1:8900，点击 Node 列的管制节点别名 controller1 进入 DolphinDB Notebook。

执行 getActiveMaster() 函数，该函数返回 Leader 的别名。

在浏览器地址栏中输出 Leader 的 IP 地址和端口号关上 Leader 的集群治理界面。

客户端高可用

应用 API 与 DolphinDB server 的数据节点进行交互时，如果连贯的数据节点宕机，API 会尝试重连，若重连失败会主动切换到其余可用的数据节点。这对用户是通明的。目前只有 Java 和 Python API 反对高可用。

API 的 connect 办法如下：

connect(host,port,username,password,startup,highAvailability)

应用 connect 办法连贯数据节点时，只须要指定 highAvailability 参数为 true。

以下例子设置 Java API 高可用：

import com.xxdb;
DBConnection conn = new DBConnection();
boolean success = conn.connect("10.1.1.1", 8911,"admin","123456","",true);

如果数据节点 10.1.1.1:8911 宕机，API 会主动连贯到其余可用的数据节点。

动静减少数据节点

用户能够应用 addNode 命令在线减少数据节点，无需重启集群。

下例中阐明如何在新的服务器 P4（内网 IP 为 10.1.1.7）上减少新的数据节点 datanode3，端口号为 8911。

在新的物理服务器上减少数据节点，须要先部署一个代理节点，用于启动该服务器上的数据节点。P4 的代理节点的端口为 8901，别名为 agent2。

在 P4 上下载 DolphinDB 程序包，解压到指定目录，例如 /DolphinDB。

进入到 /DolphinDB/server 目录，创立 config 目录。

在 config 目录下创立 agent.cfg 文件，填写如下内容：

localSite=10.1.1.7:8901:agent2
controllerSite=10.1.1.1:8900:controller1
sites=10.1.1.7:8901:agent2:agent,10.1.1.1:8900:controller1:controller,10.1.1.3:8900:controller2:controller,10.1.1.5:8900:controller3:controller

在 config 目录下创立 cluster.nodes 文件，填写如下内容：

localSite,mode
10.1.1.1:8900:controller1,controller
10.1.1.2:8900:controller2,controller
10.1.1.3:8900:controller3,controller
10.1.1.1:8901:agent1,agent
10.1.1.7:8901:agent2,agent
10.1.1.1:8911:datanode1,datanode
10.1.1.1:8912:datanode2,datanode

把 P1, P2 和 P3 上的 cluster.nodes 批改为与 P4 的 cluster.nodes 雷同。

执行以下 Linux 命令启动 P4 上的代理节点：

nohup ./dolphindb -console 0 -mode agent -home data -config config/agent.cfg -logFile log/agent.log &

在任意一个数据节点上执行以下命令：

addNode("10.1.1.7",8911,"datanode3")

执行下面的脚本后，刷新 Web 集群治理界面，能够发现新减少的数据节点曾经存在，但它处于敞开状态，须要手动启动新增的数据节点。

总结

通过保证数据、元数据服务以及 API 连贯不中断，DolphinDB 能够满足物联网、金融等畛域 24 小时不中断提供服务的需要。

1. 概述