> On 23 Aug 2018, at 3:31 am, 潘政宇 <zhengyup...@163.com> wrote:
>
>
>
>> 在 2018年8月22日，下午8:54，Matus UHLAR - fantomas <uh...@fantomas.sk> 写道：
>>
>> On 22.08.18 20:37, Zhengyu Pan wrote:
>>> Thank you for your reply. How to switch slave to master in real time?
>>
>> If you store the data in a file, simply redefine the zone type, change
>> "type master;" to
>> "type slave;”
>>
> However, I have hundreds of thousands of zone files in my master. If I modify
> these zone files sequentially and then reload bind, it will spend a lot of
> time.
Automatic multi-master is really hard to do. Ask anyone that does
database replication.
Manual multi-master however is easier to do as you have a human in the
loop deciding which machine is master.
Switching a server from standby master to active master can be a simple as
cp /etc/named.active.conf /etc/named.conf
rndc reload
and
returning it to being a standby master
cp /etc/named.standby.conf /etc/named.conf
rndc reload
If you keep /etc/named.active.conf and /etc/named.standby.conf
preconfigured for the two mode of operation.
Since you are using dynamic update
active:
zone example.com {
type master;
masterfile-format raw;
update-policy {};
...
};
standby:
zone example.com {
type slave;
masterfile-format raw;
masters { other-master;
all-the-machines-that-transfer-from-one-of-these-masters; };
update-forward { … };
...
};
then you use rsync to keep /etc/named.active.conf and /etc/named.standby.conf
up to date.
You use all the slaves as masters to the standby master so that you have a very
low probability of a lost update due to the active master dying before the
update
makes it onto one of the slaves. Named will almost certainly be up to date on
the standby master by the time you go to promote it to active master. This can
be checked by checking all the serial numbers for the zones.
You also need to be able to detect whether that other master is in active or
standby mode when you the server reboots. If you can’t determine this put the
server into standby mode. I would use
zone standby-mode {
type master;
file “active.db”;
};
zone standby-mode {
type master;
file “standby.db”;
};
as a way to do this and cross checking.
>> If you don't keep slave zones in files, you are out of luck.
>>
>>> Does bind have command?
>>
>> no.
>>
>>> Am 22.08.2018 um 12:17 schrieb Zhengyu Pan:
>>> Because I need to a master as a cold standby.
>>
>> the question apparently was, why do you need it. This is not an answer to
>> that question.
>>
> Why I need the second master is that one master may send notify packet
> unsuccessfully with the increment of slave dns. I need that one part of
> slave servers connect the first master, the other part of slave servers
> connect the second master. So i need that these two master’s zone are fully
> consistent.
>
>
>>> Another master need to
>>> have the same zone and configuration with the former. When a master
>>> is down, I need to switch to another master right away.
>>
>> slaves can be slaves to multiple servers. Servers can have multiple roles.
>>
>> ine server can fetch one zone from its master, but be a master to another
>> server for the same zone.
>>
> How to make a zone is type master for slave dns and the same zone is slave
> for master in a server. How to configure it in named.conf?
>
>
>>
>>> In my application scenario, I have two master. Each master connect
>>> several slave dns. When users update zone, i update these two master
>>> respectively in a for loop. However, when any master update fails, i
>>> will roll bock. you know, whenever any update, zone's serial will
>>> increase. this cause that the serial numbers of zone in two
>>> masters are
>>> inconsistent. How can i keep these two masters' zones consistent
>>> in real
>>> time? Is using rsync tool a good way? In the industry, is there
>>> a good
>>> way to synchronize two masters?
>>
>> The one example of this case it the active directory. It supports multiple
>> masters, BUT:
>> a DNS server should not be DNS slave to multiple AD servers. The AD servers
>> contain the data, but serial numbers are unrealiable in this case.
>>
>> I'm afraid the same would apply for your application.
>>
>
>
>
>> --
>> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
>> Warning: I wish NOT to receive e-mail advertising to this address.
>> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
>> WinError #98652: Operation completed successfully.
>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
