2.6版本milvus使用Woodpecker时数据持久性的问题

[zhongshanhao]

milvus2.6版本只支持Woodpecker MemoryBuffer模式部署。该模式将日志写入缓存在内存中，并周期性地刷入对象存储这种情况下。

q：会存在单点故障，如果单节点挂了，会丢数据吧？

QuorumBuffer模式：数据会同步写入 3 个节点中的任意两个即可认为写入成功（quorum），常在几毫秒内完成，并异步持久化到云存储。

q：这种情况也没办法保证数据的持久性？比如客户端写入后，服务端返回成功了，因为Woodpecker是异步持久化的，所有Woodpecker节点同时挂掉，期间的数据也丢掉了？

[zhongshanhao]

我是看官方文档产生了疑问，官方文档说：

看架构，数据是先写到streamingnode，然后会周期同步到object storage中，这样MemoryBuffer下，其中一个streaming node挂掉，内存中的未写到object storage的数据就丢掉了？

如果是QuorumBuffer的话，会有容错，因为做了多副本。但是MemoryBuffer没看到有多副本的介绍。

@yhmo 大佬求解答

[tinswzy]

memory buffer、quorum buffer这里的”buffer“ 确实会让人有误解。其实只是表示它在整体架构中 主要承担的功能是 暂存一段WAL日志，最终wal都会写到objectstorage上面的。
对于memorybuffer来说，他是攒批内存，但是并不会立刻ack给返回，只有真正写入 对象存储了，它才会ack给客户端。简单来说，这分数据持久化到 minio/s3, 客户端才会收到成功返回。也就是你的client只要收到ack成功，那就已经是确认完成数据flush到对象存储持久化了，挂不挂这个节点都不影响。
对于quorumbuffer来说，它实际上是三副本 本地盘的形式作为WAL的临时”buffer“，写三个节点也是sync持久化到磁盘才会ack返回给你成功的结果，即使它们挂了重启也不影响数据已经落盘了。除非2个块盘都坏了，但这概率显然非常低，而且云上的盘已经不同于传统物理硬盘，单块盘的损坏概率很小。比如gp3可能达到11个9的持久性。

[zhongshanhao]

大佬牛逼，理解了

[tinswzy]

其实你问题的关键是 不了解他是什么时候给你 ack的，这两种模式都是确保落盘了才会给你ack的，这是大前提。

[tinswzy]

你的request是同步请求写sn，虽然异步flush，但是对于你的单个request来说，你是同步等待的。所以你一个request一个request 地顺序请求的时候都是固定毫秒数以上的延时（minio 200ms,localfs 10ms）。

如果你并发多个request写sn，那么它们就可以在一个时间内中尽可能攒成1批，一起刷落盘才分别ack返回的。这也是为什么memorybuffer的时候，单个client同步写的延时会高一点，如果想吞吐高那就并发请求多个。这种模式对 吞吐友好、对 成本友好。