docker容器重启后数据意外丢失

[jqlin2019]

过程是这样的:我把TuGraph和一个dfs文件系统部署在一台机器上，用TuGraph做文件信息管理，当时有测过一些文件上传，数据库没有问题；后来测试的时候有一些视频转流和解码存储的操作，可能有大量io和cpu消耗，当时发现一些非主键或数据量较大的节点扫描命令在TuGraph阻塞住了，最多时可能有20，30条阻塞，就进行了TuGraph容器重启。第二天进行测试的时候发现保存视频信息节点的结束时间endTime字段为空，80%该类节点的endTime值都丢失了 这是当时的机器负载情况

丢失属性的节点写入cypher是merge (n0:video{id:12451}) set n0+={id:12451 ,start_time:'2023-10-23 10:12:58',end_time:'2023-10-23 10:15:06'} merge (n1:video{id:12452}) set n1+={id:12452 ,start_time:'2023-10-23 10:12:58',end_time:'2023-10-23 10:15:06'}，当时执行成功了，但是重启后部分end_time为Null，其他字段正常

docker版本是tugraph-runtime-centos7:3.5.0,已经做了存储挂载。服务器系统是Ubuntu 18.04.5 LTS

[knightast]

这里出错的数据只涉及正要修改的数据，或者说数据没写进去，还是80%的数据中有大量的误伤。

TuGraph的行存，感觉应该不会误伤。以及这个能复现么

[jqlin2019]

这里出错的数据只涉及正要修改的数据，或者说数据没写进去，还是80%的数据中有大量的误伤。

TuGraph的行存，感觉应该不会误伤。以及这个能复现么

找到了当时的IO监控数据，使用iotop查看到的情况是 Total DISK READ: 2M/s | Total DISK WRITE: 90M/s Actual DISK READ 3M/s | Total DISK WRITE: 100M/s

主要的负载被视频写入的业务占用了，lgraph_server的进程占据了读取的前4个； 请问这种IO高负载的情况有办法吗，能不能用尽量少的IO给到TuGraph来完成读写，另外一块核心业务暂时改不了，后续会尽量把服务器分开

[qishipengqsp]

综合看了一下，主要是2个方面的问题： 1、持久化/数据不一致的问题。这里需要再多一些信息 （1）启动时候durable参数和optimistic_txn有做单独设置么？是默认值么？ （2）关于发现不一致的现象。重启前是正常的么？”重启后发现end_time为null，其他字段正常“是说（比如）更新了2个字段，重启后字段A正确，字段B不正确是么？

2、IO的问题 tugraph-db底层是single writer的，启动的时候有一个thread_limit配置可以限制整体的线程数目，即限制读的线程数目。但是一般来说这种情况，应该是平衡一下主要的负载业务，即视频写入业务。

[jqlin2019]

综合看了一下，主要是2个方面的问题： 1、持久化/数据不一致的问题。这里需要再多一些信息 （1）启动时候durable参数和optimistic_txn有做单独设置么？是默认值么？ （2）关于发现不一致的现象。重启前是正常的么？”重启后发现end_time为null，其他字段正常“是说（比如）更新了2个字段，重启后字段A正确，字段B不正确是么？

2、IO的问题 tugraph-db底层是single writer的，启动的时候有一个thread_limit配置可以限制整体的线程数目，即限制读的线程数目。但是一般来说这种情况，应该是平衡一下主要的负载业务，即视频写入业务。

durable参数和optimistic_txn是默认值，conf配置用的是默认的/usr/local/etc/lgraph.json:

{
    "directory" : "/var/lib/lgraph/data",
    "license" : "/var/lib/lgraph/fma.lic",
    "host" : "0.0.0.0",
    "port" : 7070,
    "rpc_port" : 9090,
    "enable_rpc" : true,
    "enable_ha" : false,
    "verbose" : 1,
    "log_dir" : "/var/log/lgraph_log",
    "disable_auth" : false,
    "ssl_auth" : false,
    "server_key" : "/usr/local/etc/lgraph/server-key.pem",
    "server_cert" : "/usr/local/etc/lgraph/server-cert.pem",
    "web" : "/usr/local/share/lgraph/resource"
}

docker-compose的配置如下：

version: '3'
services:
  tugraph:
    restart: always
    image: tugraph-runtime-centos7:3.5.0
    container_name: tugraph-database-3.5.0
    volumes:
      - ./lgraph_data:/var/lib/lgraph/data
      - ./lgraph_log:/var/log/lgraph_log
    ports:
      - 7070:7070
      - 9090:9090
    command: "lgraph_server"

关于重启前字段是否完整的情况，因为当时的日志用了merge写入且没有打印具体返回，重启后是对上游的数据进行检查对比的，一般写入是多个字段都不为null时才进行业务写入，以业务节点Video为例，有id,start_time,end_time三个字段，之前遇到过整个节点未写入，被其他关系绑定上的空节点，查询时只有id存在，start_time和end_time字段都为空； 这次数据异常是重启后发现end_time为null，start_time字段正常保留，是业务不允许的写入情况，所以很迷惑，符合您假设的情况。 这些和docker或者服务器配置有关吗，感觉和重启的因素比较大，最近还会测试几轮，看看能不能再复现一下

[qishipengqsp]

看您的docker将数据目录挂出来了，不太会和配置有关系。请您复现的时候，注意一下几个点吧，帮助做更多的判断。

• merge语句执行成功与否，关注一下返回结果。
• 重启前数据和重启后的对比。如果是重启前后数据不一致，那有可能是WAL(Write Ahead Log)存在问题
• 最后一个可能性是merge语句有问题，您先复现一下排除其他情况，后面我找cypher同学来看看

[jqlin2019]

看您的docker将数据目录挂出来了，不太会和配置有关系。请您复现的时候，注意一下几个点吧，帮助做更多的判断。

• merge语句执行成功与否，关注一下返回结果。
• 重启前数据和重启后的对比。如果是重启前后数据不一致，那有可能是WAL(Write Ahead Log)存在问题
• 最后一个可能性是merge语句有问题，您先复现一下排除其他情况，后面我找cypher同学来看看

merge语句的问题有相关的复现了，相关节点schema和merge命令如下

call db.getVertexSchema("StatisticData")

{"label":"StatisticData","primary":"id","properties":[{"index":true,"name":"id","optional":false,"type":"INT64","unique":true},{"index":false,"name":"relate_id","optional":true,"type":"INT64"},{"index":false,"name":"counter","optional":true,"type":"INT64"},{"index":false,"name":"type","optional":true,"type":"INT64"},{"index":false,"name":"output_name","optional":true,"type":"STRING"},{"index":false,"name":"uuid","optional":true,"type":"STRING"},{"index":false,"name":"program","optional":true,"type":"STRING"},{"index":false,"name":"algo_name","optional":true,"type":"STRING"}],"type":"VERTEX"}

merge (n0:StatisticData{id:61480}) set n0+={output_name:"FX11",uuid:"",id:61480,counter:1,relate_id:1074}
......
merge (n0:StatisticData{id:61480}) set n0+={algo_name:"FX11(1)",program:"",type:1,id:61480,counter:1}

异常的字段为counter，期望返回值是1，当时的查询结果为0 数据库没有进行重启，之后重新运行merge命令，又能够正常进行修改和回显 同一批的StatisticData节点都有类似的情况，counter查询结果为0，但写入记录大于0

[jqlin2019]

补充一下当时和数据库相关的操作：发生过一次机器迁移，把/var/lib/lgraph/data目录下的数据打包迁移到了重装的新系统，docker和系统配置不变； 现在临时的解决办法是把counter字段删了重建 @qishipengqsp

[qishipengqsp]

我们尝试复现一下