Re: recovering DNA ranges

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Nathan Kinder wrote:
On 02/20/2013 02:33 PM, Rob Crittenden wrote:
With DNA configured for allocating POSIX uids with an MMR setup we see
the range split in half with every new replica provisioned. This is
expected.

It appears that if a replica is deleted then its range is lost. Is
there a way to recover this range?
Yes, but it's not handled automatically by DNA.

Since each has a start/max value, I guess what we'd have to do is find
whatever server has the closest min value and extend the max value on
that master. I'm assuming we'll need to delegate writing to the DNA
config entry, which I'm a little uncomfortable with.
DNA configuration for each server has an active range as well as an
on-deck range.  The active range is defined by the "dnaNextValue" and
"dnaMaxValue" attributes.  The on-deck range is defined by the
"dnaNextRange" attribute, which takes a value in the form
"<start>-<end>" ("500-1000" would be an example).  I would recommend
giving the range of a deleted replica to the on-deck range of another
replica instead of trying to extend it's active range.  That way you
don't have to deal with problems where you don't have another master
with an adjacent range.

The on-deck range is used internally by DNA when a range transfer takes
place.  If a replica hits the configured low-water mark (the
"dnaThreshold" attribute), it will request a range transfer from another
replica.  It might still have some active range values left to use, so
it puts the transferred range on-deck and swaps it to the active range
once the active range is fully exhausted.  When you are trying to choose
a server to reassign the deleted replica range to, you should make sure
it doesn't already have another range on-deck.

Is it also safe to assume that this wouldn't require a restart?
Correct.  Dynamic changes will work fine.

Would it be better to instead write a tool to help manage the DNA ranges?
It could certainly help make things easier.

I have the feeling we'll have to do both.

First we hunt up a server that doesn't have an on-deck setting. If we find one we put the value there.

I guess otherwise we warn about lost range. Then we'd need a tool for one to manage said range.

rob

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users



[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux