从 L0 快照中写入 DB 大小的 LTX,覆盖所有层级

<! -- -- 请提供尽可能多的细节,帮助我们复制和解决这个问题 -- -- "

□ 错误描述

进入每个目的地级别的第一个收缩会从TXID 1重新压缩整个TXID历史——包括一个DB大小的基座快照——所以一个新复制的数据库会被重写并重新满载,每收缩级别一次. 在大型数据库中,每个都有一个O(数据库大小)读取了+合并+上传,未能利用依赖L9快照的增益.

在哪里发生

指挥官。 Contracting's choice's source round from the ** Destination** level's high-water mark: 简约选择其来源范围从目的地 高水分高度的:

开始 //压缩器.go prevMaxInfo, 错误 : = c. MaxLTX FileInfo( ctx, dstlevel) // dstlevel 最大值 求取TXID := prevMaxInfo. MaxTXID + 1 / = 1 当dst为空时. itr, 错误 := c. client.LTX Files(ctx, srclevel, 搜索TXID, 假)

当目标级别为空时, `prevMaxInfo' 。 MaxTXID = 0',所以"SeekTXID = 1"和收缩从TXID 1上拉出每个源级文件——在新一代上,从DB大小的底片快照L0. 因此,由此产生的L1文件跨越`[1..N]',本身是DB大小。 当L2首次收缩时,它从TXID 1(又一个DB大小)中取出L1 → L2 `.M';然后同样取出L3。 基地向上传播整个阶梯,每个关卡有一个完整的DB重写.

□ 环境

** 流版:**
<! -- -- -- 下面的行号来自当前主干线(v0.5.17-1-g4ed7a30). -- >
页:1
主页 @ v0.5.17-1-g4ed7a30

** 操作系统 & 版本: ** Linux (容器), arm64 ** 安装方法:** 从源头建造 ** 后端:** S3 兼容(在任何后端上复制;成本为读取+并出+负载,每级为整个DB)

□ 步骤重现

1. 从空复制一个大型数据库(ours is ~65 GB),因此基础快照L0是DB大小.
2. 将DB保持在平稳的写入负载下,这样递增的L0文件会累积.
3. 监视远程商店(或进行中的多段上传)。 由于每个梯级(L1,然后是L2,然后是L3)首先被覆盖,因此观测到一个DB大小的物体,其键跨为"MinTXID=1"——即该基被重写为该等.

** 预期:** 递增梯子紧凑,仅指最新快照之上的递增。 DB大小的碱基被写出一回(到快照关卡),再也没有再被再现实化为L1/L2/L3. 每层收缩成本为O(新数据),而非O(数据库大小).

** 实际:** 每个关卡的第一个收缩重读/再写/再装入整个数据库(从TXID 1中扩展出),因为一个空的目的地从TXID 1中求取.

□ 证据

从 1~65 GB 生成(对象密钥=QQ level >/-.ltx',以字节表示大小):

页:1

Base capture — 在 TXID 1 上写了两次的 DB( 0级和快照级):

0000/000000000000000000000000000000000000000001.ltx 65,390,548,046#基础快照 L0 (~60.9 GiB) 0009/00000000000000000000000000000000000001.ltx 65,390,548,046#快照级别,大小相同.

然后每个梯子级别第一

. . . . . . .