It might seem like a very basic question, but, how is a master DNS server aware of its slaves?
I mean, does it parse the zone file and determine where to send the NOTIFY message?
And if that is the case, then, is the NOTIFY mechanism broken in a hidden master setup, isn't it?
UPDATE:
BIND Version:
[[email protected]] $ named -v
BIND 9.3.6-P1-RedHat-9.3.6-16.P1.el5
Operating System:
CentOS release 5.6 (Final)
After running [[email protected]] $ dig @10.224.45.130 example.com. axfr:
Slave:
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> @10.224.45.130 example.com. axfr
; (1 server found)
;; global options: printcmd
; Transfer failed.
Master:
28-Aug-2011 12:29:01.384 client 10.224.45.131#60553: query: example.com IN AXFR -
28-Aug-2011 12:29:01.384 client 10.224.45.131#60553: zone transfer 'example.com/AXFR/IN' denied
Same error message as before.
UPDATE 2:
[[email protected] ~] # iptables -L -n -v
Chain INPUT (policy DROP 30235 packets, 1747K bytes)
pkts bytes target prot opt in out source destination
171K 23M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tap0 * 0.0.0.0/0 0.0.0.0/0
57196 6930K ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
688 57376 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
37869 6120K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
392 21216 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
74 5275 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:110
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:143
3 192 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:389
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:465
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:587
13 832 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:636
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:694
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:843
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:873
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:953
119 7584 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:993
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:993
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1194
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
1 48 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5901
0 0 ACCEPT tcp -- * * 0.0.0.0/0 10.224.45.130 tcp dpt:10000
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:11211
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:11212
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:11213
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:11511
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:11512
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:11513
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
2987 372K ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * br0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
Chain OUTPUT (policy ACCEPT 246K packets, 37M bytes)
pkts bytes target prot opt in out source destination
I've probably looked at every single page regarding BIND master/slave setup, and I cannot for the life of me get the zone transfer working.
Here's my setup: (scroll down for description of problem)
Master: 10.224.45.130
/etc/named.conf
options {
directory "/var/named";
version "unknown";
pid-file "/var/run/named/named.pid";
recursion yes;
allow-recursion { localhost; localnets; };
notify explicit;
allow-transfer {
10.224.45.131;
};
also-notify {
10.224.45.131;
};
};
zone "." {
type hint;
file "named.root";
};
zone "example.com" IN {
type master;
file "data/example.com.hosts";
};
Slave: 10.224.45.131
/etc/named.conf
options {
directory "/var/named";
version "unknown";
pid-file "/var/run/named/named.pid";
recursion yes;
allow-recursion { localhost; localnets; };
notify yes;
allow-transfer { "none"; };
allow-notify {
10.224.45.130;
};
};
zone "." {
type hint;
file "named.root";
};
zone "example.com" IN {
type slave;
file "slaves/example.com.hosts";
masters {
10.224.45.130;
};
};
Here's the problem. When I restart named on the slave server it sees that the zone files do not exist yet and requests a transfer from the master server:
named.log (Slave)
[10.224.45.131] zone example.com/IN: no database exists yet, requesting AXFR of initial version from 10.224.45.130#53
...after which the master server receives the transfer request:
named.log (Master)
[10.224.45.130] client 10.224.45.131#53467: query: example.com IN AXFR -
...and replies with the transfer request, which gets denied:
named.log (Master)
[10.224.45.130] client 10.224.45.131#53467: zone transfer 'example.com/AXFR/IN' denied
...on the slave server it shows up as being REFUSED:
named.log (Slave)
[10.224.45.131] transfer of 'example.com/IN' from 10.224.45.130#53: failed while receiving responses: REFUSED
Looking at all the configs over and over I can't find anything wrong with the settings. I have the master server's IP address listed in the masters setting of the slave zone configuration, I have the slave server's IP address listed in the allow-transfer setting of the master options settings.
All the IP addresses are what they should be, it's not like it's trying to use the public IP address and being rejected because the IP address doesn't match. I have iptables setup to allow TCP/UDP connections on port 53 (and 953) on both servers. I have setup the file permissions properly so that the /slaves directory where the slave zone files are stored is writable by the named user.
No matter what I do I always get this same error. If anyone can give me a clue as to what I'm missing I would really appreciate it!
I've been setting up MySQL master replication (on Debian 6.0.1) following these instructions faithfully: http://www.neocodesoftware.com/replication/
I've got as far as:
mysql > show master status;
but this is unfortunately producing the following, rather than any useful output:
Empty set (0.00 sec)
The error log at /var/log/mysql.err is just an empty file, so that's not giving me any clues.
Any ideas?
This is what I have put in /etc/mysql/my.cnf on one server (amended appropriately for the other server):
server-id = 1
replicate-same-server-id = 0
auto-increment-increment = 2
auto-increment-offset = 1
master-host = 10.0.0.3
master-user = <myusername>
master-password = <mypass>
master-connect-retry = 60
replicate-do-db = fruit
log-bin = /var/log/mysql-replication.log
binlog-do-db = fruit
And I have set up users and can connect from MySQL on Server A to the database on Server B using the username/password/ipaddress above.
Basically we have a large MySQL database and we're looking to do replication to a slave (master slave setup). Do you guys have any step-by-step guide on how to do this with MINIMAL downtime on the database? Backing up the database and transferring the backup to the slave server (even through a private network) takes like 40 minutes or so. Quite a long downtime.
I periodically need to make changes to tables in mysql 5.1, mostly adding columns. Very simple with the alter table command. But my tables have up to 40 million rows now and they are growing fast... So those alter table commands take several hours. In a couple months they'll take days I'm guessing.
Since I'm using amazon RDS, I can't have slave servers to play with and then promote to master. So my question is if there's a way to do this with minimal downtime? I don't mind an operation taking hours or even days if users can still use the db of course... Can they at least read while columns are being added? What happens if my app tries to write? Insert or update? If it fails immediately that's actually not so bad, if it just hangs and causes problems for the db server that's a big problem..
This must be a fairly common scaling issue, everyone needs to add columns.. What's typically done to a production db? Slave -> master migration?
Update - I forgot to mention I'm using the innodb storage engine