Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
I was creating a new resource on our servers and ended up in an interesting state and I'm wondering if DRBD (8.3.12) just handles this correctly, or if this is bad. I created a stacked resource on server1, using steps like this: 1) created an lvm to back the resource lvcreate -n store1 -L 2048g backingvg 2) added the resource configuration to /etc/drbd.d directory for both the lower and upper resources and copied the config to the other nodes. 3) ran drbdadm create-md on the lower resource: drbdadm create-md store1_lower 4) brought up the lower device: drbdadm up store1_lower 5) made the resource primary: drbdsetup /dev/drbd1 primary -o 6) ran drbdadm create-md on the upper resource: drbdadm --stacked create-md store1 7) brought up the upper resource: drbdadm up --stacked store1 8) made the upper resource primary: drbdsetup /dev/drbd11 primary -o 9) formatted the upper resource: mkfs.ext4 /dev/drbd11 It should be noted that all my other resources are primary on the other node (server2), I thought it would be less risky to work on this on the non-active node initially. I used a different ip for the stacked ip than my active nodes while configuring it on server1. After getting the resource formatted I stopped all the resources, edited the config to use the same ip I use for the stacked ip on the rest of my resources and then just brought up the lower resource and left it secondary. next on server2 I did steps 1, 3 and 4 to bring up the resource and let it start syncing. So at this point i have the resource secondary/UpToDate on server1. Then, just to see if it would, I tried to make the resource primary on server2. To my surprise drbd happily made the resource primary on server2! I didn't issue the drbdsetup command that forces it primary as above, I only issued the standard command: drbdadm primary storage1_lower Intrigued, I went ahead and brought up the upper resource and made it primary also. I then brought up the resource on the remote node (storage3) and let it start syncing. So, now i have the following: server1: 1: cs:SyncSource ro:Secondary/Primary ds:UpToDate/Inconsistent C r----- server2: 1: cs:SyncTarget ro:Primary/Secondary ds:Inconsistent/UpToDate C r----- server2: 11: cs:SyncSource ro:Secondary/Secondary ds:UpToDate/Inconsistent A r----- server3: 11: cs:SyncTarget ro:Secondary/Secondary ds:Inconsistent/UpToDate A r----- So, my question is, did i just bork the resource totally and I should start over, or is DRBD smart enough to handle this situation by grabbing data not yet synced to server2 from server1 if it is accessed, and updating data on server1 if it is written to the primary on server2? I did make the upper resource primary and mounted it on server2, just to see if I could, and it worked also. Since the drive is empty all i could see was the lost and found directory. -- View this message in context: http://old.nabble.com/resource-Primary-but-inconsistent-tp33903255p33903255.html Sent from the DRBD - User mailing list archive at Nabble.com.