资讯专栏INFORMATION COLUMN

Oracle ASM镜像冗余

IT那活儿 / 2583人阅读
Oracle ASM镜像冗余

点击上方“IT那活儿”,关注后了解更多精彩内容!!


前  言

最近碰到个案例,某ASM环境同时损坏了多块asmdisk,用户非常担心丢数据,经过核查发现该环境采用High模式冗余3份镜像数据,一般来说是不会丢数据的,倘若不巧3份镜像都在这几个损坏的asmdisk中那就完蛋了。

今天我们就来研究一下ASM的镜像冗余以及核验数据的镜像位置从而判断某些asmdisk的损坏是否会引发数据丢失。


首先ASM使用failure group(FG)来实现数据的冗余,FG由一个或多个asmdisk构成它是ASM Diskgroup的一部分.ASM确保数据和它对应的镜像冗余保存在不同的FG中,当FG中的一个或多个磁盘故障时,或整个FG故障时也不会有数据丢失保证数据的可用性。

F G


FG有2种模式
1. 在创建ASM diskgroup时,没有指定FG,ASM默认每个asmdisk就是独立的FG,比如有100个asmdisk那就是100个FG,数据以AU为单位在FG之间实现镜像冗余。
2. 在创建ASM diskgroup时,指定了FG,还是100个asmdisk为例,可以指定4个FG,每个FG对应25个asmdisk,数据以AU为单位在FG之间实现镜像冗余。
ASM有3种冗余级别,分别是External/ Normal/ High具体如下:
冗余级别(Redundancy)
描述
External
类似于传统裸设备、文件系统模式,冗余由底层设备提供,ASM层不处理冗余。
Normal
ASM层为每一份数据(primary data)提供一份(mirror data),相当于存2份数据。
必须存在2个及以上的FG才可以创建Normal模式的diskgroup。
High
ASM层为每一份数据(primary data)提供二份(mirror data),相当于存3份数据。
必须存在3个及以上的FG才可以创建High模式的diskgroup。


注意这里External模式ASM层不做镜像,数据的可用性依赖于底层设备的raid冗余,本文仅探讨Normal与High模式。

FG模式1
创建diskgroup时没有指定FG的冗余描述图:
Normal:
图中可以看到,每个asmdisk都是一个FG,Normal模式的2份数据存在不同的FG上,当某个asmdisk故障(FG故障)时,数据任然可以在镜像FG中访问。当某个asmdisk(FG)与对应的镜像数据asmdisk(FG)同时故障时会丢失数据。
High:
图中可以看到,每个asmdisk都是一个FG,High模式的3份数据存在不同的FG上,当某个asmdisk故障(FG故障)时,数据任然可以在其它2份镜像FG中访问。当某个asmdisk(FG)与对应的2份镜像数据asmdisk(FG)同时故障时会丢失数据。
在normal或high模式下diskgroup里的asmdisk未指定FG时,默认每个asmdisk都是一个独立的FG,AU在各个FG之间镜像冗余,也就是我们平常说的创建Normal冗余需要至少2块asmdisk(FG),High模式至少需要3块asmdisk(FG)。
FG模式2
创建diskgroup时指定了FG的冗余描述图:
Normal:
图中可以看到一共有8块asmdisk,每2块指定为1个 FG,Normal模式的2份数据存在不同的FG上,当某个FG故障时,数据任然可以在镜像FG中访问。当某个FG与对应的镜像数据FG同时故障时会丢失数据。
High:
图中可以看到一共有8块asmdisk,每2块指定为1个 FG,High模式的3份数据存在不同的FG上,当某个FG故障时,数据任然可以在其他2份镜像FG中访问。当某个FG与对应的2份镜像数据FG同时故障时会丢失数据。
图中可以看到Normal冗余将2块asmdisk都指向了FG1时,创建diskgroup报错,提示只发现了1个FG,最少需要2个FG。High冗余同理。
这里指定2个及以上FG时就可以正常创建Normal冗余,High同理。注意当人工干预指定了FG时,注意各个FG的容量需要一致,以保证数据的冗余性。举例Normal模式下,指定了FG1为100G,FG2为50G 相当于FG1里还有50G数据在FG2中没有空间可以镜像,这就失去了冗余安全性,部分环境里看到的lsdg显示Usable_File_MB为负数就是失去了冗余的完整性,这种环境往往需要注意一旦出现asmdisk故障可能丢失数据。

分 隔


上文中我们搞清了diskgroup通过FG来实现镜像冗余,接下来我们新建一个High模式的磁盘组并创建数据文件,来观察数据以及镜像数据的具体存放FG。如下:
通过dbca在我们的diskgroup中创建一个新实例,可以看到已经产生了数据文件。我们以asm file_number 260 users表空间文件为例来检查该文件所在的FG地址。
在High模式下,每份数据会分为Primary copy/Mirror copy/2nd Mirrory 3份数据,且3份数据分布在不同的FG中。
这里我们先关闭diskgroup的重平衡,在模拟故障offline Primary Copy 与 Mirror copy 的FG,如下:
此时asm users260文件的extent#0只剩下2nd Mirror的FG可以访问.DB层Useres表空间下的表访问正常,asmdisk  offline无影响.
以上我们是使用asm文件号来进行查询镜像数据的存储位置, 当我们出现asmdisk故障时也可以根据disk_number来进行核验mirror数据所在的FG,如下:
通过带入故障的group number和disk_number 查出该asmdisk内的文件涉及的镜像FG,当故障的asmdisk涉及的镜像FG状态都正常时,我们就可以确保数据仍然是安全的,diskgroup 重平衡后就会自动恢复对应的镜像冗余级别。
本文就到此为止。

END


本 文 原 创 来 源:IT那活儿微信公众号(上海新炬王翦团队)


文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/129682.html

相关文章

  • #yyds干货盘点#Java ASM系列:(091)冗余变量分析

    摘要:程序中定义的变量是存储在当中。判断和是否相同,如果相同,那么表示是冗余的变量。示例冗余变量分析预期目标在下面的代码中,会提示和局部变量是多余的我们的预期目标识别出和是冗余变量。 本文属于Java ASM系列三:Tree API当中的一篇。 1. 如何判断变量是否冗余 如果在IntelliJ IDEA当中编写如下的代码,它会提示str2和str3局部变量是多余的: ...

    mengbo 评论0 收藏0
  • DBASK问答集萃第四期

    摘要:问题九库控制文件扩展报错库的扩展报错,用的是裸设备,和还是原来大小,主库的没有报错,并且大小没有变,求解释。专家解答从报错可以看出,控制文件从个块扩展到个块时报错,而裸设备最大只支持个块,无法扩展,可以尝试将参数改小,避免控制文件报错。 链接描述引言 近期我们在DBASK小程序新关联了运维之美、高端存储知识、一森咖记、运维咖啡吧等数据领域的公众号,欢迎大家阅读分享。 问答集萃 接下来,...

    SKYZACK 评论0 收藏0

发表评论

0条评论

IT那活儿

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<