【openGauss5.0.0】数据库恢复XLOG分析

已于 2024-03-25 23:19:48 修改
阅读量1.1k 收藏 19
点赞数 22
分类专栏： openGauss 文章标签： 数据库 oracle
于 2024-03-25 22:37:34 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/sujiangming/article/details/137026874
版权
文章详细描述了一个使用openEuler20.03LTS的PostgreSQL5.0.0企业版数据库进行实验，探讨了快速和立即关闭模式对事务的影响，以及XLOG在数据库恢复过程中的关键作用。实验中展示了在不同关闭模式下，数据库的运行日志变化和数据恢复情况。
摘要由CSDN通过智能技术生成

数据库恢复XLOG分析

一、实验环境

  1. Virtualbox：一台虚拟机
  2. 操作系统：openEuler20.03 LTS
  3. 数据库版本：5.0.0 企业版

二、相关知识点

关闭模式有两种：

  1. 快速（fast）：快速关闭数据库，断开客户端的连接，让当前未提交事务回滚，然后正常关闭数据库。
  2. 立即（immediate）：立即关闭数据库，立即停止数据库进程，直接退出；下次启动时会进行数据库恢复。

三、实验过程

  1. 启动数据库系统

  2. 通过gsql登录postgres数据库

  3. 创建测试表t3

    openGauss=# CREATE TABLE t3 (id INT, name VARCHAR(50));

  4. 开启显示事务并执行insert语句，但未提交事务

    openGauss=# begin;
BEGIN
openGauss=# insert into t3 values(1, 'test');
INSERT 0 1
openGauss=#

  5. 打开新的SSH会话窗口以fast模式关闭数据库

    gs_om -t stop -m fast

  6. 查看数据库运行日志变化情况

    2024-03-25 20:54:14.625 66017163.1 [unknown] 140545200476096 [unknown] 0 dn_6001 00000  0 [BACKEND] LOG:  received fast shutdown request
2024-03-25 20:54:14.643 66017164.6124 [unknown] 140541970036480 AutoVacLauncher 0 dn_6001 00000  0 [BACKEND] LOG:  autovacuum launcher shutting down
2024-03-25 20:54:14.647 66017164.5080 postgres 140541944805120 JobScheduler 0 dn_6001 00000  0 [BACKEND] LOG:  job scheduler is shutting down
2024-03-25 20:54:14.657 66017164.6127 [unknown] 140541538858752 dn_6001 0 dn_6001 00000  0 [BACKEND] LOG:  shutting down
2024-03-25 20:54:14.746 66017164.6127 [unknown] 140541538858752 dn_6001 0 dn_6001 00000  0 [BACKEND] LOG:  will do full checkpoint, need flush 0 pages.
2024-03-25 20:54:14.746 66017164.6127 [unknown] 140541538858752 dn_6001 0 dn_6001 00000  0 [SLRU] LOG:  remove old segments(<0) under pg_csnlog
2024-03-25 20:54:15.017 66017164.6132 [unknown] 140542053943040 dn_6001 0 dn_6001 00000  0 [INCRE_CKPT] LOG:  pagewriter thread shut down, id is 2
2024-03-25 20:54:15.020 66017164.6125 [unknown] 140542087505664 dn_6001 0 dn_6001 00000  0 [INCRE_CKPT] LOG:  pagewriter thread shut down, id is 0
2024-03-25 20:54:15.023 66017164.6127 [unknown] 140541538858752 dn_6001 0 dn_6001 00000  0 [UNDO] LOG:  [CheckPointUndoSystemMeta:355]undo metadata checkPointRedo = 38073248, oldestXmin = 19961, recycleXmin = 19961, globalFrozenXid = 0, globalRecycleXid = 13845.
2024-03-25 20:54:15.026 66017164.6127 [unknown] 140541538858752 dn_6001 0 dn_6001 00000  0 [BACKEND] LOG:  keep all the xlog segments, because current segno = 2, less than wal_keep_segments = 16
2024-03-25 20:54:15.026 66017164.6127 [unknown] 140541538858752 dn_6001 0 dn_6001 01000  0 [BACKEND] WARNING:  replicationSlotMinLSN is InvalidXLogRecPtr!!!
2024-03-25 20:54:15.026 66017164.6127 [unknown] 140541538858752 dn_6001 0 dn_6001 01000  0 [BACKEND] WARNING:  replicationSlotMaxLSN is InvalidXLogRecPtr!!!
2024-03-25 20:54:15.027 66017164.6127 [unknown] 140541538858752 dn_6001 0 dn_6001 00000  0 [BACKEND] LOG:  CreateCheckPoint PrintCkpXctlControlFile: [checkPoint] oldCkpLoc:0/244D808, oldRedo:0/244D788, newCkpLoc:0/244F3A0, newRedo:0/244F3A0, preCkpLoc:0/244D6E8
2024-03-25 20:54:15.027 66017164.6127 [unknown] 140541538858752 dn_6001 0 dn_6001 00000  0 [BACKEND] LOG:  will update control file (create checkpoint), shutdown:1
2024-03-25 20:54:15.028 66017164.6127 [unknown] 140541538858752 dn_6001 0 dn_6001 00000  0 [BACKEND] LOG:  attempting to remove WAL segments older than log file 000000010000000000000000
2024-03-25 20:54:15.029 66017164.6127 [unknown] 140541538858752 dn_6001 0 dn_6001 00000  0 [DBL_WRT] LOG:  Double write exit
2024-03-25 20:54:15.029 66017164.6127 [unknown] 140541538858752 dn_6001 0 dn_6001 00000  0 [DBL_WRT] LOG:  Double write exit
2024-03-25 20:54:15.029 66017164.6127 [unknown] 140541538858752 dn_6001 0 dn_6001 00000  0 [BACKEND] LOG:  database system is shut down
2024-03-25 20:54:15.30  [postmaster][reaper][140545200476096] LOG: checkpoint thread exit and nowait for sharestorage
2024-03-25 20:54:15.118 66017163.1 [unknown] 140545200476096 [unknown] 0 dn_6001 00000  0 [BACKEND] LOG:  FiniNuma allocIndex: 0.
2024-03-25 20:54:15.118 66017163.1 [unknown] 140545200476096 [unknown] 0 dn_6001 00000  0 [BACKEND] LOG:  Gaussdb exit(0)

  7. 重启数据库，查看t3表数据及当前xlog插入点及LSN

    [omm@standalone ~]$ gs_om -t start
[omm@standalone ~]$ gsql -d postgres -p 26000 -r
openGauss=# select * from t3;
 id | name
----+------
(0 rows)
openGauss=# select pg_current_xlog_insert_location();
 pg_current_xlog_insert_location
---------------------------------
 0/244F8C0
(1 row)
openGauss=# select pg_xlogfile_name('0/244F8C0');
 pg_xlogfile_name
--------------------------
 000000010000000000000002
(1 row)

openGauss=# select pg_xlogfile_name_offset('0/244F8C0');
      pg_xlogfile_name_offset
------------------------------------
 (000000010000000000000002,4520128)
(1 row)

    查看表数据，发现未提交的事务被回滚，insert语句插入的数据没有出现在表中。

  8. 重复步骤2重新登录数据库，在不开启显示事务下执行insert语句

    openGauss=# insert into t3 values(1, 'test');
INSERT 0 1

  9. 查看当前xlog插入点及LSN所在WAL的位置

    openGauss=# select pg_current_xlog_insert_location();
 pg_current_xlog_insert_location
---------------------------------
 0/244FE20
(1 row)
openGauss=# select pg_xlogfile_name('0/244FE20');
 pg_xlogfile_name
--------------------------
 000000010000000000000002
(1 row)

openGauss=# select pg_xlogfile_name_offset('0/244FE20');
 pg_xlogfile_name_offset
------------------------------------
 (000000010000000000000002,4521504)
(1 row)

    xlog当前插入点：0/244FE20,当前插入的xlog segment为：000000010000000000000002，LSN为：4521504

  10. 打开新的SSH会话窗口以immediate模式关闭数据库

    gs_om -t stop -m immediate

  11. 重复步骤6查看新的运行日志变化情况
    找到最新的一条日志文件，查看最后11数据，内容如下：

    2024-03-25 21:06:49.293 660174cd.6125 [unknown] 140493807679232 dn_6001 0 dn_6001 00000  0 [BACKEND] LOG:  keep all the xlog segments, because current segno = 2, less than wal_keep_segments = 16
2024-03-25 21:06:49.294 660174cd.6125 [unknown] 140493807679232 dn_6001 0 dn_6001 01000  0 [BACKEND] WARNING:  replicationSlotMinLSN is InvalidXLogRecPtr!!!
2024-03-25 21:06:49.294 660174cd.6125 [unknown] 140493807679232 dn_6001 0 dn_6001 01000  0 [BACKEND] WARNING:  replicationSlotMaxLSN is InvalidXLogRecPtr!!!
2024-03-25 21:06:49.294 660174cd.6125 [unknown] 140493807679232 dn_6001 0 dn_6001 00000  0 [BACKEND] LOG:  CreateCheckPoint PrintCkpXctlControlFile: [checkPoint] oldCkpLoc:0/244FCA0, oldRedo:0/244FC20, newCkpLoc:0/244FEA0, newRedo:0/244FE20, preCkpLoc:0/244FB80
2024-03-25 21:06:49.294 660174cd.6125 [unknown] 140493807679232 dn_6001 0 dn_6001 00000  0 [BACKEND] LOG:  will update control file (create checkpoint), shutdown:0
2024-03-25 21:06:49.296 660174cd.6125 [unknown] 140493807679232 dn_6001 0 dn_6001 00000  0 [BACKEND] LOG:  attempting to remove WAL segments older than log file 000000010000000000000000
2024-03-25 21:07:07.667 660176fb.5060 postgres 140493504444160 Clean Statement thread 0 dn_6001 00000  0 [BACKEND] LOG:  clean statement thread start
2024-03-25 21:07:43.608 660174cd.1 [unknown] 140497468059584 [unknown] 0 dn_6001 00000  0 [BACKEND] LOG:  received immediate shutdown request
2024-03-25 21:07:43.608 660174cd.10000 [unknown] 140494557538048 dn_6001 0 dn_6001 00000  0 [BACKEND] LOG:  [Alarm Module]alarm checker shutting down...
2024-03-25 21:07:43.612 660174cd.1 [unknown] 140497468059584 [unknown] 0 dn_6001 00000  0 [BACKEND] LOG:  FiniNuma allocIndex: 0.
2024-03-25 21:07:43.612 660174cd.1 [unknown] 140497468059584 [unknown] 0 dn_6001 00000  0 [BACKEND] LOG:  Gaussdb exit(0)

    注意，其中有一行日志为：

    [BACKEND] LOG: CreateCheckPoint PrintCkpXctlControlFile: [checkPoint] oldCkpLoc:0/244FCA0, oldRedo:0/244FC20, newCkpLoc:0/244FEA0, newRedo:0/244FE20, preCkpLoc:0/244FB80
    表明了重做日志点的位置：0/244FE20，这个值和第9步骤看到的是一样的。

  12. 再重启数据库，查看t3表数据及运行日志变化情况

    openGauss=# select * from t3;
 id | name
----+------
  1 | test
(1 row)

    t3表已有数据。再看最新的运行日志：

    [BACKEND] LOG:  database system was not properly shut down; automatic recovery in progress
[BACKEND] LOG:  StartupXLOG PrintCkpXctlControlFile: [checkPoint] oldCkpLoc:0/244FEA0, oldRedo:0/244FE20, newCkpLoc:0/244FEA0, newRedo:0/244FE20, preCkpLoc:0/244FCA0
……
 [BACKEND] LOG:  redo starts at 0/244FE20
 [BACKEND] LOG:  redo done at 0/244FEA0, end at 0/244FF40
 [REDO] LOG:  [PR]: Recoverying elapsed: 102217 us, redoTotalBytes:288,EndRecPtr:38076224, redoStartPtr:38075936,speed:0 MB/s, totalTime:102217
 [BACKEND] LOG:  CreateCheckPoint PrintCkpXctlControlFile: [checkPoint] oldCkpLoc:0/244FEA0, oldRedo:0/244FE20, newCkpLoc:0/244FFC0, newRedo:0/244FF40, preCkpLoc:0/244FEA0

    其中redo starts at 0/244FE20 说明重启后，数据库需要重做日志，将数据进行恢复。

若兰幽竹
关注
专栏目录
openGauss/MogDB数据库安装部署之xlog目录设置
2401_83143557的博客
03-28 287
xlog 文件是一个记录事务日志的文件，它记录数据库系统中所有的更改操作，当发生主机电源故障或其他导致服务器崩溃的服务器故障时，由于 xlog 日志包含了关于已经执行的每个事务的足够信息，所以数据库能够通过在事务日志中 replay 操作来恢复数据库中的数据。注意 dataNode1 数据目录的格式里有各个主机的 hostname 名称，dataNodeXlogPath1 参数里只需要重复配置多个 xlog 的路径即可，不需要有各主机 hostname 的设置。调整之前原来规划的数据目录如下。
openGauss高性能--Xlog no Lock Flush
Cui_Yuan_666的博客
08-23 27
取消WalInsertLock争抢及WalWriter专用磁盘写入线程。
【MogDB/openGauss数据库xlog目录满问题处理】
小怪兽的博客
12-26 3385
MODGDB/openGauss数据库xlog满通常为以下几个原因： 1.主备状态不正常，存在网络问题，集群内有宕机的节点 2.xlog保留数量过多 3.逻辑复制槽失效，且未及时清理 4.开启归档，但归档失败导致xlog不清理 首先，确认数据库状态 gs_om -t query 确认主备状态，是否存在宕机的节点。 查看是否存在down，Standby Need repair(WAL)或者unkown的状态。 如果数据库状态不正常，xlog目录100% 需要手动移走一部分xlog后，检查数据库状
【参赛作品41】openGauss/MogDB数据库安装部署之xlog目录设置
Gauss松鼠会
12-17 1023
xlog文件是一个记录事务日志的文件，它记录数据库系统中所有的更改操作，当发生主机电源故障或其他导致服务器崩溃的服务器故障时，由于xlog日志包含了关于已经执行的每个事务的足够信息，所以数据库能够通过在事务日志中replay操作来恢复数据库中的数据。为了提高写入性能需要将xlog从数据目录分离出来。
【MogDB/openGauss误删未归档的xlog日志如何解决】
小怪兽的博客
11-07 745
在使用MogDB/openGauss数据库的过程中，有时候大量业务，或者导数据会导致pg_xlog下的日志数量持续增长，此时如果xlog的产生频率太快，而来不及自动清理，极有可能造成pg_xlog目录的打满。如果对数据库的xlog不太了解的时候，可能造成误删未归档的xlog日志，或者更严重地，把对应操作还未写入数据文件的xlog也删除了。
OpenGauss 3.1 单实例重启启动失败当kill -9 主进程后
weixin_54645630的博客
03-15 623
在自己的测试环境，因同一个主机上同时运行openGuass和PostGreSQL, 默认都是5432 port， 当在opengauss运行中我使用kill -9 杀死主进程后，重启失败。
centos7.6 安装华为开源openGauss5.0.0数据库
最新发布
09-14
centos7.6 安装华为开源openGauss5.0.0数据库 实际操作，按照步骤百分百成功！！！
openGauss_5.0.0 分布式安装包下载地址
08-27
openGauss_5.0.0 分布式镜像下载地址
【我和openGauss的故事】kettle连接openGauss 5.0.0 数据库
gallopingdb的博客
08-14 407
Kettle最早是一个开源的ETL工具，全称为KDE Extraction, Transportation, Transformation and Loading Environment。在2006年，Pentaho公司收购了Kettle项目，原Kettle项目发起人Matt Casters加入了Pentaho团队，成为Pentaho套件数据集成架构师 [1]；
openGauss 5.0.0：开源数据库的里程碑与企业级特性提升
openGauss 5.0.0版本是面向数据基础设施的开源数据库，自2020年6月首次发布基础版本1.0.0以来，经过多次迭代升级，不断增强了其在高性能、高可靠、高安全和高智能方面的特性。这个版本在2023年3月达到了5.0.0，带来...
opengauss 5.0.0集群部署
10-27
OpenGauss 5.0.0是一个开源的关系型数据库管理系统，下面是集群部署的步骤： 1. 准备环境：确保所有参与集群的服务器都满足最低配置要求，并且安装了适当的操作系统和依赖项。 2. 下载并安装OpenGauss：从官方网站...
openGauss数据库pg_xlog爆满问题解决
Gauss松鼠会
04-24 4710
openGauss数据库pg_xlog日志爆满问题解决办法
openGauss学习笔记-177 openGauss 数据库运维-逻辑复制-逻辑解码-逻辑解码概述
超哥的博客
12-29 1464
支持通过数据迁移工具定期向异构数据库（如Oracle等）进行数据同步，不具备实时数据复制能力。不足以支撑与异构数据库间并网运行实时数据同步的诉求。 openGauss提供了逻辑解码功能，通过反解xlog的方式生成逻辑日志。目标数据库解析逻辑日志以实时进行数据复制。
openGauss学习笔记-212 openGauss 数据库运维-日志参考
超哥的博客
02-02 1282
openGauss学习笔记-212 openGauss 数据库运维-日志参考212.1 日志类型简介212.2 系统日志212.3 操作日志212.4 审计日志212.5 WAL日志212.6 性能日
openGauss 数据库-PITR 恢复
2301_79720856的博客
03-06 837
以上的报错，是由于日志文件问题，根据 recovery.conf 文件内容，只是把归档目录中的文件自动复制到 pg_xlog 目录中，不如直接手动把归档日志文件复制到 pg_xlog 目录中。当数据库崩溃或希望回退到数据库之前的某一状态时，openGauss 的即时恢复功能（Point-In-Time Recovery，简称 PITR）可以支持恢复到备份归档数据之后的任意时间点。请注意案例中的 /opt/huawei/install/data/ 为本示例中的数据文件目录，请根据实际情况修改此输入值。
openGauss2.0.0 极简版安装
2301_79720856的博客
03-15 1346
openGauss 的极简安装没有使用 OM 工具，即不能使用 OM 工具对 openGauss 实例进行管理和配置。openGauss 极简版免去了用户配置 XML 文件的操作，也免去了配置 1 主+1 备的配置操作，这简化了少许安装操作。但是极简版个人感觉稍有些失望，所谓的"极"字并没有得到充分体现，系统内核参数、资源限制参数、环境变量配置、用户创建、目录创建和权限等等这些操作并没有实现自动化配置，脚本很简单但是并没有写入 install 脚本中。
openGauss学习笔记-147 openGauss 数据库运维-备份与恢复-逻辑备份与恢复之gs_dump
超哥的博客
12-07 1401
gs_dump是openGauss用于导出数据库相关信息的工具，用户可以自定义导出一个数据库或其中的对象（模式、表、视图等），回收站对象除外。支持导出的数据库可以是默认数据库postgres，也可以是自定义数据库。
openGauss存储技术（二）——行存储引擎
Cui_Yuan_666的博客
11-15 490
上篇讲了openGauss行存储引擎总体架构、行存储的基本模型与页面组织结构、行存储的多版本管理以及 DML操作，本篇继续精彩分享~
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

若兰幽竹

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值