Re: [DRBD-user] Data consistency question

[Lars Ellenberg]

On Tue, Mar 13, 2018 at 10:23:25AM +, Ondrej Valousek wrote:
> Hi list,
> 
> I have a question regarding filesystem consistency - say I choose
> async protocol (A) and the master peer node crashes fatally in the
> middle of write operation.
>
> The slave peer node will then be outdated, but what happens to the
> filesystem on the top of the replicated block device - will I be able
> to restore data from the outdated peer?
> 
> My understanding is that DRBD completely ignores the filesystem, so
> unless I choose synchronous replication protocol C, filesystem
> corruption can occur on the peer node.
> 
> Am I right?

No.

If you "fatally" lose your primary while the secondary is "sync target,
inconsistent", then yes, you have lost your data.
That's why we have the "before-resync-target" handler, where you could
snapshot the last consistent version of your data, before becoming sync target.

If you "fatally" lose your primary during normal operation
(which is: live replication, no resync),
depending on protocol in use, the disk on the secondary will
possibly not have seen those writes that where still in flight.

Which in "synchronous" mode (protocol C) will be only requests that have
not been completed to upper layers (the file system, the data base, the
VM) yet, so it would look just like a "single system crash".

In "asynchronous" mode (protocol A), that will be a few more requests,
some of which may have already been completed to upper layers.

Clients that have committed a transaction, and already got an
acknowledgement for that, may be confused by the fact that the most
recent few such transactions may have been lost.

That's the nature of "asynchronous" replication here.

Going online with the Secondary now will look just like a "single system
crash", but like that crash would have happened a few requests earlier.

It may miss the latest few updates.
But it will still be consistent.

-- 
: Lars Ellenberg
: LINBIT | Keeping the Digital World Running
: DRBD -- Heartbeat -- Corosync -- Pacemaker

DRBD® and LINBIT® are registered trademarks of LINBIT
__
please don't Cc me, but send to list -- I'm subscribed
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] Unable to init a node

[Yannis Milios]

>>  root@dmz-pve1:~ # modinfo drbd
>> filename:   /lib/modules/4.13.13-6-pve/kernel/drivers/block/drbd/
drbd.ko
>> alias:  block-major-147-*
>> license:GPL
>> version:8.4.7   < (this is wrong!)


Since version 5, PVE ships with drbd8 kernel module (see version section
above) . That's the reason you're getting errors during drbd cluster
initialization.
You will have to install drbd-dkms package from Linbit's repository in
order to get drbd9 kernel module installed. Make sure you install
pve-headers-x package before doing that, otherwise drbd9 kernel module
will fail to build.

Y
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

[DRBD-user] Data consistency question

[Ondrej Valousek]

Hi list,

I have a question regarding filesystem consistency - say I choose async 
protocol (A) and the master peer node crashes fatally in the middle of write 
operation.
The slave peer node will then be outdated, but what happens to the filesystem 
on the top of the replicated block device - will I be able to restore data from 
the outdated peer?

My understanding is that DRBD completely ignores the filesystem, so unless I 
choose synchronous replication protocol C, filesystem corruption can occur on 
the peer node.

Am I right?
Thanks,

Ondrej

-

The information contained in this e-mail and in any attachments is confidential 
and is designated solely for the attention of the intended recipient(s). If you 
are not an intended recipient, you must not use, disclose, copy, distribute or 
retain this e-mail or any part thereof. If you have received this e-mail in 
error, please notify the sender by return e-mail and delete all copies of this 
e-mail from your computer system(s). Please direct any additional queries to: 
communicati...@s3group.com. Thank You. Silicon and Software Systems Limited (S3 
Group). Registered in Ireland no. 378073. Registered Office: South County 
Business Park, Leopardstown, Dublin 18.
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] Unable to init a node

[Jean-Daniel TISSOT]

And i forget, I get the same result


Le 13/03/2018 à 16:57, Jdt a écrit :
>
> Le 13/03/2018 à 16:21, Roland Kammerer a écrit :
>
>> On Tue, Mar 13, 2018 at 04:07:17PM +0100, Jdt wrote:
>>> Hi,
>>>
>>> We had a three nodes Proxmox cluster in V4 (jessie) with drbd from Proxmox.
>>> I choose to reinitialize this cluster with Proxmox V5 (stretch) with
>>> drbd from Linbit.
>>>
>>> I install Proxmox from the ISO image on the three nodes. Proxmox nodes
>>> are not associated yet in a cluster.
>>> I install drbdmanage-proxmox as indicated in
>>> https://docs.linbit.com/docs/users-guide-9.0/#ch-proxmox
>>> My network interfaces are well configured for drbd.
>>> On the first node I create the drbdpool volume group as indicated in
>>> https://docs.linbit.com/docs/users-guide-9.0/#s-dm-init-cluster
>>>
>>> But it's failed in initialization :
>>> root@dmz-pve1:~ # drbdmanage init 192.168.2.10
>>>
>>> You are going to initialize a new drbdmanage cluster.
>>> CAUTION! Note that:
>>>   * Any previous drbdmanage cluster information may be removed
>>>   * Any remaining resources managed by a previous drbdmanage installation
>>>     that still exist on this system will no longer be managed by drbdmanage
>>>
>>> Confirm:
>>>
>>>   yes/no: yes
>>> Error: External command failed:
>>> drbdsetup new-resource .drbdctrl 0
>>> Command output:
>>>   (stdout)
>>> Command exited with exit_code 20
>>>
>>> Initialization failed
>> Failing at that early stage usually means that the wrong module is
>> loaded. cat /proc/drbd
> root@dmz-pve1:~ # cat /proc/drbd
> version: 8.4.7 (api:1/proto:86-101)
> srcversion: 2DCC561E7F1E3D63526E90D
>
>>> In /etc/drbdmanaged.cfg, I have
>> You should not.
> Ok, I reinstall
>
> root@dmz-pve1:~ # modinfo drbd
> filename:  
> /lib/modules/4.13.13-6-pve/kernel/drivers/block/drbd/drbd.ko
> alias:  block-major-147-*
> license:    GPL
> version:    8.4.7
> description:    drbd - Distributed Replicated Block Device v8.4.7
> author: Philipp Reisner , Lars Ellenberg
> 
> srcversion: 2DCC561E7F1E3D63526E90D
> depends:    lru_cache,libcrc32c
> retpoline:  Y
> intree: Y
> name:   drbd
> vermagic:   4.13.13-6-pve SMP mod_unload modversions
> parm:   minor_count:Approximate number of drbd devices (1-255)
> (uint)
> parm:   disable_sendpage:bool
> parm:   allow_oos:DONT USE! (bool)
> parm:   proc_details:int
> parm:   usermode_helper:string
>
> root@dmz-pve1:~ # cat /etc/drbdmanaged.cfg
> [LOCAL]
> storage-plugin = drbdmanage.storage.lvm_thinlv.LvmThinLv
> force=1
> root@dmz-pve1:~ # lsmod | grep drbd
> drbd  360448  0
> lru_cache  16384  1 drbd
> libcrc32c  16384  2 dm_persistent_data,drbd
>
>
>
>>
>> If you don't have "force" set, most of them are ignored. Having options
>> per node, per config files isn't possible for years. As I don't see
>> "force", but your "custom options", that indicates to me that you did
>> not use our version of drbdmanage for proxmox, which sets up
>> drbdmanaged.cfg correctly, or you just overwrote what was in it with
>> what you thought is a good idea. Unfortunately, it was not a good
>> idea...
>> Regards, rck
>> ___
>> drbd-user mailing list
>> drbd-user@lists.linbit.com
>> http://lists.linbit.com/mailman/listinfo/drbd-user
> Regards, JdT
>
>
> ___
> drbd-user mailing list
> drbd-user@lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user

-- 
Bien cordialement, Jean-Daniel TISSOT

Administrateur Systèmes et Réseaux
Tel: +33 3 81 666 440 Fax: +33 3 81 666 568

Chrono-environnement

Laboratoire Chrono-environnement

16, Route de Gray
25 030 BESANÇON Cedex

Plan et Accès

___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user