KingbaseES V8R6 集群运维案例-- sys_internal.init.*文件引起sys_basebackup失败

案例说明：

KingbaseES V8R6集群在执行‘repmgr standby clone’或sys_basebackup克隆备库时出现如下图相关sys_internal.init文件错误：

适用版本：

KingbaseES V8R6

二、pg_internal.init文件原理

如上图所示，此故障和pg_internal.init文件有关，下面介绍有关此文件的工作机制（摘自pg官方文档）。

pg_internal.init: 用于缓存系统表，加快系统表读取速度（每个用户创建的数据库目录下也有同名文件）。

 PostgreSQL中存在两种高速缓存：syscache和relcache。syscache主要用于缓存系统表元组；relcache中包含所有访问过的表的模式信息（包含系统表）。这两个缓存在数据库中不是共享的，是每个进程独有的，通过共享消息队列来进行同步。
 relcache，初始化在initpostgres时完成；其中存储的内容（RelationData）会记录到本地文件pg_internal.init中；失效和刷新常发生于执行heap_delete和heap_update类似操作后，会有对应的机制进行缓存刷新。

如下图所示，初始化postgres过程：

启动postgres服务进程：初始化relcache管理环境

• 通过"global/pg_filenode.map"、"global/pg_internal.init"文件初始化共享catalog："pg_catalog"，将系统表"pg_database"、"pg_authid"、"pg_auth_members"等的描述符信息加载到relcache里。"global/pg_filenode.map"文件里存放的是数据库中关系和文件节点的映射信息，"global/pg_internal.init"文件里存放的是"pg_class"、"pg_attribute"、"pg_proc"、"pg_type"等系统关系信息。
• 然后完成设置数据库快照
• 根据hba文件完成客户端认证
• 从pg_database获取客户端要访问的数据库的对应元组
• 根据要访问的数据库ID，加载该数据库本地的"pg_filenode.map"、"pg_internal.init"文件完成初始化。加载"pg_class"、"pg_attribute"、"pg_proc"、"pg_type"等及其索引信息。如果从相关"pg_filenode.map"、"pg_internal.init"文件初始化失败，系统会从硬编码的代码中初始化基础设施相关关系信息。不管加载那个文件，完成相关信息初始化后如有必要将重写该文件。重写时先写临时文件，写完后改文件名为正式文件。这样做是为了避免并发的后台进程读相关文件时崩溃。关于文件名举个例子，例如文件"data/global/pg_internal.init"，对应的临时文件名是"data/global/pg_internal.init.pid"，最后的"pid"是当前进程ID。
• 调用CheckMyDatabase方法检查当前用户的数据库访问权限，从cache里的pg_database取当前数据库的相关属性字段。
• 调用InitializeClientEncoding方法初始化客户端字符编码。
• 调用pgstat_bestart方法在PgBackendStatus设置本进程状态。至此pg服务进程的初始化工作告一段落。

二、查看KingbaseES数据库sys_internal.init文件

1）global目录下系统表cache文件

2）base目录下系统表cache文件

如上图所示，在global或base目录下都有系统表的cache文件sys_internal.init，对于此文件管理方式为，不管加载那个文件，完成相关信息初始化后如有必要将重写该文件。重写时先写临时文件，写完后改文件名为正式文件。这样做是为了避免并发的后台进程读相关文件时崩溃。文件"data/global/pg_internal.init"，对应的临时文件名是"data/global/pg_internal.init.pid"，最后的"pid"是当前进程ID。如下图所示，在备库克隆过程中读取到了sys_internal.init的临时文件，导致clone失败。

3）查看主库下sys_internal.init临时文件

三、问题解决方案

sys_internal.init.pid，是sys_internal.init文件在写入时，产生的临时文件，写入成功后会改名为正式文件，此文件的存在有可能是数据库系统非正常关机导致临时文件没有被及时清理所致，可以通过手工方式将此类文件删除。删除此类文件后，重新执行备库的clone，clone成功。