图数据库设计实践 | 存储服务的负载均衡和数据迁移
在文章《Nebula 架构剖析系列（一）图数据库的存储设计》中，咱们提过度布式图存储的管理由 Meta Service 来统一调度，它记录了全部 partition 的分布状况，以及当前机器的状态。当 DBA 增减机器时，只须要经过 console 输入相应的指令，Meta Service 便可以生成整个 Balance 计划并执行。而之因此没有采用彻底自动 Balance 的方式，主要是为了减小数据搬迁对于线上服务的影响，Balance 的时机由用户本身控制。git
在本文中咱们将着重讲解在存储层如何实现数据和服务的负载平衡。github
简单回顾一下，Nebula Graph 的服务可分为 graph，storage，meta。本文主要描述对于存储层（storage）的数据和服务的 balance。这些都是经过 Balance 命令来实现的：Balance 命令有两种，一种须要迁移数据，命令为 BALANCE DATA ；另外一种不须要迁移数据，只改变 partition 的 raft-leader 分布（负载均衡），命令为 BALANCE LEADER 。shell
本文目录
- Balance 机制浅析
- 集群数据迁移
- Step 1：准备工做
- Step 1.1 查看现有集群状态
- Step 1.2 建立图空间
- Step 2 加入新实例
- Step 3 迁移数据
- Step 4 假如要中途中止 balance data
- Step 5 查看数据迁移结果
- Step 6 Balance leader
- Step 1：准备工做
- 批量缩容
- 示例数据迁移
Balance 机制浅析
在图数据库 Nebula Graph 中， Balance 主要用来 balance leader 和 partition，只涉及 leader 和 partition 在机器之间转移，不会增长或者减小 leader 和 partition 的数量。数据库
上线新机器并启动相应的 Nebula 服务后，storage 会自动向 meta 注册。Meta 会计算出一个新的 partition 分布，而后经过 remove partition和 add partition 逐步将数据从老机器搬迁到新的机器上。这个过程所对应的命令是 BALANCE DATA ，一般数据搬迁是个比较漫长的过程。bash
但 BALANCE DATA 仅改变了数据和副本在机器之间的均衡分布，leader（和对应的负载） 是不会改变的，所以还须要经过命令BALANCE LEADER来实现负载的均衡。这个过程也是经过 meta 实现的。架构
集群数据迁移
如下举例说明 BALANCE DATA 的使用方式。本例将从 3 个实例（进程）扩展到 8 个实例（进程）：负载均衡
Step 1：准备工做
部署一个 3 副本的集群，1个 graphd，1个 metad，3 个 storaged（具体部署方式请参考集群部署文：https://zhuanlan.zhihu.com/p/80335605），经过 SHOW HOSTS 命令能够看到集群的状态信息：分布式
Step 1.1 查看现有集群状态
按照集群部署文档部署好 3 副本集群以后，用 SHOW HOSTS 命令查看下如今集群状况：spa
nebula> SHOW HOSTS ================================================================================================ | Ip | Port | Status | Leader count | Leader distribution | Partition distribution | ================================================================================================ | 192.168.8.210 | 34600 | online | 0 | No valid partition | No valid partition | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34700 | online | 0 | No valid partition | No valid partition | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34500 | online | 0 | No valid partition | No valid partition | ------------------------------------------------------------------------------------------------ Got 3 rows (Time spent: 5886/6835 us)
SHOW HOSTS 返回结果解释：设计
- IP，Port 表示当前的 storage 实例。这个集群启动了 3 个 storaged 服务，而且尚未任何数据。(192.168.8.210:34600，192.168.8.210:34700，192.168.8.210:34500)
- Status 表示当前实例的状态，目前有 online/offline 两种。当机器下线之后（metad 在一段间隔内收不到其心跳），将把其更改成 offline。 这个时间间隔能够在启动 metad 的时候经过设置
expired_threshold_sec来修改，当前默认值是 10 分钟。 - Leader count：表示当前实例 Raft leader 数目。
- Leader distribution：表示当前 leader 在每一个 space 上的分布，目前还没有建立任何 space。( space 能够理解为一个独立的数据空间，相似 MySQL 的 Database）
- Partition distribution：不一样 space 中 partition 的数目。
能够看到 Leader distribution 和 Partition distribution 暂时都没有数据。
Step 1.2 建立图空间
建立一个名为 test 的图空间，包含 100 个 partition，每一个 partition 有 3 个副本。
nebula> CREATE SPACE test (PARTITION_NUM=100, REPLICA_FACTOR=3)
片刻后，使用 SHOW HOSTS 命令显示集群的分布。
nebula> SHOW HOSTS ================================================================================================ | Ip | Port | Status | Leader count | Leader distribution | Partition distribution | ================================================================================================ | 192.168.8.210 | 34600 | online | 0 | test: 0 | test: 100 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34700 | online | 52 | test: 52 | test: 100 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34500 | online | 48 | test: 48 | test: 100 | ------------------------------------------------------------------------------------------------
如上，建立包含 100 个 partitio_n 和 3 个 replica 图空间以后，3 个实例的_Leader distribution 和 _Partition distribution _有了对应的数值，对应的 _Partition distribution_都为 100。固然，这样的 learder 分布还不均匀。
Step 2 加入新实例
启动 5 个新 storaged 实例进行扩容。启动完毕后，使用 SHOW HOSTS 命令查看新的状态：
nebula> SHOW HOSTS ================================================================================================ | Ip | Port | Status | Leader count | Leader distribution | Partition distribution | ================================================================================================ | 192.168.8.210 | 34600 | online | 0 | test: 0 | test: 100 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34900 | online | 0 | No valid partition | No valid partition | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 35940 | online | 0 | No valid partition | No valid partition | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34920 | online | 0 | No valid partition | No valid partition | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 44920 | online | 0 | No valid partition | No valid partition | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34700 | online | 52 | test: 52 | test: 100 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34500 | online | 48 | test: 48 | test: 100 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34800 | online | 0 | No valid partition | No valid partition | ------------------------------------------------------------------------------------------------
上新实例以后，集群由原来 3 个实例变成了 8 个实例。上图数据库 icon 为蓝色的图示为新增的 5 个实例，此时因为仅仅加入了集群，新实例的状态为 Online，但此时_Leader distribution_ 和 Partition distribution 并无数值，说明还不会参与服务。
Step 3 迁移数据
运行 BALANCE DATA 命令。
nebula> BALANCE DATA ============== | ID | ============== | 1570761786 | --------------
若是当前集群有新机器加入，则会生成一个新的计划 ID。对于已经平衡的集群，重复运行 BALANCE DATA 不会有任何新操做。若是当前有正在执行的计划，那会显示当前计划的 ID。
也可经过 BALANCE DATA $id 查看这个 balance 的具体执行进度。
nebula> BALANCE DATA 1570761786 =============================================================================== | balanceId, spaceId:partId, src->dst | status | =============================================================================== | [1570761786, 1:1, 192.168.8.210:34600->192.168.8.210:44920] | succeeded | ------------------------------------------------------------------------------- | [1570761786, 1:1, 192.168.8.210:34700->192.168.8.210:34920] | succeeded | ------------------------------------------------------------------------------- | [1570761786, 1:1, 192.168.8.210:34500->192.168.8.210:34800] | succeeded | ------------------------------------------------------------------------------- ...//这里省略一些。如下一行为例 ------------------------------------------------------------------------------- | [1570761786, 1:88, 192.168.8.210:34700->192.168.8.210:35940] | succeeded | ------------------------------------------------------------------------------- | Total:189, Succeeded:170, Failed:0, In Progress:19, Invalid:0 | 89.947090% | ------------------------------------------------------------------------------- Got 190 rows (Time spent: 5454/11095 us)
BALANCE DATA $id 返回结果说明：
- 第一列 balanceId，spaceId:partId，src->dst 表示一个具体的 balance task。<br /> 以
1570761786, 1:88, 192.168.8.210:34700->192.168.8.210:35940为例：- 1570761786 为 balance ID
- 1:88，1 表示当前的 spaceId（也就是 space test 的 ID），88 表示迁移的 partitionId
- 192.168.8.210:34700->192.168.8.210:35940，表示数据从 192.168.8.210:34700 搬迁至_192.168.8.210:35940_。而原先 192.168.8.210:34700 中的数据将会在迁移完成后再 GC 删除
- 第二列表示当前 task 的运行状态，有 4 种状态
- Succeeded：运行成功
- Failed：运行失败
- In progress：运行中
- Invalid：无效的 task
最后对全部 task 运行状态的统计，部分 partition 还没有完成迁移。
Step 4 假如要中途中止 balance data
BALANCE DATA STOP 命令用于中止已经开始执行的 balance data 计划。若是没有正在运行的 balance 计划，则会返回错误提示。若是有正在运行的 balance 计划，则会返回计划对应的 ID。
因为每一个 balance 计划对应若干个 balance task，
BALANCE DATA STOP不会中止已经开始执行的 balance task，只会取消后续的 task，已经开始的 task 将继续执行直至完成。
用户能够在 BALANCE DATA STOP 以后输入 BALANCE DATA $id 来查看已经中止的 balance 计划状态。
全部已经开始执行的 task 完成后，能够再次执行 BALANCE DATA，从新开始 balance。若是以前中止的计划中有失败的 task，则会继续执行以前的计划，若是以前中止的计划中全部 task 都成功了，则会新建一个 balance 计划并开始执行。
Step 5 查看数据迁移结果
大多数状况下，搬迁数据是个比较漫长的过程。可是搬迁过程不会影响已有服务。如今能够经过 SHOW HOSTS 查看运行后的 partition 分布。
nebula> SHOW HOSTS ================================================================================================ | Ip | Port | Status | Leader count | Leader distribution | Partition distribution | ================================================================================================ | 192.168.8.210 | 34600 | online | 3 | test: 3 | test: 37 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34900 | online | 0 | test: 0 | test: 38 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 35940 | online | 0 | test: 0 | test: 37 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34920 | online | 0 | test: 0 | test: 38 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 44920 | online | 0 | test: 0 | test: 38 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34700 | online | 35 | test: 35 | test: 37 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34500 | online | 24 | test: 24 | test: 37 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34800 | online | 38 | test: 38 | test: 38 | ------------------------------------------------------------------------------------------------ Got 8 rows (Time spent: 5074/6488 us)
_Partition distribution_相近，partition 总数 300 不变且 partition 已均衡的分布至各个实例。
若是有运行失败的 task，可再次运行 BALANCE DATA 命令进行修复。若是屡次运行仍没法修复，请与社区联系 GitHub。
Step 6 Balance leader
BALANCE DATA 仅能 balance partition，可是 leader 分布仍然不均衡，这意味着旧实例的服务较重，而新实例的服务能力未获得充分使用。运行 BALANCE LEADER 从新分布 Raft leader：
nebula> BALANCE LEADER
片刻后，使用 SHOW HOSTS 命令查看，此时 Raft leader 已均匀分布至全部的实例。
nebula> SHOW HOSTS ================================================================================================ | Ip | Port | Status | Leader count | Leader distribution | Partition distribution | ================================================================================================ | 192.168.8.210 | 34600 | online | 13 | test: 13 | test: 37 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34900 | online | 12 | test: 12 | test: 38 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 35940 | online | 12 | test: 12 | test: 37 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34920 | online | 12 | test: 12 | test: 38 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 44920 | online | 13 | test: 13 | test: 38 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34700 | online | 12 | test: 12 | test: 37 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34500 | online | 13 | test: 13 | test: 37 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34800 | online | 13 | test: 13 | test: 38 | ------------------------------------------------------------------------------------------------ Got 8 rows (Time spent: 5039/6346 us)
如上， BALANCE LEADER 成功执行后，新增的实例和原来的实例（对应上图 icon 蓝色和黑色图示）的 _Leader distribution_相近， 全部实例已均衡，此外，也能够看到 Balance 命令只涉及 leader 和 partition 在物理机器上的转移，并无增长或者减小 leader 和 partition。
批量缩容
Nebula Graph 支持指定须要下线的机器进行批量缩容。语法为 BALANCE DATA REMOVE $host_list，例如：BALANCE DATA REMOVE 192.168.0.1:50000,192.168.0.2:50000，将指定移除 192.168.0.1:50000，192.168.0.2:50000 两台机器。
若是移除指定机器后，不知足副本数要求（例如剩余机器数小于副本数），Nebula Graph 将拒绝本次 balance 请求，并返回相关错误码。
示例数据迁移
上面讲了如何从 3 个实例变成 8个实例的集群，若是你对上文有疑问，记得在本文的评论区留言哈。咱们如今看看上面迁移的过程，192.168.8.210:34600 这个实例的状态变化。
说明：有颜色为红色说明对应的数值发生变化，若是数值不变，则为黑色。
附录
最后是 Nebula 的 GitHub 地址，欢迎你们试用，有什么问题能够向咱们提 issue。GitHub 地址：https://github.com/vesoft-inc/nebula
- 1. 图数据库设计实践 | 存储服务的负载均衡和数据迁移
- 2. 【数据库】数据库负载均衡
- 3. nginx--负载均衡--数据库
- 4. 阿里云 云服务器+云数据库+负载均衡
- 5. 存储类服务集群的负载均衡与实战
- 6. zookeeper负载均衡和数据同步
- 7. 服务器负载均衡和客户端负载均衡
- 8. 【数据库】数据库负载均衡、读写分离技术
- 9. geoserver数据存储迁移
- 10. 服务器负载均衡
- 更多相关文章...
- • 移动设备 统计 - 浏览器信息
- • AJAX 数据库实例 - ASP 教程
- • TiDB 在摩拜单车在线数据业务的应用和实践
- • Flink 数据传输及反压详解
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 图数据库设计实践 | 存储服务的负载均衡和数据迁移
- 2. 【数据库】数据库负载均衡
- 3. nginx--负载均衡--数据库
- 4. 阿里云 云服务器+云数据库+负载均衡
- 5. 存储类服务集群的负载均衡与实战
- 6. zookeeper负载均衡和数据同步
- 7. 服务器负载均衡和客户端负载均衡
- 8. 【数据库】数据库负载均衡、读写分离技术
- 9. geoserver数据存储迁移
- 10. 服务器负载均衡