Onderwerp: PowerDNS caching serials en axfr

Hallo wht

Wij zijn sinds kort overgestapt na een mysql replicatie PowerDNS op 3 nameservers naar een supermaster setup.
Dit ivm dataverlies als een replicatie verbroken wordt.

PowerDNS gebruikt de serial om de records te updaten.
Als er een record wordt verwijderd en opnieuw wordt toegevoegd maakt de master een nieuwe serial aan en plaatst deze ook in cache, met als gevolg dat er een notify uitgaat naar de slave en een axfr tot stand wordt gebracht.
Edit je een record dan maakt PowerDNS gebruik van de serial in de cache en die is hetzelfde als in de database van de slave , de slave krijgt alleen een notify en geen axfr en de records worden niet geupdate
Weet iemand een oplossing?

Die is er niet. PowerDNS houdt zich (zoals het hoort) aan het protocol, en de slaves zien geen nieuwe serial.

De serial zal geupdate moeten worden. Even een goor scriptje schrijven om die serial te updaten, en daarna een pdns_control notify erachter aan.

Wat je zou kunnen overwegen is van Master-Slave naar MySQL-Replicatie over te stappen. Dus MySQL laten repliceren, en de master op de master-MySQL en slave op Slave-MySQL laten luisteren. Dan heb je directe updates en dit gezeur niet.

Precies, en wanneer je op de master de serial update dan announced pdns dit automatisch naar alle slaves. Zonder een extra commando.

Oorspronkelijk geplaatst door DoMMeL

Wij zijn sinds kort overgestapt na een mysql replicatie PowerDNS op 3 nameservers naar een supermaster setup.
Dit ivm dataverlies als een replicatie verbroken wordt.

Oorspronkelijk geplaatst door DiedX

Wat je zou kunnen overwegen is van Master-Slave naar MySQL-Replicatie over te stappen. Dus MySQL laten repliceren, en de master op de master-MySQL en slave op Slave-MySQL laten luisteren. Dan heb je directe updates en dit gezeur niet.

Wanneer wordt de replicatie verbroken?
ID's die niet kloppen? (zou bij een master - slave niet mogen voorvallen)
Server die een timout geeft? (neemt normaal terug gewoon op)
Of na herstart dat die de replicatie niet mooi opneemt?

Zelf ben ik meer voor replicatie tussen deze systemen(kan ook gemonitord worden als deze 'breekt'), en met andere DNS systemen even met axfr laten doorsturen.

Bij elke update aan de master (serial) zou dit normaal door moeten worden gestuurd en je slaves zouden dit moeten opnemen / updaten.

Oorspronkelijk geplaatst door DiedX

Dan heb je directe updates en dit gezeur niet.

Je kan de tijden inkorten, binnen 5 seconden zijn bij ons alle records uptodate

slave-cycle-interval

En om verdere discussies te voorkomen, alles heeft zowel zijn voordelen als zijn nadelen. Totdat sidn accepteerd dat je kan reggen op nog niet helemaal complete nameservers houden we dit aan. Als ze om zijn schakelijk we terug naar default.

Gezien de "auto-serial" functie (als je een 0 invoert in het SOA record zou PowerDNS automatisch een serienummer 'verzinnen' naar aanleiding van de meest recente change_date van dat domein) al een paar versies kapot is en met die bug niks wordt gedaan zijn wij juist overgestapt van een Master-Slaves setup naar een setup van MySQL replicatie en hebben we ons interne systeem overgezet naar de PowerDNS::Backend::MySQL API die de normale 'standaard' serial yyyymmddxx serial omhoog gooit na elke change. Iets dat we sowieso al van plan waren trouwens.

Lijkt mij in ieder geval wel logisch om bij elke wijziging die plaats vindt de serial omhoog te gooien anders heb je sowieso een issue met je slaves.

Wij hadden sowieso eigenlijk meer issues met AXFR dan met MySQL replicatie. Slaves die hun notify nog niet hadden omgezet in het doen van een AXFR en dus even niet up to date waren.

Oorspronkelijk geplaatst door Pur

Gezien de "auto-serial" functie (als je een 0 invoert in het SOA record zou PowerDNS automatisch een serienummer 'verzinnen' naar aanleiding van de meest recente change_date van dat domein) al een paar versies kapot is en met die bug niks wordt gedaan zijn wij juist overgestapt van een Master-Slaves setup naar een setup van MySQL replicatie en hebben we ons interne systeem overgezet naar de PowerDNS::Backend::MySQL API die de normale 'standaard' serial yyyymmddxx serial omhoog gooit na elke change. Iets dat we sowieso al van plan waren trouwens.

Heb je bert daar rechtsreeks al eens over gemaild ?

Oorspronkelijk geplaatst door Mikey

Heb je bert daar rechtsreeks al eens over gemaild ?

Nope wel twee keer aangekaart op de mailing list. Waarna iemand mij ook direct benaderde die hetzelfde probleem had en die zou Bert direct benaderen. Maar dat is inmiddels ook alweer een behoorlijk tijdje geleden.

En we waren dus sowieso al van plan om een keer over te schakelen naar MySQL replicatie + reguliere serials want het is imho niet de allermooiste oplossing om de auto-serial functionaliteit te gebruiken.

Oorspronkelijk geplaatst door Tim.Bracquez

Wanneer wordt de replicatie verbroken?
ID's die niet kloppen? (zou bij een master - slave niet mogen voorvallen)
Server die een timout geeft? (neemt normaal terug gewoon op)
Of na herstart dat die de replicatie niet mooi opneemt?

Zelf ben ik meer voor replicatie tussen deze systemen(kan ook gemonitord worden als deze 'breekt'), en met andere DNS systemen even met axfr laten doorsturen.

Bij elke update aan de master (serial) zou dit normaal door moeten worden gestuurd en je slaves zouden dit moeten opnemen / updaten.

Ik snap je eerste zin niet: de replicatie met een nieuwere versie van MySQL ging bij mij goed. Ook als de server enige tijd niet beschikbaar is.

Zelf ben ik er geen voorstander van. Bij een van mijn vorige werkgevers hadden we deze setup, en het werkt, maar ik vind het relatief ingewikkeld. DNS heeft dit "replicatie"-principe in zich, en kan daarom goed gebruikt worden.

Zelf heb ik PDNS met serial-updates (dus geen MySQL) in gebruik, en overweeg unbound eens te testen.

Oorspronkelijk geplaatst door DiedX

Ik snap je eerste zin niet: de replicatie met een nieuwere versie van MySQL ging bij mij goed. Ook als de server enige tijd niet beschikbaar is. ...

Welke eerste zin?

Alles heeft zijn voor en nadelen...

Dat is inderdaad de samenvatting

Precies, en wanneer je op de master de serial update dan announced pdns dit automatisch naar alle slaves. Zonder een extra commando.

En dat is nu het probleem.
De serials worden na een edit van een record geupdate in de database van de master, deze zijn ook verschillend en als master hoger dan de slaves.
Dus zou een notify moeten werken, op de slave komt een notify binnen maar ziet de serials als niet veranderd en doet geen axfr
Als ik in de database van de master kijk zie ik een andere serial staan.
Dus wat doet de master, die zend een notify naar de slaves met de serial die in cache staat, dus ziet de slave een gelijke serial en doet geen axfr.
Als ik een record verwijder en daarna weer toevoeg dan gaat het goed.

Pdns stuurt helemaal geen serial vanuit de cache, doorgaands wordt er om de minuut gecontrolleerd of er wijzigingen zijn, indien ja wordt er een notify verstuurd vanuit de waarde die in de database staat, en niet diegene die hij al wist.

Maar zet anders eens beide nameservers in monitor mode, dan krijg je precies te zien wat hij doen en waar hij struikelt.

Heb je je soa-serial wel geupgrade?

upgraden van soa serial?
Ik weet niet wat je bedoelt