mysql mount disk_asm disk误设置pvid导致asm diskgroup无法mount恢复

2023-10-11 20:10

本文主要是介绍mysql mount disk_asm disk误设置pvid导致asm diskgroup无法mount恢复,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

有朋友找到我说他们把以前存储到AIX直连的存储切换为含光纤交换机的存储网络后,RAC无法启动,让我给予支持.通过分析是由于换链路之后开始磁盘顺序不对,维护人员对其asm disk 设置了pvid,导致asm 磁盘组无法正常mount,从而使得含votedisk的dg的asm disk无法正常访问,从而RAC的cssd进程无法启动,同样数据文件的磁盘组也无法mount,通过kfed修复成功,实现数据0丢失.

平台版本信息(2节点RAC)

$ sqlplus -v

SQL*Plus: Release 11.2.0.4.0 Production

$ uname -a

AIX db2 1 7 00F9733E4C00

GI日志报错信息

2014-12-20 16:44:08.769:

[ohasd(6946818)]CRS-2769:Unable to failover resource 'ora.diskmon'.

2014-12-20 16:44:11.775:

[cssd(9502756)]CRS-1714:Unable to discover any voting files, retrying discovery in 15 seconds;

Details at (:CSSNM00070:) in /u01/app/11.2.0/grid/log/db1/cssd/ocssd.log

2014-12-20 16:44:26.791:

[cssd(9502756)]CRS-1714:Unable to discover any voting files, retrying discovery in 15 seconds;

、Details at (:CSSNM00070:) in /u01/app/11.2.0/grid/log/db1/cssd/ocssd.log

2014-12-20 16:44:41.812:

[cssd(9502756)]CRS-1714:Unable to discover any voting files, retrying discovery in 15 seconds;

Details at (:CSSNM00070:) in /u01/app/11.2.0/grid/log/db1/cssd/ocssd.log

从这里可以看出来是由于RAC启动过程中无法获得votedisk使得其无法正常启动,通过分析日志找出来votedisk相关磁盘

2014-12-15 17:36:15.424:

[cssd(10027070)]CRS-1605:CSSD voting file is online: /dev/rhdisk4; details in /u01/app/11.2.0/grid/log/db1/cssd/ocssd.log

2014-12-15 17:36:15.433:

[cssd(10027070)]CRS-1605:CSSD voting file is online: /dev/rhdisk5; details in /u01/app/11.2.0/grid/log/db1/cssd/ocssd.log

2014-12-15 17:36:15.445:

[cssd(10027070)]CRS-1605:CSSD voting file is online: /dev/rhdisk6; details in /u01/app/11.2.0/grid/log/db1/cssd/ocssd.log

从这里可以知道rhdisk4,5,6为votedisk对应磁盘,使用kfed查看磁盘头信息

$kfed read /dev/rhdisk4

kfbh.endian: 201 ; 0x000: 0xc9

kfbh.hard: 194 ; 0x001: 0xc2

kfbh.type: 212 ; 0x002: *** Unknown Enum ***

kfbh.datfmt: 193 ; 0x003: 0xc1

kfbh.block.blk: 0 ; 0x004: blk=0

kfbh.block.obj: 0 ; 0x008: file=0

kfbh.check: 0 ; 0x00c: 0x00000000

kfbh.fcn.base: 0 ; 0x010: 0x00000000

kfbh.fcn.wrap: 0 ; 0x014: 0x00000000

kfbh.spare1: 0 ; 0x018: 0x00000000

kfbh.spare2: 0 ; 0x01c: 0x00000000

1102BEE00 C9C2D4C1 00000000 00000000 00000000 [................]

1102BEE10 00000000 00000000 00000000 00000000 [................]

Repeat 6 times

1102BEE80 00F9733D 67553E0A 00000000 00000000 [..s=gU>.........]

1102BEE90 00000000 00000000 00000000 00000000 [................]

Repeat 246 times

KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][212]

$kfed read /dev/rhdisk4 blkn=1

kfbh.endian: 0 ; 0x000: 0x00

kfbh.hard: 130 ; 0x001: 0x82

kfbh.type: 2 ; 0x002: KFBTYP_FREESPC

kfbh.datfmt: 2 ; 0x003: 0x02

kfbh.block.blk: 1 ; 0x004: blk=1

kfbh.block.obj: 2147483648 ; 0x008: disk=0

kfbh.check: 3883664132 ; 0x00c: 0xe77c0304

kfbh.fcn.base: 0 ; 0x010: 0x00000000

kfbh.fcn.wrap: 0 ; 0x014: 0x00000000

kfbh.spare1: 0 ; 0x018: 0x00000000

kfbh.spare2: 0 ; 0x01c: 0x00000000

kfdfsb.aunum: 0 ; 0x000: 0x00000000

kfdfsb.max: 254 ; 0x004: 0x00fe

kfdfsb.cnt: 23 ; 0x006: 0x0017

kfdfsb.bound: 0 ; 0x008: 0x0000

kfdfsb.flag: 1 ; 0x00a: B=1

kfdfsb.ub1spare: 0 ; 0x00b: 0x00

kfdfsb.spare[0]: 0 ; 0x00c: 0x00000000

kfdfsb.spare[1]: 0 ; 0x010: 0x00000000

kfdfsb.spare[2]: 0 ; 0x014: 0x00000000

kfdfse[0].fse: 119 ; 0x018: FREE=0x7 FRAG=0x7

kfdfse[1].fse: 16 ; 0x019: FREE=0x0 FRAG=0x1

…………

$kfed read /dev/rhdisk4 blkn=510

kfbh.endian: 0 ; 0x000: 0x00

kfbh.hard: 130 ; 0x001: 0x82

kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD

kfbh.datfmt: 1 ; 0x003: 0x01

kfbh.block.blk: 254 ; 0x004: blk=254

kfbh.block.obj: 2147483648 ; 0x008: disk=0

kfbh.check: 3460116983 ; 0x00c: 0xce3d31f7

kfbh.fcn.base: 0 ; 0x010: 0x00000000

kfbh.fcn.wrap: 0 ; 0x014: 0x00000000

kfbh.spare1: 0 ; 0x018: 0x00000000

kfbh.spare2: 0 ; 0x01c: 0x00000000

kfdhdb.driver.provstr: ORCLDISK ; 0x000: length=8

kfdhdb.driver.reserved[0]: 0 ; 0x008: 0x00000000

kfdhdb.driver.reserved[1]: 0 ; 0x00c: 0x00000000

kfdhdb.driver.reserved[2]: 0 ; 0x010: 0x00000000

kfdhdb.driver.reserved[3]: 0 ; 0x014: 0x00000000

kfdhdb.driver.reserved[4]: 0 ; 0x018: 0x00000000

kfdhdb.driver.reserved[5]: 0 ; 0x01c: 0x00000000

kfdhdb.compat: 186646528 ; 0x020: 0x0b200000

kfdhdb.dsknum: 0 ; 0x024: 0x0000

kfdhdb.grptyp: 2 ; 0x026: KFDGTP_NORMAL

kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER

kfdhdb.dskname: CRS_0000 ; 0x028: length=8

kfdhdb.grpname: CRS ; 0x048: length=3

kfdhdb.fgname: CRS_0000 ; 0x068: length=8

…………

由上述分析可以基本上确定是asm disk header 被破坏,进一步分析破坏原因

[db2/dev#]lspv

hdisk0 00f9733ef7cf27e9 rootvg active

hdisk1 00f9733e21b953e6 rootvg active

hdisk2 00f9733e21b97a83 appvg active

hdisk3 00f9733e21b98434 appvg active

hdisk4 00f9733d67553e0a None

hdisk5 00f9733d67553f31 None

hdisk6 00f9733d67554011 None

hdisk7 00f9733d67554165 None

hdisk8 00f9733d675541e5 None

hdisk9 00f9733d675542e4 None

hdisk10 none None

[db2/dev#]ls -l rhdisk*

crw------- 2 root system 24, 1 Oct 18 11:45 rhdisk0

crw------- 1 root system 24, 3 Oct 18 13:27 rhdisk1

crw------- 1 root system 24, 5 Dec 20 20:02 rhdisk10

crw------- 1 root system 24, 2 Oct 18 13:32 rhdisk2

crw------- 1 root system 24, 0 Oct 18 13:32 rhdisk3

crw-rw---- 1 grid asmadmin 24, 8 Dec 20 20:02 rhdisk4

crw-rw---- 1 grid asmadmin 24, 9 Dec 20 20:02 rhdisk5

crw-rw---- 1 grid asmadmin 24, 10 Dec 20 20:02 rhdisk6

crw-rw---- 1 grid asmadmin 24, 4 Dec 20 20:02 rhdisk7

crw-rw---- 1 grid asmadmin 24, 6 Dec 20 20:02 rhdisk8

crw-rw---- 1 grid asmadmin 24, 7 Dec 20 20:02 rhdisk9

从这里基本上可以看出来,是由于磁盘头被重写了pvid,导致asm disk header 被破坏.进一步分析asm log,确定哪些磁盘被用作asm disk

SQL> CREATE DISKGROUP CRS NORMAL REDUNDANCY DISK '/dev/rhdisk4',

'/dev/rhdisk5',

'/dev/rhdisk6' ATTRIBUTE 'compatible.asm'='11.2.0.0.0','au_size'='1M' /* ASMCA */

NOTE: Assigning number (1,0) to disk (/dev/rhdisk4)

NOTE: Assigning number (1,1) to disk (/dev/rhdisk5)

NOTE: Assigning number (1,2) to disk (/dev/rhdisk6)

NOTE: initializing header on grp 1 disk CRS_0000

NOTE: initializing header on grp 1 disk CRS_0001

NOTE: initializing header on grp 1 disk CRS_0002

SQL> CREATE DISKGROUP DATA EXTERNAL REDUNDANCY DISK

'/dev/rhdisk9' SIZE 614400M ATTRIBUTE 'compatible.asm'='11.2.0.0.0','au_size'='1M' /* ASMCA */

NOTE: Assigning number (2,0) to disk (/dev/rhdisk9)

NOTE: initializing header on grp 2 disk DATA_0000

SQL> CREATE DISKGROUP FBA EXTERNAL REDUNDANCY DISK

'/dev/rhdisk8' SIZE 204800M ATTRIBUTE 'compatible.asm'='11.2.0.0.0','au_size'='1M' /* ASMCA */

NOTE: Assigning number (3,0) to disk (/dev/rhdisk8)

NOTE: initializing header on grp 3 disk FBA_0000

SQL> CREATE DISKGROUP ARCH EXTERNAL REDUNDANCY DISK

'/dev/rhdisk7' SIZE 102400M ATTRIBUTE 'compatible.asm'='11.2.0.0.0','au_size'='1M' /* ASMCA */

NOTE: Assigning number (4,0) to disk (/dev/rhdisk7)

NOTE: initializing header on grp 4 disk ARCH_0000

这里可以确定asm disk为rhdisk[4-9],通过kfed分析全部和rhdisk4一样的问题,也符合lspv查询出来的结果,使用kfed repair修复asm disk header后

SQL> alter diskgroup data mount;

Diskgroup altered.

SQL> alter diskgroup fba mount;

Diskgroup altered.

SQL> alter diskgroup arch mount;

Diskgroup altered.

SQL> alter diskgroup crs mount;

Diskgroup altered.

SQL> select group_number,disk_number,path from v$asm_disk;

GROUP_NUMBER DISK_NUMBER PATH

------------ ----------- --------------------------------------------------

2 0 /dev/rhdisk4

2 1 /dev/rhdisk5

2 2 /dev/rhdisk6

1 0 /dev/rhdisk7

4 0 /dev/rhdisk8

3 0 /dev/rhdisk9

6 rows selected.

SQL> select group_number,name from v$asm_diskgroup;

GROUP_NUMBER NAME

------------ ------------------------------------------------------------

1 ARCH

2 CRS

3 DATA

4 FBA

这里证明通过kfed对磁盘头的修复,asm磁盘组已经全部mount成功,GI状态也恢复正常

[db2/#]crsctl status res -t

--------------------------------------------------------------------------------

NAME TARGET STATE SERVER STATE_DETAILS

--------------------------------------------------------------------------------

Local Resources

--------------------------------------------------------------------------------

ora.ARCH.dg

ONLINE ONLINE db1

ONLINE ONLINE db2

ora.CRS.dg

ONLINE ONLINE db1

ONLINE ONLINE db2

ora.DATA.dg

ONLINE ONLINE db1

ONLINE ONLINE db2

ora.FBA.dg

ONLINE ONLINE db1

ONLINE ONLINE db2

ora.LISTENER.lsnr

ONLINE ONLINE db1

ONLINE ONLINE db2

ora.asm

ONLINE ONLINE db1 Started

ONLINE ONLINE db2 Started

ora.gsd

OFFLINE OFFLINE db1

OFFLINE OFFLINE db2

ora.net1.network

ONLINE ONLINE db1

ONLINE ONLINE db2

ora.ons

ONLINE ONLINE db1

ONLINE ONLINE db2

ora.registry.acfs

ONLINE ONLINE db1

ONLINE ONLINE db2

--------------------------------------------------------------------------------

Cluster Resources

--------------------------------------------------------------------------------

ora.LISTENER_SCAN1.lsnr

1 ONLINE ONLINE db1

ora.cvu

1 ONLINE ONLINE db1

ora.db1.vip

1 ONLINE ONLINE db1

ora.db2.vip

1 ONLINE ONLINE db2

ora.nkora.db

1 ONLINE ONLINE db1 Open

2 ONLINE ONLINE db2 Open

ora.oc4j

1 ONLINE ONLINE db1

ora.scan1.vip

1 ONLINE ONLINE db1

这里忽略了一个问题,在修复磁盘头之前没有清除pvid,导致磁盘头修复后,pvid依然存储在odm中

[db2/dev#]lspv

hdisk0 00f9733ef7cf27e9 rootvg active

hdisk1 00f9733e21b953e6 rootvg active

hdisk2 00f9733e21b97a83 appvg active

hdisk3 00f9733e21b98434 appvg active

hdisk4 00f9733d67553e0a None

hdisk5 00f9733d67553f31 None

hdisk6 00f9733d67554011 None

hdisk7 00f9733d67554165 None

hdisk8 00f9733d675541e5 None

hdisk9 00f9733d675542e4 None

hdisk10 none None

通过分析发现fba磁盘组中无任何记录,使用该磁盘组进行直接清除pvid测试

$ sqlplus / as sysasm

SQL*Plus: Release 11.2.0.4.0 Production on Sun Dec 21 03:13:31 2014

Copyright (c) 1982, 2013, Oracle. All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

With the Real Application Clusters and Automatic Storage Management options

SQL> alter diskgroup fba dismount;

Diskgroup altered.

SQL> exit

Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

With the Real Application Clusters and Automatic Storage Management options

$ exit

You have mail in /usr/spool/mail/root

[db2/#]chdev -l hdisk8 -a pv=clear

hdisk8 changed

[db2/#]lspv

hdisk0 00f9733ef7cf27e9 rootvg active

hdisk1 00f9733e21b953e6 rootvg active

hdisk2 00f9733e21b97a83 appvg active

hdisk3 00f9733e21b98434 appvg active

hdisk4 00f9733d67553e0a None

hdisk5 00f9733d67553f31 None

hdisk6 00f9733d67554011 None

hdisk7 00f9733d67554165 None

hdisk8 none None

hdisk9 00f9733d675542e4 None

hdisk10 none None

[db2/#]su - grid

$ sqlplus / as sysasm

SQL*Plus: Release 11.2.0.4.0 Production on Sun Dec 21 03:15:19 2014

Copyright (c) 1982, 2013, Oracle. All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

With the Real Application Clusters and Automatic Storage Management options

SQL> alter diskgroup fba mount;

Diskgroup altered.

SQL> exit

Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

With the Real Application Clusters and Automatic Storage Management options

通过测试直接清除pvid asm 磁盘头依然工作正常,关闭GI,使用chdev清除hdisk[4-9]所有pvid,启动GI一切正常

[db1/#]crsctl status res -t

--------------------------------------------------------------------------------

NAME TARGET STATE SERVER STATE_DETAILS

--------------------------------------------------------------------------------

Local Resources

--------------------------------------------------------------------------------

ora.ARCH.dg

ONLINE ONLINE db1

ONLINE ONLINE db2

ora.CRS.dg

ONLINE ONLINE db1

ONLINE ONLINE db2

ora.DATA.dg

ONLINE ONLINE db1

ONLINE ONLINE db2

ora.FBA.dg

ONLINE ONLINE db1

ONLINE ONLINE db2

ora.LISTENER.lsnr

ONLINE ONLINE db1

ONLINE ONLINE db2

ora.asm

ONLINE ONLINE db1 Started

ONLINE ONLINE db2 Started

ora.gsd

OFFLINE OFFLINE db1

OFFLINE OFFLINE db2

ora.net1.network

ONLINE ONLINE db1

ONLINE ONLINE db2

ora.ons

ONLINE ONLINE db1

ONLINE ONLINE db2

ora.registry.acfs

ONLINE ONLINE db1

ONLINE ONLINE db2

--------------------------------------------------------------------------------

Cluster Resources

--------------------------------------------------------------------------------

ora.LISTENER_SCAN1.lsnr

1 ONLINE ONLINE db1

ora.cvu

1 ONLINE ONLINE db1

ora.db1.vip

1 ONLINE ONLINE db1

ora.db2.vip

1 ONLINE ONLINE db2

ora.nkora.db

1 ONLINE ONLINE db1 Open

2 ONLINE ONLINE db2 Open

ora.oc4j

1 ONLINE ONLINE db1

ora.scan1.vip

1 ONLINE ONLINE db1

[db1/#]lspv

hdisk0 00f9733df7c7a9db rootvg active

hdisk1 00f9733d21dad8fe rootvg active

hdisk2 00f9733d21dbd08b appvg active

hdisk3 00f9733d21dbd2ab appvg active

hdisk4 none None

hdisk5 none None

hdisk6 none None

hdisk7 none None

hdisk8 none None

hdisk9 none None

hdisk10 none None

至此设置pvid导致asm disk header损坏的asm 恢复正常,实现数据0丢失。

温馨提示:aix asm disk磁盘中不能设置pvid,否则将会导致asm disk header 损坏,无法正常mount

如果您遇到此类情况,无法解决请联系我们,提供专业ORACLE数据库恢复技术支持

Phone:13429648788    Q Q:107644445070b0066bacfd9eecef93af3f89813bc.png    E-Mail:dba@xifenfei.com

这篇关于mysql mount disk_asm disk误设置pvid导致asm diskgroup无法mount恢复的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/190521

相关文章

SQL中的外键约束

外键约束用于表示两张表中的指标连接关系。外键约束的作用主要有以下三点: 1.确保子表中的某个字段(外键)只能引用父表中的有效记录2.主表中的列被删除时,子表中的关联列也会被删除3.主表中的列更新时,子表中的关联元素也会被更新 子表中的元素指向主表 以下是一个外键约束的实例展示

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

如何去写一手好SQL

MySQL性能 最大数据量 抛开数据量和并发数,谈性能都是耍流氓。MySQL没有限制单表最大记录数,它取决于操作系统对文件大小的限制。 《阿里巴巴Java开发手册》提出单表行数超过500万行或者单表容量超过2GB,才推荐分库分表。性能由综合因素决定,抛开业务复杂度,影响程度依次是硬件配置、MySQL配置、数据表设计、索引优化。500万这个值仅供参考,并非铁律。 博主曾经操作过超过4亿行数据

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

MySQL数据库宕机,启动不起来,教你一招搞定!

作者介绍:老苏,10余年DBA工作运维经验,擅长Oracle、MySQL、PG、Mongodb数据库运维(如安装迁移,性能优化、故障应急处理等)公众号:老苏畅谈运维欢迎关注本人公众号,更多精彩与您分享。 MySQL数据库宕机,数据页损坏问题,启动不起来,该如何排查和解决,本文将为你说明具体的排查过程。 查看MySQL error日志 查看 MySQL error日志,排查哪个表(表空间

电脑桌面文件删除了怎么找回来?别急,快速恢复攻略在此

在日常使用电脑的过程中,我们经常会遇到这样的情况:一不小心,桌面上的某个重要文件被删除了。这时,大多数人可能会感到惊慌失措,不知所措。 其实,不必过于担心,因为有很多方法可以帮助我们找回被删除的桌面文件。下面,就让我们一起来了解一下这些恢复桌面文件的方法吧。 一、使用撤销操作 如果我们刚刚删除了桌面上的文件,并且还没有进行其他操作,那么可以尝试使用撤销操作来恢复文件。在键盘上同时按下“C

三国地理揭秘:为何北伐之路如此艰难,为何诸葛亮无法攻克陇右小城?

俗话说:天时不如地利,不是随便说说,诸葛亮六出祁山,连关中陇右的几座小城都攻不下来,行军山高路险,无法携带和建造攻城器械,是最难的,所以在汉中,无论从哪一方进攻,防守方都是一夫当关,万夫莫开;再加上千里运粮,根本不需要打,司马懿只需要坚守城池拼消耗就能不战而屈人之兵。 另一边,洛阳的虎牢关,一旦突破,洛阳就无险可守,这样的进军路线,才是顺势而为的用兵之道。 读历史的时候我们常常看到某一方势

Android实现任意版本设置默认的锁屏壁纸和桌面壁纸(两张壁纸可不一致)

客户有些需求需要设置默认壁纸和锁屏壁纸  在默认情况下 这两个壁纸是相同的  如果需要默认的锁屏壁纸和桌面壁纸不一样 需要额外修改 Android13实现 替换默认桌面壁纸: 将图片文件替换frameworks/base/core/res/res/drawable-nodpi/default_wallpaper.*  (注意不能是bmp格式) 替换默认锁屏壁纸: 将图片资源放入vendo

安卓链接正常显示,ios#符被转义%23导致链接访问404

原因分析: url中含有特殊字符 中文未编码 都有可能导致URL转换失败,所以需要对url编码处理  如下: guard let allowUrl = webUrl.addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed) else {return} 后面发现当url中有#号时,会被误伤转义为%23,导致链接无法访问