记一次DRBD Unknown故障处理过程

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

1, 节点状态查看

(1) 主节点状态

[[email protected] drbd.d]# cat /proc/drbd    
version: 8.4.3 (api:1/proto:86-101)    
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by [email protected], 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    
[[email protected] drbd.d]#

(2) 从节点状态

[[email protected] ~]# cat /proc/drbd    
version: 8.4.3 (api:1/proto:86-101)    
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by [email protected], 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    
[[email protected] ~]#

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

(1) 停止app2 drbd服务

[[email protected] ~]# service drbd stop  
Stopping all DRBD resources: .    
[[email protected] ~]#

(2) 重新初始化元数据

[[email protected] ~]# 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服务

[[email protected] ~]# 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

.  
[[email protected] ~]# cat /proc/drbd   
version: 8.4.3 (api:1/proto:86-101)    
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by [email protected], 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    
[[email protected] ~]#

3. app1主节点下

(1) 主节点状态正常了

[[email protected] ~]# cat /proc/drbd    
version: 8.4.3 (api:1/proto:86-101)    
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by [email protected], 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之后,数据重新同步到从节点

[[email protected] ~]# service drbd reload  
Reloading DRBD configuration: .    
[[email protected] ~]# cat /proc/drbd    
version: 8.4.3 (api:1/proto:86-101)    
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by [email protected], 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    
[[email protected] ~]# cat /proc/drbd    
version: 8.4.3 (api:1/proto:86-101)    
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by [email protected], 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    
[[email protected] ~]# cat /proc/drbd    
version: 8.4.3 (api:1/proto:86-101)    
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by [email protected], 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    
[[email protected] ~]#

时间: 2024-10-26 13:20:12

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

记一次server2008硬盘故障处理过程

server2008系统上安装了金蝶系统,使用mssql2008数据库,系统每日做自动备份.在一次对已备份的数据库目录进行拷贝的时候发现从D盘拷到F盘(第二块硬盘)的时候每次拷了几分钟系统就开始卡了,查看我的电脑发现F盘不见了,查看设备管理器发现第二块硬盘不见了,怀疑是硬盘(线)松动,于是关机,把线重新插了一下,重启,这回F盘重新出来了,再次进行拷贝,又出现上次一样的问题,于是怀疑是硬盘问题(认不到硬盘),于是再次关机,再次启动,进bios模式,发现第二块硬盘有被认到,然后继续进系统,进到桌面,

【故障处理】一次RAC故障处理过程

[故障处理]一次RAC故障处理过程 1.1  故障环境介绍 项目 source db db 类型 2节点RAC db version 11.2.0.1.0 db 存储 ASM OS版本及kernel版本 RHEL 6.6 1.2  故障处理过程 晚上10点多,一个网友喊我帮忙处理RAC宕机不能启动的问题,并且告知涉及到多路径和存储的事.小麦苗对存储一向不太懂,多路径也没怎么接触,自己也没研究过这个东西.既然找到了我,那就不能不管啊,硬着头皮上去看看.结果悲催了,搞了N个小时,求助了N个人,搞到第

记一次数据库调优过程(IIS发过来SQLSERVER 的FETCH API_CURSOR语句是神马?)

记一次数据库调优过程(IIS发过来SQLSERVER 的FETCH API_CURSOR语句是神马?) 前几天帮客户优化一个数据库,那个数据库的大小是6G 这麽小的数据库按道理不会有太大的性能问题的,但是客户反应说CPU占用很高,经常达到80%~90% 我检查了任务管理器,确实是SQLSERVER占的CPU 而服务器的内存是16G内存,只占用了7G+ 客户的环境: Windows2008R2 SQLSERVER2005 SP3 64位 企业版 服务器内存:16G CPU:8核 RDS:阿里云主机

解决drbd Unknown 问题:

解决drbd Unknown 问题: cs:StandAlone ro:Secondary/Unknown ds:UpToDate/DUnknown   r----- 方法一: 在选定的非主节点上执行 drbdadm secondary data drbdadm -- --discard-my-data connect mysql 主节点上执行 drbdadm connect data 如果以上方法不行: 重新初始化 drbdadm detach data ###dd if=/dev/zero

记一次OOM查询处理过程

记一次OOM查询处理过程 问题的爆出及分析排查现场 排查后的解决方案 项目的jvm参数 总结 一.问题的爆出及分析排查现场 服务偶尔会出现不可用的情况,导致出现time out,然后我迅速登录现场,直接查看当时的gc日志,不废话,直接上图 通过这个图可以发现在10点7分.8分的时候频繁Full GC,但是GC之后 年轻代,老年代并没有少.并且Full GC时长5s8多,造成stop-the-world5s8,因此应用程序会出现无影响.再贴一张图 通过这个可以看到内存慢慢的通过GC降下来了 根据这

基于CentOS6.7的DRBD安装配置过程详解

一.DRBD简介 DRBD的全称为:Distributed ReplicatedBlock Device(DRBD)分布式块设备复制,DRBD是由内核模块和相关脚本而构成,用以构建高可用性的集群.其实现方式是通过网络来镜像整个设备.你可以把它看作是一种网络RAID.它允许用户在远程机器上建立一个本地块设备的实时镜像. 二.DRBD是如何工作的呢? (DRBD Primary)负责接收数据,把数据写到本地磁盘并发送给另一台主机(DRBD Secondary).另一个主机再将数据存到自己的磁盘中.目

记一次PHP项目部署过程

首先介绍一下项目的基本情况:使用PHP语言开发,数据库用的是MySQL 5.5,HTTP服务器用的是Apache 2.2.早上十点到机房看了看服务器的基本情况:Windows 2000操作系统,没有安装Apache,没有php,幸好已经安装了MySQL数据库,替我省了点事.不过开心得有点太早了,机房老师告诉我她也不知道MySQL的登录密码.没有密码我的项目就没法连接数据库了,基本上等于废了.重装MySQL也没用,因为删除MySQL后原来的密码还是会保留在系统中,如果要修改密码,还是需要输入原来的

记一次内存泄露优化过程

背景 项目目前存在使用久了或者重复打开关闭某个页面,内存会一直飙升,居高不下,频繁发生GC.静置一段时间后,情况有所改善,但是问题依旧明显,如图1-1.1-2. 图1-1.操作时的内存使用情况 图1-2.静置时的内存使用情况 如上图1-1,是通过Android Studio查看内存(灰色)和CPU(红色)使用情况,可以看出内存有发生抖动并且是处于比较高的状态,再者,从logcat可以看到一直发生GC,如下图1-3: 图1-3. 出现这些情况,是有很多因素造成的,最主要的原因是发生了内存泄露:页面

斩获新知——记一次reverse的实现过程

最近学习C++,在实现reverse函数的时候,从一个小问题开始,在对这个问题的旁敲侧击当中带起了更多疑惑,顺藤摸瓜之后,尽管没有将诸多问题完美解答,但整个过程下来却也觉得似有所获.最初的问题起自于使用C++实现reverse模板函数时碰到的swap问题,随之在翻查STL中reverse源码的实现过程当中产生了其他疑问,如__ITERATOR_CATEGORY,__VALUE_TYPE,__STL_REQUIRES宏的作用,do...while(0)技巧.之后在查找一些资料之后总算对这些问题都有