No Sir.
What if the Primary dies? Hard?
You now want your Secondary to take over, no?
Well, you cannot anymore. Because it is not Connected.
How could it, you just lost the peer ;-)
Don't focus only on one specific scenario.
Because, if you just "fix" that specific scenario,
you break
On Mon, Sep 06, 2010 at 10:02:51PM +0800, jan gestre wrote:
> On Mon, Sep 6, 2010 at 8:48 PM, Lars Ellenberg
> wrote:
> > On Mon, Sep 06, 2010 at 08:34:40PM +0800, jan gestre wrote:
> >> Hi Everyone,
> >>
> >> I've found this drbddisk modification
guments for your setup.
Or, well, remember what you did differently
on the "identical system that works" (TM).
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
On Mon, Sep 06, 2010 at 04:37:07PM -0400, Jean-Francois Malouin wrote:
> * Lars Ellenberg [20100906 16:05]:
> > On Mon, Sep 06, 2010 at 01:46:46PM -0400, Jean-Francois Malouin wrote:
> > > Hi,
> > >
> > > On a Debian/squeeze system running 2.6.32-5-xen-amd6
) in inode 28: 1233 1249 1251 1252
> Multiply-claimed block(s) in inode 1183: 1251 1252
> Multiply-claimed block(s) in inode 1184: 1233
> Multiply-claimed block(s) in inode 1185: 1249
>
> When fsck -fy is run on /repl partition then the end result is content of
> file x
> > Multiply-claimed block(s) in inode 28: 1233 1249 1251 1252
> > > Multiply-claimed block(s) in inode 1183: 1251 1252
> > > Multiply-claimed block(s) in inode 1184: 1233
> > > Multiply-claimed block(s) in inode 1185: 1249
> > >
> > > When fsck -fy
On Tue, Sep 07, 2010 at 03:15:07PM +0200, Lars Ellenberg wrote:
> On Tue, Sep 07, 2010 at 12:12:08PM +, putcha narayana wrote:
> >
> > Thanks for responding,
> >
> >
> >
> > FYI: I have ran stat command to get details of the files whose data is
>
BD layer.
There are no partial writes on the DRBD layer. And I'm not sure what
you mean with "lock the disk" in this context, either.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are register
On Wed, Sep 08, 2010 at 01:31:02PM +0200, Eric Deschamps wrote:
> Hi list!
>
> I am trying to sync KVM virtual machines located on LVM spaces.
>
> The first host is a ubuntu 8.04 amd64 server (host 1) and the second is
> a ubuntu 10.04 amd64 server, both with original kernels. Drbd api are
> not
at that point anymore,
so whatever was accessing sdb1 had a short life.
> and the above message never comes before today.
> likewise the above message didn't came on the other node(node2)
Likely something triggered through udev (or other) had sdb1 open at that time.
It impossible to determin
> }
>
> disk {
> fencing resource-only;
> }
> }
>
> resource r0 {
> device/dev/drbd1;
> meta-disk internal;
> on mirror1 {
> disk /dev/sda7;
> address
evices available and format
> them from the VM host?
In this case, I think it does not make much difference.
> Anything else I need to be aware of ?
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and
et.
So no, if you run PostgreSQL on disks with volatile caches,
and you unplug the power hard, you can expect data loss
and possibly data corruption.
Which is completely independend of DRBD.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and co
g is the huge latency I suffer using flushes in my setup
> where I run several virtual KVM instances in DRBD containers without
> BBU RAID. These virtual systems frequently flush disks and these
> operations occasionally queue up to a substantial epoch of 100 or even
> higher.
Try dis
ut you can have drbd.conf differ in that setting on both nodes.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don
d automatically or is it something more involved?
> (Last time I looked at iSCSI I'm sure you had to completely re-export
> all your LUNs any time you wanted to add/remove one)
Just the same as if you had a single iSCSI server without DRBD
crashing and rebooting.
Only faster.
--
: La
> patients
>
>
> intranet
>
>
See how not one of them references DRBD,
but all directly use the lower level LVs directly?
If you bybass DRBD, you cannot expect it to magically know
about, and sync, your changes.
--
: Lars Ellenberg
: LINBIT | Your W
On Wed, Sep 08, 2010 at 04:53:12PM +0200, Eric Deschamps wrote:
> Le 08/09/2010 16:30, Lars Ellenberg a écrit :
>
> >
> > See how not one of them references DRBD,
> > but all directly use the lower level LVs directly?
> >
> > If you bybass DRBD, you cannot e
gt; Is that normal?
Yes.
In a newer version of that resource agent it uses some "quiet" flag in
the invokation of crm_master (which is the wrapper around crm_attribute,
which is logging this).
In a newer version of pacemaker, crm_attribute even keeps quiet
when someone uses that flag ;-)
-
Sam.
> >Before you ran that, did you verify that both disks were attached? If
> >one of them still showed Diskless, it won't work.
>
> Ok but I run DRBD v8.3.7 (both side) and lot of command from the
> http://www.drbd.org/docs/ are changed (it seems) as "drbdadm --
> --cl
to try and promote
whatever is configured?
> and I had to manually issue the
> "drbdadm primary" command on server-1.
> It did work, not a big deal, but it would be better if this can work as
> expected.
>
> Could be due to some settings in the drbd.conf?
>
3.28 0.253 0.262
>
> There is a significant (50-100%) increase in bandwidth and decrease in
> latency using SDP instead of IPoIB, so even though IPoIB works I'd like to
> use the SDP method.
Share your findings on DRBD performance IPoIB vs. SDP,
once you get the thing to
/Articles/399148/
http://www.spinics.net/lists/linux-scsi/msg44074.html
Maybe disable the drbd level checksum, and trust the TCP checksum.
> If not, are you planning to implement this feature?
Maybe.
But it does not have particular priority.
Maybe we rather wait for the VM and VFS layer to fix
On Fri, Sep 17, 2010 at 05:28:44PM +0200, Fabrice Charlier wrote:
> On 09/17/2010 02:40 PM, Lars Ellenberg wrote:
>
> >Maybe disable the drbd level checksum, and trust the TCP checksum.
>
> And take the risk of corrupt one mirror? ;-)
>
> >>If not, are you plan
scaled better, though.
But please go ahead and tune your stack, on your hardware, which may be
more capable than the test lab hardware we used.
Depending on your hardware, and the quality recommendations of
your SDP tuning expert, your findings may be different.
--
: Lars Ellenberg
: LINBIT |
akes it really easy to measure the
> time that it takes. just do `time cp /path/to/large/file
> /mnt/new/path/to/large/file`. the write operations in the cp wont
> complete until the data is on both disks.
Uhm... page cache...
rather do a "time cp $source $sink ; time sync",
d21ca97d74cdc4fb27285;hb=68ee998421a014e931b398ed21fd738c9e9a5d12#l322
(That url is ugly, I meant to say look at lines around 322 in that script.)
We start with a timeout of 1 second,
apparently that is not enough in your setup to get an answer.
If the message disturbs you, feel free to inc
modify the metadata
with drbdmeta show-gi/set-gi).
You should definetly not automate this, as it would render all the
effort we do to "outdate" disconnected secondaries useless.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http:/
this message, or read the whole thread.
Date: Thu, 5 Aug 2010 14:40:56 +0200
From: Lars Ellenberg
u are doing is unplug an iSCSI cable.
But in general, if anything happens at all, you get high load on either
the network or the initiators or the targets or the replication link
or anything more interesting breaks, then I certainly don't want to be
the one cleaning up the mess.
I strong
- drbd-8.3.7/user/Makefile.in.orig2010-01-13 17:04:50.0 +0100
> +++ drbd-8.3.7/user/Makefile.in 2010-09-25 12:26:17.963038793 +0200
> @@ -98,23 +98,24 @@ distclean: clean
>
> install:
> ifeq ($(WITH_UTILS),yes)
> - install -d $(DESTDIR)/sbin/
> +
Your setup is broken somewhere.
Maybe show the xml definition of your xen resource,
of the pacemaker config,
and the drbd config,
and someone can point out what you did wrong.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD®
5 /var/lib/xen/images/trnagios/disk0
> virtual-n1:~ # xm create trnagios
> virtual-n1:~ # ssh trnagios
> Password:
>
> :D :D :D I'm sooo happy :). I thought I can trust yast in starting the vm
> after unclean cut. But this doesn't work... I'm fine with this solu
;, and
to resolve it would also require a full resync.
You will NOT get any incremental resync here.
We have that feature on the roadmap, though,
we call it "More than two nodes in one level".
Feature sponsoring accepted ;-)
--
: Lars Ellenberg
: LINBIT | Your Way to High Availa
GPL
> version:8.3.2
Please use 8.3.8.1,
iirc, we fixed some bugs in some code paths with online verify since 8.3.2.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered tradem
On Mon, Oct 11, 2010 at 05:02:40PM +0200, Fabrice Charlier wrote:
> On 10/11/2010 04:02 PM, Lars Ellenberg wrote:
>
> >Would have been useful to post that nice kernel panic message here.
>
> http://img176.imageshack.us/img176/5827/11102010.jpg
Ok, the interesting part is
:d
int crypto_tfm_alg_min_keysize(struct
> crypto_tfm *tfm)
> 290 {
>
> We do an online verify each night.
> Does not reproduce since.
As long as it does not reproduce, we cannot really fix it.
Give us a reproducer, and we'll fix it.
> Slightly changed config now.
tmap.o drbd_proc.o
> +drbd-y += drbd_worker.o drbd_receiver.o drbd_req.o drbd_actlog.o
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austr
=
> > to suppress the warnings.
>
> hi,
>
> what about my suggestion? what objections do you have to not apply
> it for drbd 8.3.9?
I just committed something similar to that.
Should be pushed to public "soon".
Will be in 8.3.9.
--
: Lars Ellenberg
: LINBIT | Yo
etter yet, _package_ drbd as .rpm or .deb,
which will do the configure properly for you anyways.
I'm very much unsure if DRBD will function properly
if you deviate from that. It may.
We certainly do not test any other locations.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
:
On Wed, Oct 20, 2010 at 01:42:37PM +0200, r...@q-leap.de wrote:
> >>>>> "Lars" == Lars Ellenberg writes:
>
> Lars> On Mon, Oct 18, 2010 at 12:47:14PM +0200, r...@q-leap.de wrote:
> >> Also there were two issues when compiling the kernel mod
On Wed, Oct 20, 2010 at 04:33:30PM +0200, r...@q-leap.de wrote:
> >>>>> "Lars" == Lars Ellenberg writes:
>
> >> Build automagic of who? The kernel? When I apply the patch generated by
> >> make kernel-patch and compile I get a "B
So if you have stonith enabled, and you want to protect against being
shot while modifying data, you should say "resource-and-stonith".
What exactly do you want to solve?
Either you want to avoid going online with stale data,
so you place that contraint, or use dopd, or some similar mechanis
|| echo n)
+ CONFIG_DRBD_TRACE := $(shell test $${SUBLEVEL} -ge 30 && test $${SUBLEVEL}
-lt 35 && echo m || echo n)
include $(DRBDSRC)/Makefile-2.6
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
FIG_DRBD_TRACE := $(shell test $${SUBLEVEL} -ge 30 && echo m || echo n)
+ CONFIG_DRBD_TRACE := $(shell test $${SUBLEVEL} -ge 30 && test $${SUBLEVEL}
-lt 35 && echo m || echo n)
include $(DRBDSRC)/Makefile-2.6
--
: Lars Ellenberg
: LINBIT | Your Way to High Availabili
.739628] [ cut here ]
>
>
> I don't get any message like this on real hardware.
>
> This is absolutely reproducable and still exists in git head
> (drbd-8.3.9-5-g7fed7c2).
>
> It didn't exist in 8.3.8.1.
>
> Except for the warn
> Appricated you help us to understand what's the error 20 meaning? How
> could it happen?
Do you have any further logs, kernel or other, from the time period in question?
Or sysstat like info about the general workload at that time?
Was the system particularly busy at the times wh
On Tue, Nov 09, 2010 at 10:08:55AM +, putcha narayana wrote:
>
>
> Hi
>
> Can someone please respond to my request.
Upgrade drbd.
If it is still reproducable, post again.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http:/
On Mon, Nov 08, 2010 at 08:10:31AM -0800, fibrer...@gmail.com wrote:
> Hi Lars,
>
> Despite this patch, compiling still fails on Ubuntu Maverick (10.10).
> Can you advise?
Works for me, though.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and con
ny small files from an NFS-client, has
> decreased drastically.
Then read about the disk settings no-disk-barrier, no-disk-flushes,
no-md-flushes, which did not exist in 0.7, and have performance impact.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consult
gt;mount: unknown filesystem type 'drbd'
how about
mount -t ext4 -o your,favorite,mount,options /dev/$vg/$snap_lv /mnt/point
(or ext3 or xfs or whatever it is you are actually using?)
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting ht
Sorry this post spent so much time in some moderation queue,
apparently you don't post from your subscription address,
or you are not subscribed. Anyways, see below.
On Tue, Nov 09, 2010 at 05:40:02PM +0100, Thomas Vögtle wrote:
> Lars Ellenberg wrote:
> >
> > If your kern
do with DRBD or its fencing scripts.
> Is this supposed to work by automatically unfencing the peer?
> Is there something I'm doing wrong here?
Do you need to reset the fault status of your rings on the remaining
node using corosync-cfgtool? Corosync apparently does not heal itself,
but needs a
q, what);
> + spin_lock_irqsave(&mdev->req_lock, flags);
> + __req_mod(req, what, &m);
> + spin_unlock_irqrestore(&mdev->req_lock, flags);
> +
> + if (m.bio)
> + complete_master_bio(mdev, &m);
> }
>
> int w_read_retry_r
,
but they should no longer show up in drbd-overview.
> DRBD seems to be holding the associated devices in use so I cant remove
> them from devmapper.
That is nonsense, I dare say.
If its "Diskless", it does not hold anything in use.
So whatever keeps you from removing things from
e looked in the messages log but haven't found anything, is there
> another log I should be reviewing?
>
> Thanks in advance for any insight into this.
>
> Sean
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbi
rnel sources
already containing drbd.
Or just use the one shipped with 2.6.35.
You should use a DRBD userland with the same version as your kernel module.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are r
: Unrelated data, aborting!
Still cryptic?
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list
dhat/RPMS/x86_64/drbd-xen-8.3.9-1.x86_64.rpm
> /usr/src/redhat/RPMS/x86_64/drbd-utils-8.3.9-1.x86_64.rpm
>
> The one rgmanager is not there, but all the other ones that I don't want. Why?
does
make rpm "RPMOPT=--with rgmanager"
give you the desired result?
--
: Lars Ellenbe
setting up my network. I am using ubuntu 10.4
> machines as my nodes and I want to integrate drbd with pacemaker.
>
> Regards,
> --
> Amir
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are register
On Tue, Nov 23, 2010 at 11:55:17AM -0800, chambal wrote:
> When I do "smartctl -a /dev/sda" on this system, it usually
> triggers errors in the system log.
Wrong list?
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbi
n the DRBD device (on the
> master) become unaccessible.
> Is this a known issue ?
Sorry. What exactly is the issue?
What do you mean by "become unaccessible"?
> My 10Gb cards seems to work fine apart from this.
>
> Should I try syncing over Gb links ?
--
: Lars Elle
after a week like a
> teenager with
> the 20's oder 30's?
It's a mostly cosmetic issue, and has since been fixed.
Upgrade your kernel module.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consult
imary is not a very good idea.
Also, dual-primary mode of drbd does not necessarily add to your
availability, so think twice if you really need it.
We may add some workarounds in later versions of DRBD (copying
all data to private pages first, before we further process it),
which will obviously have addi
on top of iSCSI,
and of course you can have iSCSI on top of a failover DRBD cluster.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc
supported?
>
>
> So, is anyone using this successfuly? Is this a bug or ramdisks are
> really not supported?
Worked for me last time I tried.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered tra
ned in degr-wfc-timeout.
See if my post
[DRBD-user] DRBD Failover Not Working after Cold Shutdown of Primary
dated Tue Jan 8 11:56:00 CET 2008 helps.
http://lists.linbit.com/pipermail/drbd-user/2008-January/008223.html
and other archives
BTW, that setting only affects drbdadm/drbdsetup wait-connect
or ?
Because you do not have access to up-to-date data.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but
On Fri, Dec 03, 2010 at 05:12:23PM +, Andrew Gideon wrote:
> On Fri, 03 Dec 2010 09:43:11 +0100, Lars Ellenberg wrote:
>
> > See if my post
> > [DRBD-user] DRBD Failover Not Working after Cold Shutdown of Primary
> > dated Tue Jan 8 11:56:00 CET 2008 helps.
>
On Wed, Dec 01, 2010 at 08:53:58PM +0100, Florian Haas wrote:
> On 12/01/2010 08:27 PM, Laurent CARON wrote:
> > On 29/11/2010 10:57, Lars Ellenberg wrote:
> >> Sorry. What exactly is the issue?
> >> What do you mean by "become unaccessible"?
> >
>
to attach.
Fix that.
Your shutdown process is apparently broken enough to
not really shutdown everything and demote/down DRBD
so it stays Primary. That makes an "orderly" shutdown/reboot
look like a Primary crash to DRBD.
Fix that.
Are you sure that you have been the only one tampering wit
-vienna-cc--manager--templates--drbd
>
> So, I have no idea why, but it seems that if /etc/hosts is broken
> then the symlinks are no available when DRBD starts. When after
> booting up is stop/start the DRBD service, then DRBD attaches to the
> disks fine. Strange.
At best, changin
> into a similar situation?
So as soon as you have upgraded on both sides,
drbd should be able to resolve that.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered
.
I think your experiment is just broken,
and that's certainly not DRBD's fault.
Maybe you overcomitted too much?
> Dec 8 10:27:21 wcluster1 kernel: [ 1721.887452] block drbd2: in
> got_BlockAck:4348: rs_pending_cnt = -1 < 0 !
>
> This last message is repeated many tim
t;
> After that I manually attached the device without problems.
>
> Is this really a problem with a too small device or may it be that
> the device wasn't existing at all?
You have to investigate your boot process more closely then.
It is likely still racy somewhere,
possibly wi
versions would not even have detected it, but more or less
silently skipped the resync (they would have logged some warning about
no resync, but bits in bitmap), because of the identical (ignore the
right most bit) "current" UUIDs, even though there have been "dirty"
bits in
card-least-changes; after-sb-1pri
> discard-secondary;}syncer {rate 100M;al-extents 257;}on pitanga { device
> /dev/drbd0;
> disk /dev/sda7; address
> 10.1.1.50:7788; meta-disk internal;}on inga { device /dev/drbd0;
> disk /dev/sda7; address
> 10.1.1.
tion? or drbd can't be
> configured to resolve this?
http://blogs.linbit.com/florian/2010/10/28/drbd-fsck-dix/
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austr
be wrong, but I suspect you are not using the DRBD kernel
module you think you do. You most likely still use the "drbd 8.0.14"
module "shipped" with lenny. Same for your other oops.
Please "tripple" check.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availabil
you aware of the 8.3.9-y branch?
http://git.drbd.org/?p=drbd-8.3.git;a=shortlog;h=refs/heads/drbd-8.3.9-y
If that does not help, I'd suggest you managed to get a broken build
or drbd (not exactly matching your xen dom0 kernel).
--
: Lars Ellenberg
: LINBIT | Your Way to High Availab
nd what versions have you tried?
> >
> > 8.3.8-1, using the precompiled binary RPMs. I've not tried other
> > revs. I have tried other configurations, all of which seem to
> > lock-up; in one configuration, the drive devices not associated with
> > DRBD get locked
not available at present time. See thread below:
> http://forums.citrix.com/thread.jspa?threadID=279359&tstart=45
>
> FP1 in general has plenty of issues, but that's beyond this topic.
> http://forums.citrix.com/forum.jspa?forumID=503&start=0
> Hope this saves you s
m, the filesystem is no longer
notified implicitly, and even though you don't have to, you may want to
do that explicitly (e.g. using xfs_freeze -f, -u), which of course
needs to be done on the Primary (where it is mounted).
If we are not talking about Filesystems, but anything else (VM images,
use version 8.3.10rc1. While doing
> "service drbd start" on the Xenserver, the drbdadm command crashes
> with that error message:
>
> Jan 10 15:57:50 xs1 kernel: drbd: initialized. Version: 8.3.10rc1
> (api:88/proto:86-96)
> Jan 10 15:57:50 xs1 kernel: drbd: GIT-hash
On Tue, Jan 11, 2011 at 04:58:46PM +0100, Alex Kuehne wrote:
> Quoting Lars Ellenberg :
>
> >On Mon, Jan 10, 2011 at 04:07:12PM +0100, Alex Kuehne wrote:
> >>Quoting Alex Kuehne :
> >>
> >>>Hi guys,
> >>>
> >>>This is another repor
wether using dopd or crm-fence-peer)
is not trivial to get it right. That is partially because what is right
is not clearly defined, and may well change with different requirements.
As I tried to explain in above linked post,
stonith alone does not help, either.
--
: Lars Ellenberg
: LINBIT | Yo
better, it may help knowing that DRBD
will refuse to become synctarget if it is currently primary,
so if you want something to not become synctarget,
it is usually good enough to just keep it primary.
Besides, for all things cluster upgrade,
you could (probably: should) just do a "dry run"
e opencf draft standard. I believe the correct return variable is
> $OCF_SUCCESS.
>
> The redhat implementation of the opencf standard is defined in the
> redhat-provided script /usr/share/cluster/ocf-shellfuncs.
Thanks.
Known and fixed:
http://git.drbd.org/?p=drbd-8.3.git;a=commitdiff;h
s connection).
If you go "crm", please go pacemaker,
not it's >= four years old predecessor.
Thanks,
> > Yes I use heartbeat-2.1.3-3.el5.centos, so I would tell that I'm using
> > heartbeat 2 but with ha.cf config.
Note that ha.cf is always needed.
The differen
having I/O operations occur on the primary device, but does not
> necessarily insure that write operations will not be blocked by Linux
> waiting on them to occur on both volumes.
Not that I'm advocating against DRBD usually, but just make sure you do
not overlook the parts about write-i
ce.
Is that so?
What makes you think so?
> If the primary
> and secondary each served the local drives as targets over SRP (and
> the primary writes as an initiator directly to the secondary's drive),
> for example, the mirror peak write performance could be much higher.
I
ing your disk images
on the iSCSI target host. Not even "read-only loop mount" that stuff,
typically even read-only mounts first replay the journal...
much less start a VM directly from those images. Or the replication
will lose track of blocks in need for resynchronisation.
In other words:
"Nick Couchman" schrieb:
>The naming of the drbd devices seems to be a little picky. I'd like to
>be able to call one /dev/drbd-do-no-use or something like that, but
>drbd
>seems to choke on this and is fairly strict about the drbd
>naming
>scheme.
device name has to be either drbd , or st
connected -> WFConnection )
So... My guess is, that you still have two versions of your data.
>From this log, there was no sync, because DRBD default behaviour in that
case it to disconnect. Therefore no rollback, and no data loss.
But you certainly have diverging data sets, and my gues
ate, that DRBD refused to connect.
If it finnaly synced up and connected anyways, likely someone told it to
"--discard-my-data" on one of the nodes (or "invalidate" or something to
that regard).
And if that has been the side with the data you lost,
well, then that someone told D
other
> erratic behaviour?
It won't cause any harm.
But you should just set cpu-mask ff.
Note that it may take a new write request or other "full round trip"
through all threads to become visible: to avoid locking issues they all
set
-u,
even against a non-xfs file system.
It it much more useful to "quiesce" the application(s)
running on top of that filesystem than the filesystem itself:
if you don't do the former, the latter won't help much,
if you do the former, the latter does not have much to do, anyways.
On Thu, Feb 03, 2011 at 09:55:48PM +0100, Lars Ellenberg wrote:
> On Thu, Feb 03, 2011 at 02:16:08PM -0600, J wrote:
> > On 2/3/2011 1:09 PM, Digimer wrote:
...
> Your question was:
> if I take a snapshot of the logical volume used by
> drbd, will I be able to mount that l
On Thu, Feb 03, 2011 at 03:20:50PM -0600, J wrote:
> On 2/3/2011 2:55 PM, Lars Ellenberg wrote:
> >Don't give up so quickly because of information overload ;-)
> >Your question was:
> > if I take a snapshot of the logical volume used by
> > drbd, will I be
der DRBD, it can cause spurious detaches
on the Secondary, so don't use that either,
unless you absolutely know what you are doing.
> }
>
> This will completely turn off write ordering which. I have measured
> performance gains doing this with backed-up write caches.
--
: Lars Ellenb
1 - 100 of 1385 matches
Mail list logo
