最近某金融客户突然问我，如果数据库出现坏块或者文件损坏，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。

ITPub博客

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

最新文章