Nokia Lumia 820.1 Dev Kit

Pár héttel ezelőtt írtam a MySQL replikációról, majd most úgy tűnik egy PowerDNS alapokon nyugvó DNS kiszolgálóhoz szükség is van rá némi kiegészítéssel.

Ami miatt úgy tűnik használni kell, az a PowerDNS supermaster/superslave funkciójának egy hiányossága.

A domain név szervereket (DNS) elsősorban a megfelelő hibatűrés érdekében többszörözni szokás. Ilyenkor egy-egy zónához (például a halacs.hu vagy a .hu TLD) nem csak egy authoritatív (mérvadó) kiszolgálót tartunk számon, hanem legalább kettőt. Ezeket szokták legtöbbször elsődleges és másodlagos névszerverekként is említeni (feltéve, hogy csak kettő van).

Nyilvánvalóan nem szeretnénk minden géphez odamenni (be sshzni, stb), hanem valamiféleképpen el kéne érjük, hogy egyetlen helyen módosítva a DNS adatbázist, annak híre a többi kiszolgálóhoz is biztosan eljusson. Erre született megoldásként az AXFR protokoll, melyet a PowerDNS is használ a supermaster/superslave funkcióhoz.

Jelen esetben a "super" szó annyit jelent, hogy egy átlagos master-slave felálláshoz képest itt egy új zóna felvételekor azt elegendő csak a master kiszolgálón beállítani, majd a többi képes azt automatikusan átvenni.

Ez eddig remekül működik is egészen odáig, amíg zónákat csak létrehozni és módosítani akarunk, a törlésnél ugyanis már gondok adódnak: a törlés híre nem terjed át a slaveekhez, így a törölt domain neveket ezek a szerverek továbbra is kiszolgálhatják maradvány adatokkal (persze csak ha kérdezik őket, de ebbe itt nem mennék bele).

Megoldásként kínálkozik az AXFR lecserélése egy kizárólag MySQL-t használó megoldásra. Ennek alapjául szolgál a már említett bejegyzésem, melyben leírtam hogyan kell létrehozni egy MySQL master-slave clustert.             

Az ott leírtakat most annyiban egészíteném ki, hogy ha a DNS szolgáltatásért nem egy dedikált szerver a felelős, akkor könnyen előfordulhat, hogy nem szeretnénk minden adatbázist replikálni, csak mondjuk a 'PowerDNS' nevűt. Ezt a következő my.cnf fájlbeli paramtéterek helyes használatával érhetjük el:

• binlog-do-db
  Utasítja a replikációhoz felhasznált naplózó szálat, hogy csak a megadott nevű adatbázis változásait naplózza. A nem naplózott események nem kerülnek át a hálózaton.
• binlog-ignore-db
  Az előző ellentéte (mit ne naplózzon)
• replicate-do-db
  Hasonló mint az első opció, azonban ez a slave oldalú feldolgozó szálnak szól, és arra utasítja, hogy a kapott adatokból csak a megadott nevű adatbázisok naplóit dolgozza fel és juttassa érvényre az ott tárolt adatokon.
• replicate-ignore-db
  Az előző ellentéte (mit ne dolgozzon fel)

Csak szintaktikai kérdés ugyan, de fontos lehet: mivel az adtbázis nevek tartalmazhatnak vesszőt, így ha több adatbázisra is szeretnénk valamelyiket alkalmazni, akkor mindegyiket külön sorban kell megadni az opciót soronként megismételve.