发现版本

opengauss 3.0.2

问题概述

gs_basebackup方式备份，恢复时报错page of relation not exist

复现步骤

1. 创建表并插入数据
# create table test(id int) with (compresstype=2,compress_chunk_size=512);
# insert into test select generate_series(1,60000000); 

– 2900W一个段文件，产生三个段文件

2. 删除数组，使第二、第三个段文件页面为空

# delete from test where id > 25000000; 

3. 任意操作

# create table test2(id int);
# insert into test2 select generate_series(1,10000);
# delete from test2 where id > 5000;
# drop table test2;

4. 实际vacuum产生truncate，确保页面产生truncate
   例如：INFO: vacuum 1663/15563/16533, “test”: removed 1445886 row versions in 6398 pages(dn_6001_6002_6003_6004 pid=85118)

# vacuum verbose test;

5. 预置数据，确保备机已经回放结束

# insert into test select generate_series(25000001,30000000);
# create index on test(id);

6. 通过gs_ctl query查看receiver_replay_location，需要和sender_replay_location相等

7. 发起备份，同时作数据插入或者修改

gs_basebackup

主机同时操作：

# update test set id = id +1 where id = 30000000;

8. 备份结束后，启动备机：以主机方式启动，此时预期报错：一个页面not exists

问题原因

从备份数据来看，相关页面没有备份导致。备份数据从备机产生，分析备机数据发现：相关文件的nblocks为0，导致备份工具没有备份任何数据，这个层面看，备份工具功能无异常，需要分析为何备机的相关文件nblocks为0
备机：通过gs_ctl build产生，生成的nblocks正常不为0，考虑是回放过程中nblocks修改为0后没有累加导致
nblocks修改逻辑：truncate置0，mdextend累加。
分析发现：在回放过程中，查询文件大小时返回的是truncate前的nblocks数量，返回逻辑是smgrcache中已经缓存的smgr的缓存数据，考虑是缓存失效没有通知到其他线程导致。

解决方案

升级到3.0.5版本