暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

循序渐进丨不小心搞坏了一个生产表,MogDB还能救吗?

MogDB 2024-09-25
201

最近某金融客户突然问我,如果数据库出现坏块或者文件损坏,MogDB是否有什么好的解决方案?之前我并没有接触过这个客户,了解后发现他们居然已经投产了20多套MogDB了。作为曾经的Oracle重度使用用户,大家自然会拿国产数据库与Oracle进行比较。
我们知道Oracle数据库中有corrupt block自动修复功能,在主备环境中,如果主库或者备库出现数据坏块,那么Oracle ADG能够进行自动修复。
这实际上是Oracle 11.2.0.3版本所引入的一个特性auto block media recover,简称bmr。这个功能有相关的数据库参数来进行控制,决定是否启用。
NAME                                 VALUE        DESCRIB
------------------------------------ ------------ ------------------------------------------------
_auto_bmr                            enabled      enable/disable Auto BMR
_auto_bmr_req_timeout                60           Auto BMR Requester Timeout
_auto_bmr_sess_threshold             30           Auto BMR Request Session Threshold
_auto_bmr_pub_timeout                10           Auto BMR Publish Timeout
_auto_bmr_fc_time                    60           Auto BMR Flood Control Time
_auto_bmr_bg_time                    3600         Auto BMR Process Run Time
_auto_bmr_sys_threshold              100          Auto BMR Request System Threshold
_auto_bmr_max_rowno                  1024         x$krbabrstat Max number of rows


Oracle的这个功能很强大,也非常人性化,其基本原理跟blockrecover类似,copy block+ apply redo。
那么如果你使用国产数据库,比如MogDB,遇到文件损坏或者坏块怎么办呢?
我们知道MogDB使用的文件系统,而openGauss系数据库的表本质上就是一个独立的文件。如果你真的遇到表文件损坏,那么实际上MogDB也提供了相关的函数来应对这个场景。
这里我给大家简单演示一下。
[omm1@mogdb1 ~]$ gsql -r
gsql ((MogDB 5.0.8 build 41aa0432) compiled at 2024-07-26 12:43:48 commit 0 last mr 1804 )
Non-SSL connection (SSL connection is recommended when requiring high-security)
Type "help" for help.

MogDB=# \l
                                 List of databases
   Name    | Owner | Encoding | Collate | Ctype | Access privileges | Compatibility 
-----------+-------+----------+---------+-------+-------------------+---------------
 aa        | aa    | UTF8     | C       | C     |                   | A
 bb        | bb    | UTF8     | C       | C     |                   | B
 postgres  | omm1  | UTF8     | C       | C     |                   | A
 template0 | omm1  | UTF8     | C       | C     | =c/omm1          +| A
           |       |          |         |       | omm1=CTc/omm1     | 
 template1 | omm1  | UTF8     | C       | C     | =c/omm1          +| A
           |       |          |         |       | omm1=CTc/omm1     | 
(5 rows)

MogDB=# \c aa
Non-SSL connection (SSL connection is recommended when requiring high-security)
You are now connected to database "aa" as user "omm1".
aa=#  create table test_corrupt(id int,name varchar(100));
CREATE TABLE
aa=# insert into test_corrupt select generate_series,generate_series||'MogDB or MogDB Cube' from generate_series(1,100000);
INSERT 0 100000
aa=# SELECT pg_relation_filepath('test_corrupt');
 pg_relation_filepath 
----------------------
 base/16779/31665
(1 row)

aa=# checkpoint;
CHECKPOINT
aa=
aa=# \q

万事具备只欠东风!这里模拟删除这个表文件。注意!如果是生产库,请慎重!
[omm1@mogdb1 ~]$ cd $PGDATA
[omm1@mogdb1 data]$ rm -rf  base/16779/31665
[omm1@mogdb1 data]$ 
[omm1@mogdb1 data]$ gsql -r -d aa
gsql ((MogDB 5.0.8 build 41aa0432) compiled at 2024-07-26 12:43:48 commit 0 last mr 1804 )
Non-SSL connection (SSL connection is recommended when requiring high-security)
Type "help" for help.

aa=# select count(1) from test_corrupt;
ERROR:  could not open file "base/16779/31665": No such file or directory
aa=

人为删除这个表文件之后,我们登录数据库后查询,发现已经找不到文件了。
aa=# select * from gs_verify_data_file();
     node_name     | rel_oid |   rel_name   |  miss_file_path  
-------------------+---------+--------------+------------------
 dn_6001_6002_6003 |   31665 | test_corrupt | base/16779/31665
(1 row)

aa=
aa=# \timing on
Timing is on.
aa=# select * from gs_repair_file(31665,'base/16779/31665',600);
 gs_repair_file 
----------------
 t
(1 row)

Time: 530.816 ms
aa=# select count(1) from test_corrupt;
 count  
--------
 100000
(1 row)

Time: 33.093 ms
aa=


大家可以看到,通过gs_verify_data_file函数可以对表文件进行check检查,有点类似Oracle dbv工具,关于该函数的用法解释如下:
参数说明:
  • tableoid
    要修复的文件对应的表oid,依据gs_verify_data_file函数返回的列表中rel_oid一列填写。
    取值范围:Oid,0 - 4294967295。注意:输入负值等都会被强制转成非负整数类型。
  • path
    需要修复的文件路径,依据gs_verify_data_file函数返回的列表中miss_file_path一列填写。
    取值范围:字符串。
  • timeout
    等待备DN回放的时长,修复文件需要等待备DN回放到当前主DN对应的位置,根据备DN回放所需时长设定。
    取值范围:60s - 3600s。
最后一步是通过gs_repair_file函数来进行文件自动修复。可以看到,非常顺利地修复了这个表文件,至于gs_repair_file函数的用法,也比较类似,大家参考MogDB官网即可。
那么这个修复具体是什么逻辑呢?实际上我们看看log就能够发现一些线索。
2024-08-20 15:55:09.762 omm1 aa [local] 47016331712256 0[0:0#0] 2251799813808012 [REMOTE] LOG:  remote read page size, file base/16779/31665 from 172.20.22.128@17135
2024-08-20 15:55:09.884 omm1 aa [local] 47016331712256 0[0:0#0] 2251799813808012 [REMOTE] LOG:  remote read page, file base/16779/31665 block start is 0 from 172.20.22.126@54520
2024-08-20 15:55:10.290 omm1 aa [local] 47016331712256 0[0:0#0] 2251799813808012 [REDO] LOG:  file rename from base/16779/31665.repair to base/16779/31665 finish


大家可以看到,本质上修复的这个文件是从备库去拉取的,同时再应用本地redo。
关于提到的几个函数的功能和一些详细描述,大家可以参考MogDB官方文档。

参考:https://docs.mogdb.io/zh/mogdb/v5.0/data-damage-detection-and-repair-functions


关于作者

李真旭,网名Roger,前Oracle ACE,拥有十多年的Oracle运维管理使用经验,参与过众多运营商、金融、政务行业客户的大型数据库交付项目,具有丰富的运维管理经验;对数据库管理运行机制、锁机制、优化机制等具有深入理解,擅长数据库的performance tunning、troubleshooting以及异常恢复,帮助众多中大型客户解决了无数疑难问题,累计恢复的数据总量超过1个PB。

END


MogDB 是云和恩墨基于 openGauss 开源内核进行增强提升,推出的一款安稳易用的企业级关系型数据库。其具备金融级高可用和全密态计算的极致安全、面向多核处理器的极致性能、AI自诊断调优的极致智能能力,能够满足从核心交易到复杂计算的企业级业务需求。

访问官网了解更多:www.mogdb.io

产品兼容适配申请:partner@enmotech.com

加微信进入交流群:Roger_database

文章转载自MogDB,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论