NebulaGraph使用docker-compose部署方式如何备份还原
原创NebulaGraph使用docker-compose部署方式如何备份还原
原创
### 一、前言
之前的备份管理参考官网文档只实现了单机的备份，未能实现docker-compose部署方式的备份还原操作，实在睡不着啊，有道是垂死病中惊坐起，今天晚必须搞定他。。。。
额，搞定了，天也快亮了。
### 二、备份and还原
#### 2.1、agent部署问题以及解决
由于agent部署需要在每个节点安装，但是docker-compose方式部署，只有一台机器，我们先尝试部署一个agent测试是否可行。
# 下载Agent
wget https://github.com/vesoft-inc/nebula-agent/releases/download/v3.6.1/agent-3.6.1-linux-amd64
# 重命名并放入系统PATH,放入系统PATh后可以直接执行命令，不用./
sudo mv agent-3.6.1-linux-amd64 /usr/local/bin/agent
# 赋权755，使用br命令可以正常使用
sudo chmod 755 /usr/local/bin/agent
# 查看meta服务启动后转发出来的端口,我这边是49161 49159 49158三个端口
docker-compose ps 由于之前踩过坑了，详见上一篇文章，所以我们要知道agent注册的host要和meta服务的host一致，否则无法进行备份会报错提示没有agent,那么我们先去看一下meta服务注册后的host是什么。
# 连接服务
sudo nebula-console -addr 127.0.0.1 -port 9669 -u root -p password
# 我们可以看到，有三个meta服务，host分别是metad0 metad1 metad2
所以我们注册agent的时候要使用主机metad0这个名称，有一些linux基础的朋友就知道了，我们要去修改/etc/hosts这个文件了
# 修改hosts文件
sudo vim /etc/hosts
# 内容如下
127.0.0.1 localhost metad0 metad1 metad2
# 启动Agent
sudo nohup agent --agent="metad0:8888" --meta="metad0:49161" > nebula\_agent.log 2>&1 &
# 查看agent的进程是否正常
# 连接服务，查看agent是否正常注册
sudo nebula-console -addr 127.0.0.1 -port 9669 -u root -p password
show hosts agent;
坑一：翻车了啊，兄弟们，agent没有成功注册
不要慌，有坑填坑就完事了，我们去查看一下agent的日志
通过日志我们可以发现以下几点线索
1、第一次连接端口49161成功了
2、尝试去连接metad1的9559端口失败
3、没有尝试连接metad2节点的9559端口
通过以往的各种被坑经验，我判断存报错存在以下两种可能性
1、agent需要连接所有meta节点，连接meta0后读取到了其他meta节点的信息，尝试连接，失败了
2、agent需要连接meta集群节点中的leader，我链接的metad0不是leader
由于报错只连接了meta1失败，没有尝试连接metad2，所以第2种的可能性大一点，我们修改agent的启动参数，连接metad1去启动agent，端口号49159，记得先杀掉之前的agent
# 启动Agent
sudo nohup agent --agent="metad1:8888" --meta="metad1:49159" > nebula\_agent.log 2>&1 &
# 连接服务，查看agent是否正常注册
sudo nebula-console -addr 127.0.0.1 -port 9669 -u root -p password
show hosts agent;
ok，搞定了，agent服务正常注册了，注册名称也是我们所期望的metad1
#### 2.2、备份
安装br工具，尝试进行备份
# 下载br
wget https://github.com/vesoft-inc/nebula-br/releases/download/v3.5.0/br-3.5.0-linux-amd64
# 重命名并放入系统PATH,放入系统PATh后可以直接执行命令，不用./
sudo mv br-3.5.0-linux-amd64 /usr/local/bin/br
# 赋权755，使用br命令可以正常使用
sudo chmod 755 /usr/local/bin/br
# 查看版本
br version安装完毕
# 备份
sudo br backup full --meta "metad1:49159" --storage "local:///opt/NebulaGraph"**坑二**：兄弟们双翻车，报错Error: parse cluster response failed: response is not successful, code is E_LIST_CLUSTER_NO_AGENT_FAILURE
多么熟悉的报错，应该是缺少两个agent导致的，现在问题卡在哪呢，9559是容器端口，转发出来以后就不是了，正因如此才能实现在一台服务器启动3个agent而没有端口冲突的问题，我们如果要启动三个agent会导致第2,3两个agent无法正常连接meta集群的leader（从坑一可以发现，所有agent想要正常启动都要连接leader才行，但是我们要模拟注册metad0和metad2，只能链接这两个节点才能正常给三个meta注册agent进行备份操作）
在死了无数脑细胞后，发现一个思路我们可以用四层代理，将服务器9559端口转发到leader节点的49159
nginx安装就不写了，不水内容，浪费大家时间，nginx配置文件如下
server {
listen 9559;
proxy\_pass 127.0.0.1:49159;
}配置文件主要含义就是有三个服务metad0，metad1，metad2都监听同一个端口9559，分别转发后边的meta服务，由于服务名不一样，所以并不会存在端口冲突。
我们启动agent0和agent2
# 启动Agent0
# 注意修改8888端口为8887
sudo nohup agent --agent="metad0:8887" --meta="metad0:49161" > nebula\_agent0.log 2>&1 &
# 启动Agent2
# 注意修改8888端口为8889
sudo nohup agent --agent="metad2:8889" --meta="metad2:49158" > nebula\_agent2.log 2>&1 &
# 连接服务，查看agent是否正常注册
sudo nebula-console -addr 127.0.0.1 -port 9669 -u root -p password
show hosts agent;
再次尝试备份
# 备份
sudo br backup full --meta "metad1:49159" --storage "local:///opt/NebulaGraph"
**坑3**：。。。叒报错了，还是熟悉的报错
这次痛定思痛，仔细翻看官方文档，最终确定agent不是每个meta节点要部署，是所有节点，查看storaged和graph节点的host，启动对应节点的agent
#启动agent
sudo nohup agent --agent="storaged0:8890" --meta="metad1:49159" > nebula\_agent3.log 2>&1 &
sudo nohup agent --agent="storaged1:8891" --meta="metad1:49159" > nebula\_agent4.log 2>&1 &
sudo nohup agent --agent="storaged2:8892" --meta="metad1:49159" > nebula\_agent5.log 2>&1 &
sudo nohup agent --agent="graphd:8893" --meta="metad1:49159" > nebula\_agent6.log 2>&1 &
sudo nohup agent --agent="graphd1:8894" --meta="metad1:49159" > nebula\_agent7.log 2>&1 &
sudo nohup agent --agent="graphd2:8895" --meta="metad1:49159" > nebula\_agent8.log 2>&1 &
# 查看节点注册
再次备份
# 备份
sudo br backup full --meta "metad1:49159" --storage "local:///opt/NebulaGraph"**坑四**：坏消息继续报错，好消息报错变了
继续分析报错， service metad1:49159 not found，这个报错应该是集群内其他服务连接 metad1:49159失败，由于集群是容器启动，会将metad1解析到对应的容器IP，而容器IP又没监听49159这个端口，所以失败，我们已经通过nginx转发了这个端口到9559，所以我们使用9559端口进行备份
# 备份
sudo br backup full --meta "metad1:9559" --storage "local:///opt/NebulaGraph"**坑五**：报错继续中，报错有一次发生了变化
分析：报错中的路径应该是容器中存储数据的路径，容器外无非访问导致，但是容器化部署单机多节点又无法将所有文件通过挂载的方式挂到物理主机，因为重名文件。
没办法了，直接将容器中放入agent，使agent在容器中运行，就可以读到文件了。删除现有集群以及agent然后重新安装集群（此部分内容不写了，没意义）
需要注意的是新集群启动之前，要修改docker-compose.yaml将备份路径挂载到容器内,同时增加hostname配置（一处小坑，不单独再写了）
# 每个容器添加一下内容
volumes:
- /opt/NebulaGraph:/opt/NebulaGraph
# hostname配置
services:
metad0:
hostname: metad0
# 注意，以上配置是所有服务都需要加，只列举一个集群启动以后复制agent到容器内
# 复制agent
sudo docker cp /usr/local/bin/agent nebula-docker-compose-release-36-graphd-1:/usr/local/bin/agent
sudo docker cp /usr/local/bin/agent nebula-docker-compose-release-36-graphd1-1:/usr/local/bin/agent
sudo docker cp /usr/local/bin/agent nebula-docker-compose-release-36-graphd2-1:/usr/local/bin/agent
sudo docker cp /usr/local/bin/agent nebula-docker-compose-release-36-storaged0-1:/usr/local/bin/agent
sudo docker cp /usr/local/bin/agent nebula-docker-compose-release-36-storaged1-1:/usr/local/bin/agent
sudo docker cp /usr/local/bin/agent nebula-docker-compose-release-36-storaged2-1:/usr/local/bin/agent
sudo docker cp /usr/local/bin/agent nebula-docker-compose-release-36-metad0-1:/usr/local/bin/agent
sudo docker cp /usr/local/bin/agent nebula-docker-compose-release-36-metad1-1:/usr/local/bin/agent
sudo docker cp /usr/local/bin/agent nebula-docker-compose-release-36-metad2-1:/usr/local/bin/agent
# 启动agent
# 流程说明，进入容器，启动agent，退出容器
# 重复此操作，保证每个容器都启动了agent，注意修改参数
docker exec -it nebula-docker-compose-release-36-graphd-1 bash
nohup agent --agent="graphd:8888" --meta="metad1:9559" > nebula\_agent.log 2>&1 &
exit
# 全部启动完成后，查看agent注册情况
需要注意，重新部署后leader节点发生变化，通过agent日志确认leader节点，修改nginx配置指向leader节点
再再再再次备份
# 备份
# 直接使用nginx代理后的9559端口
sudo br backup full --meta "metad1:9559" --storage "local:///opt/NebulaGraph"
**坑6**：无语。。。不过看报错，很简单，宿主机br工具，无法连接agent导致，一不做二不休，我们把br工具也放到容器内。。。然后再容器内进行备份
# 复制br工具
sudo docker cp /usr/local/bin/br nebula-docker-compose-release-36-metad0-1:/usr/local/bin/br
# 进入容器内
docker exec -it nebula-docker-compose-release-36-metad0-1 bash
# 备份
br backup full --meta "metad1:9559" --storage "local:///opt/NebulaGraph"
终于成了，由于我们已经将/opt/NebulaGraph在容器中做了挂载，所以我们宿主机也是有这个备份的。
查看备份
#### 2.3、还原
这个就比较简单了，基于以上遇到过的坑，我们要进入容器内进行还原操作，同时我们备份目录/opt/NebulaGraph是挂载到所有容器内的，避免了复制备份文件的麻烦
# 进入容器内
docker exec -it nebula-docker-compose-release-36-metad0-1 bash
# 恢复数据
br restore full --meta "127.0.0.1:9559" --storage "local:///opt/NebulaGraph" --name BACKUP\_2023\_12\_05\_14\_59\_41
正常还原，成功，睡觉，呃呃呃我先写个总结。。。。
### 三、总结
整体来说不顺利，意料之外的坑很多，最终解决的办法也不理想（太晚了，时间不够了，只能临时解决）。
所有遇到的坑，都在正文中写了，不在最后重复写了，一些特殊的地方单独和大家说一下。
**重点1**：为什么用nginx代理，而不是直接修改docker-compose.yaml的配置，把端口映射出来？
因为无法确定那个meta会是主节点，nginx可以在服务启动后确定那个是主节点后调整配置。
**重点2**：解决问题的思路。
通过查看官方文档，分析备份恢复的逻辑；通过各种日志报错信息，分析报错原因；通过不断尝试，找出解决办法。
**重点3**：为什么这么备份我觉得不理想，理想的解决办法应该是什么
不理想的原因：1、我直接往容器中复制了agent和br，容器删除后重建，这一切都没有了，不符合容器化部署的理念。
理想的方式：写dockerfile，重做镜像来实现上面的效果。
**想做，但是不做的事**：k8s部署的备份还原方式，想做因为没做过。不做的原因，已经分析出了备份的逻辑，只需要给每个pod注入一个agent容器就可以实现，但是太累了，所以就不再写k8s的备份恢复了，有兴趣的小伙伴自行尝试，有问题可以联系我。
**建议**：官方给出了这种部署方式，就顺便提供一下备份的方式吧，自己研究太累了。
**最后一句话：你不做你怎么知道你不行，Do it!**
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。