Re: [Samba] ctdb vacuum timeouts and record locks
- Date: Tue, 7 Nov 2017 17:05:27 -0800
- From: Computerisms Corporation via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] ctdb vacuum timeouts and record locks
Thanks for your answer...
I am using the 10.external. ip addr show shows the correct IP addresses
on eth0 in the lxc container. rebooted the physical machine, this node
is buggered. shut it down, used ip addr add to put the addresses on the
other node, used ctdb addip and the node took it and node1 is now
functioning with all 4 IPs just fine. Or so it appears right now.
something is seriously schizophrenic here...
I'm wondering why you're using 10.external. Although we have tested
it, we haven't actually seen it used in production before! 10.external
is a hack to allow use of CTDB's connection tracking while managing the
public IP addresses externally. That is, you tell CTDB about the
public IPs, use "ctdb moveip" to inform CTDB about moved public IPs and
it sends grat ARPs and tickle ACKs on the takeover node. It doesn't
actually assign the public IP addresses to nodes.
Hm, okay, I was clear that using 10.external it is a human's
responsibility to deal with assigning IPs to physical interfaces. In
re-reading the docs, I see DeterministicIPs and NoIPFailback are
required for moveip, which I am not sure are set. will check next
opportunity, if they aren't that might explain the behaviour, however,
the ips were correctly assigned using the ip command.
The reason I am using 10.external is because when I initially set up my
cluster test environment, none of ctdb's automatic networking
assignments worked. ip addr show wouldn't display the addresses as
being assigned to the interface. I never did get down to the bottom of
that problem, I had thought perhaps the lxc container was the issue, but
don't know why it would be, the ip commands all seem to work fine from
While I was trying to find my way around that, I found 10.external. I
found that by adjusting my start scripts to include the appropriate ip
addr add commands, it worked fine. in my test environment I played with
the ctdb addip/delip/moveip commands, and manually assigning the
addresses, and it all worked fine. If I turned off a node, I could
uncomment a couple lines in the start script in the other node and
restart and everything moved to where it was supposed to be.
But not all things have worked in production as they did in my testing
environment, and doesn't always seem to work the same in production from
one time to the next, for that matter...
The documentation might not be clear on this but if you're using
10.external then you need to have the DisableIPFailover tunable set to
1 on all nodes so that CTDB doesn't try to move the IPs itself.
I do have the DisableIPFailover set.
from the documentation, I am under the impression that if I do ctdb
delip on one node, and ctdb addip on the other node, and make sure the
other node shows the correct additional IPs assigned to the physical
interface using the ip addr show command, that should move an ip from
one node to the other. But when I do this, I will frequently still see
messages like <ip> still hosted during callback, or failed to release
<ip> in the logs. sometimes on startup, I will see log entries like
<ip> incorrectly on an interface, when ip addr show shows the address is
correctly on an interface, and ctdb ipinfo will show that the ip is
assigned to the node.
Does this mean these commands are not working, or could it be that the
10.external doesn't do the magic in these cases?
Please let us know if the documentation could be improved...
Often documentation isn't straightforward until you have had some
experience and gained some of context that those who wrote it have. I
am not sure about improving documentation, but I can say I learned
significantly more about how to set things up, what to expect, and what
procedures to perform by reading mailing list posts than I did by
reading the manuals or the wiki...
peace & happiness,
To unsubscribe from this list go to the following URL and read the