记一次DRBD Unknown故障处理过程

原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://koumm.blog.51cto.com/703525/1769112

配置drbd过程出现Primary/Unknown 故障,最后通过如下方式解决。

1, 节点状态查看

(1) 主节点状态

[root@app1 drbd.d]# cat /proc/drbd    
version: 8.4.3 (api:1/proto:86-101)    
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by gardner@, 2013-11-29 12:28:00    
0: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r-----    
    ns:0 nr:0 dw:0 dr:672 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:604    
[root@app1 drbd.d]#

(2) 从节点状态

[root@app2 ~]# cat /proc/drbd    
version: 8.4.3 (api:1/proto:86-101)    
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by gardner@, 2013-11-29 12:28:00    
0: cs:StandAlone ro:Secondary/Unknown ds:UpToDate/DUnknown   r-----    
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:548    
[root@app2 ~]#

2. 这里确认以主节点的数据为准,重新同步到从节点

(1) 停止app2 drbd服务

[root@app2 ~]# service drbd stop   
Stopping all DRBD resources: .    
[root@app2 ~]#

(2) 重新初始化元数据

[root@app2 ~]# drbdadm create-md data   
You want me to create a v08 style flexible-size internal meta data block.    
There appears to be a v08 flexible-size internal meta data block    
already in place on /dev/sdb1 at byte offset 5364318208    
Do you really want to overwrite the existing v08 meta-data?    
[need to type 'yes' to confirm] yes

Writing meta data...   
md_offset 5364318208    
al_offset 5364285440    
bm_offset 5364121600

Found ext3 filesystem   
     5238400 kB data area apparently used    
     5238400 kB left usable by current configuration

Even though it looks like this would place the new meta data into   
unused space, you still need to confirm, as this is only a guess.

Do you want to proceed?   
[need to type 'yes' to confirm] yes

initializing activity log   
NOT initializing bitmap    
lk_bdev_save(/var/lib/drbd/drbd-minor-0.lkbd) failed: No such file or directory    
New drbd meta data block successfully created.    
lk_bdev_save(/var/lib/drbd/drbd-minor-0.lkbd) failed: No such file or directory

(3) 启动drbd服务

[root@app2 ~]# service drbd start   
Starting DRBD resources: [    
     create res: data    
   prepare disk: data    
    adjust disk: data    
     adjust net: data    
]    
..........    
***************************************************************    
DRBD's startup script waits for the peer node(s) to appear.    
- In case this node was already a degraded cluster before the    
   reboot the timeout is 0 seconds. [degr-wfc-timeout]    
- If the peer was available before the reboot the timeout will    
   expire after 0 seconds. [wfc-timeout]    
   (These values are for resource 'data'; 0 sec -> wait forever)    
To abort waiting enter 'yes' [  15]:se

.   
[root@app2 ~]# cat /proc/drbd    
version: 8.4.3 (api:1/proto:86-101)    
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by gardner@, 2013-11-29 12:28:00    
0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----    
    ns:0 nr:5238400 dw:5238400 dr:0 al:0 bm:320 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0    
[root@app2 ~]#

3. app1主节点下

(1) 主节点状态正常了

[root@app1 ~]# cat /proc/drbd    
version: 8.4.3 (api:1/proto:86-101)    
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by gardner@, 2013-11-29 12:28:00    
0: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r-----    
    ns:0 nr:0 dw:0 dr:672 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:604

(2) 重启drbd之后,数据重新同步到从节点

[root@app1 ~]# service drbd reload   
Reloading DRBD configuration: .    
[root@app1 ~]# cat /proc/drbd     
version: 8.4.3 (api:1/proto:86-101)    
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by gardner@, 2013-11-29 12:28:00    
0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r---n-    
    ns:176816 nr:0 dw:0 dr:180896 al:0 bm:10 lo:4 pe:2 ua:8 ap:0 ep:1 wo:d oos:5063296    
        [>....................] sync'ed:  3.4% (4944/5112)M    
        finish: 0:00:57 speed: 87,552 (87,552) K/sec    
[root@app1 ~]# cat /proc/drbd     
version: 8.4.3 (api:1/proto:86-101)    
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by gardner@, 2013-11-29 12:28:00    
0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r---n-    
    ns:3541004 nr:0 dw:0 dr:3545760 al:0 bm:215 lo:2 pe:4 ua:6 ap:0 ep:1 wo:d oos:1700480    
        [============>.......] sync'ed: 67.6% (1660/5112)M    
        finish: 0:00:23 speed: 71,780 (69,368) K/sec    
[root@app1 ~]# cat /proc/drbd     
version: 8.4.3 (api:1/proto:86-101)    
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by gardner@, 2013-11-29 12:28:00    
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----    
    ns:5238400 nr:0 dw:0 dr:5239072 al:0 bm:320 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0    
[root@app1 ~]#

本文出自 “koumm的linux技术博客” 博客,请务必保留此出处http://koumm.blog.51cto.com/703525/1769112

时间: 2025-01-25 09:22:42

记一次DRBD Unknown故障处理过程的相关文章

拿来主义往往束缚人们对新事物的研究与发现 - 记于 OpenGLES 模型移动研究过程中的感悟

拿来主义往往束缚人们对新事物的研究与发现 - 记于 OpenGLES 模型移动研究过程中的感悟 太阳火神的美丽人生 (http://blog.csdn.net/opengl_es) 本文遵循"署名-非商业用途-保持一致"创作公用协议 转载请保留此句:太阳火神的美丽人生 -  本博客专注于 敏捷开发及移动和物联设备研究:iOS.Android.Html5.Arduino.pcDuino,否则,出自本博客的文章拒绝转载或再转载,谢谢合作. OpenGLES 在 iOS 上的研究工作已经持续

记一次Mac mini折腾过程(鼠键共享,更换SSD)

(本文纯属随意记录,也懒得分开来写) 从公司网管那捣鼓来一个"遗弃" Mac mini,说其它人觉得用起来太卡,正好我的工作PC( CPU 4×i3,MEM 8G, HDD 500G)软件开多了也觉得有些卡,特别是我使用浏览器的习惯不太好,每次搜索统一结果都要打开好多标签页对比,文章性质的觉得有用想将来记录下来就没关闭页面,一两个星期下来只Chrome使用的内存就达到4G多.不用也浪费,于是就拿Mac mini分摊一下压力. 刚拿到手时心想得有多不堪配置才使得的Mac mini卡到嫌弃

彷徨中的成长-记一个文科生的IT成长过程

纠结了许久,要不要写这篇文章,然而最终还是写了.就权当总结与呻吟吧..当然,呻吟最开始还是发在自己的站点的,忍不住手贱,还是想发博客园. 1 剧透 人算不如天算:时隔多年,我竟然搞起了前端. 2 发端 7年前,它进入SYSU学习档案管理. 2.1 UG1 大学一年级,上学期,完全是小白!没有任何的计算机专业知识.没有任何相关课程学习.只记得专业课叫机关文件管理,还有高数.前半年过的各种悠闲. 下学期,初识IT:第一门课是4个学分的大学计算机公共基础.这门课只有第一章配得上基础..第二章数字编码与

AIX环境下数据文件ORA-1113故障处理过程

故障环境: AIX5.3 ORACLE10.2.0.3 RAC HA 故障现象: 一.启动RAC单节点异常 $ crs_stat -t Name           Type           Target    State     Host ------------------------------------------------------------ ora....0A.lsnr application    ONLINE    OFFLINE ora.p670a.gsd  app

小麦苗BLOG文章索引

小麦苗BLOG文章索引            自从2014年7月1号开始写blog到2015年5月5日,历时10个月的时间,大概写了90篇文章,这blog多了就乱了,今天抽空出来整理整理,方便大家也方便自己阅读,本文将一直更新,另外,最后我把所有的blog文章全列出来,可能会有用.    小麦苗的所有文章:itpub文章链接-小麦苗.zip     2015年06月03日更新一次,我写的blog数量:109 篇    2015年07月03日更新一次,我写的blog数量:126 篇    2016

站长新手使用服务器须知

从使用虚拟空间到使用独立服务器,这对一个站长来说是一件惊天动地的大事,对于一个没有拿自己电脑做过服务器的站长来说,第一次拿到属于自己的服务器的密码的时候,心情将是无比激动的. 然而,随之而来的诸多问题可能会让你措手不及,一些小的问题是可以预防的. 1.除非你确认自己掌握了,否则不要去试WIN2003的防火墙 WIN2003防火墙打开后,默认是禁止3389端口的,很多站长在启用了防火墙后一重启服务器就再连不上3389了.所以除非你确认自己知道这个防火墙的使用,否则就不要去碰它. 还有的朋友是改了端

无线网络故障自己处理

随着无线的普及,无线网络也进入很多企业的网络部署中.人们在工作中就可以方便.快捷的使用无线网络,享受无线的便捷.可是,有时当你打开电脑,准备在Internet上纵横驰骋,享受一下网络的乐趣时,却发现无线网络怎么也连不上,是不是有些扫兴?可我们总不能一遇到这种问题就吧公司网管找来处理,这种简单的事情还是自己动手吧.以下是本人在使用无线网时碰到的"症状比较典型"一例故障处理,希望能对您处理无线网故障时能有所启发. 某天本本正常开机后,发现无线网卡一直提示"正在连接".检

使用github管理你的代码

关于为什么使用github,网上已经有很多讨论了.当然选择还有google code, Bitbucket,sourceforge.github有如下优势: 1. github更有利于开源项目的发展 source forge并没有充分体现这一点,它更像一个开源软件下载站.至于Google Code,这是个传奇.但是已经被新CEO布林颁布的大扫除政策打死了,属于边缘化业务,Google不会投入新精力了,只是碍于原本有很多项目依旧运行在Google Code上,所以才没有像Google Reader

「技术大牛」是如何缩短事件平均解决时间的?

前不久,我们讨论了运维不容错过的 4个关键指标,其中平均解决时间(MTTR)被认为是衡量业务的最佳标准,随后也分析了「告警等级」对MTTR的重要性. 正确看待 MTTR MTTR 为从故障发生到故障修复所经历的时间.总故障时间是关于告警事件数量与各告警事件时长的函数.经过仔细地探讨这两项因素及其优先级,结合具体情况,总结以下策略用来缩短MTTR: 1)加快工作速度 = 然并卵 如果想通过加快工作速度降低 MTTR,理论上是完美的,但是骨感的现实根本不按我们的剧本走!为了对 MTTR 进行持续的.