<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>Possible DRBD Desync After Outage - Why?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>Hello:<BR>
<BR>
We have two DRBD machines running RHEL 5.3 with DRBD 8.3.0.&nbsp; Recently, we had an outage that took the primary server in the cluster down, leaving it to failover using DRBD and Heartbeat.&nbsp; This was done with no issues.&nbsp;&nbsp;<BR>
<BR>
When the other server came back online, we initiated a manual resync as follows:<BR>
<BR>
drbdadm secondary RESOURCE<BR>
drbdadm -- --discard-my-data connect RESOURCE<BR>
<BR>
Then from the live server, we did drbdadm connect RESOURCE, and it connected and resynced.<BR>
<BR>
Assuming all this was done right, we ran into other issues - some people have complained that their files have &quot;reverted&quot; to a previous state.&nbsp; We don't show any errors occuring in the synchronization of the files, and never saw any &quot;oos&quot; in the DRBD status.&nbsp;<BR>
<BR>
So how could this have happened?&nbsp; What can be done, outside of regular &quot;drbdadm verify&quot;s, to combat this problem?&nbsp; And honestly, why is it necessary to do manual verification when file integrity of this nature should be a fundamental part of any file system duplication of this nature?<BR>
<BR>
I've attached my drbd.conf here - feel free to mention if I've done something stupid.<BR>
<BR>
resource r1 {<BR>
&nbsp; protocol C;<BR>
&nbsp; handlers {<BR>
&nbsp;&nbsp;&nbsp; pri-on-incon-degr &quot;echo 'DRBD: primary requested but inconsistent!' | wall; /etc/init.d/heartbeat stop&quot;; #&quot;halt -f&quot;;<BR>
&nbsp;&nbsp;&nbsp; pri-lost-after-sb &quot;echo 'DRBD: primary requested but lost!' | wall; /etc/init.d/heartbeat stop&quot;; #&quot;halt -f&quot;;<BR>
&nbsp; }<BR>
<BR>
&nbsp; startup {<BR>
&nbsp;&nbsp;&nbsp; degr-wfc-timeout 120;&nbsp;&nbsp;&nbsp; # 2 minutes.<BR>
&nbsp;&nbsp;&nbsp; wfc-timeout 120;&nbsp;&nbsp;&nbsp; # 2 minutes.<BR>
&nbsp; }<BR>
<BR>
&nbsp; disk {<BR>
&nbsp;&nbsp;&nbsp; no-disk-flushes;<BR>
&nbsp;&nbsp;&nbsp; on-io-error&nbsp;&nbsp; detach;<BR>
&nbsp; }<BR>
<BR>
&nbsp; net {<BR>
&nbsp;&nbsp;&nbsp; timeout 120;<BR>
&nbsp;&nbsp;&nbsp; connect-int 20;<BR>
&nbsp;&nbsp;&nbsp; ping-int 20;<BR>
&nbsp;&nbsp;&nbsp; max-buffers&nbsp;&nbsp;&nbsp;&nbsp; 2048;<BR>
&nbsp;&nbsp;&nbsp; max-epoch-size&nbsp; 2048;<BR>
&nbsp;&nbsp;&nbsp; ko-count 30;<BR>
&nbsp;&nbsp;&nbsp; cram-hmac-alg &quot;sha1&quot;;<BR>
&nbsp;&nbsp;&nbsp; shared-secret &quot;******&quot;;<BR>
&nbsp;&nbsp;&nbsp; after-sb-0pri disconnect;<BR>
&nbsp;&nbsp;&nbsp; after-sb-1pri disconnect;<BR>
&nbsp;&nbsp;&nbsp; after-sb-2pri disconnect;<BR>
&nbsp; }<BR>
<BR>
&nbsp; syncer {<BR>
&nbsp;&nbsp;&nbsp; rate 30M;<BR>
&nbsp;&nbsp;&nbsp; al-extents 503;<BR>
&nbsp;&nbsp;&nbsp; verify-alg sha1;<BR>
&nbsp; }<BR>
<BR>
&nbsp; on SERVER1 {<BR>
&nbsp;&nbsp;&nbsp; device&nbsp;&nbsp;&nbsp; /dev/drbd1;<BR>
&nbsp;&nbsp;&nbsp; disk&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /dev/sda7;<BR>
&nbsp;&nbsp;&nbsp; address&nbsp;&nbsp; 172.16.2.1:7789;<BR>
&nbsp;&nbsp;&nbsp; meta-disk /dev/sda6[1];<BR>
&nbsp; }<BR>
<BR>
&nbsp; on SERVER2 {<BR>
&nbsp;&nbsp;&nbsp; device&nbsp;&nbsp;&nbsp; /dev/drbd1;<BR>
&nbsp;&nbsp;&nbsp; disk&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /dev/sda7;<BR>
&nbsp;&nbsp;&nbsp; address&nbsp;&nbsp; 172.16.2.2:7789;<BR>
&nbsp;&nbsp;&nbsp; meta-disk /dev/sda6[1];<BR>
&nbsp; }<BR>
}</FONT>
</P>

</BODY>
</HTML>