Newsgroup: it.comp.os.linux.sys
Titolo: Sincronizzazione zone DNS

Giusto per parlare, secondo voi, il sistema migliore per sincronizzare X zone DNS su Y server partendo da un sistema centrale, può essere una tradizionale replica MySQL (che mi da sempre un mucchio di problemi), un banale dump+reload tramite cron, una sorta di API richiamate dal sistema centrale e presenti su ciascun server DNS oppure che altro ?
 
Il sistema centrale non ha le zone su file (altrimenti potrebbe bastare un rsync schedulato) ma un database MySQL.
 
Non è fondamentale il real-time, una schedulazione ogni X minuti è più che adeguata.
 
Ho provato svariati sistemi, ma fino ad ora nessuno mi ha mai convinto appieno.
Le repliche MySQL sono troppo instabili ed al primo crash, nel 99% dei casi, richiedono sempre un intervento manuale per ripartire.
 
Il dump+restore che uso tutt'ora in alcuni sistemi è decisamente più affidabile, ma in caso di grosse quantità di dati, durante l'operazione di restore il server risponde NXDOMAIN o analogo
 
Preferisco non usare MySQL sui singoli server DNS, in questo caso lo userei solo per gestire la replica, ma preferirei rimuovere tutto e trovare altri sistemi di sincronizzazione.


posto che non ho mai usato mysql come backend per il dns (e me ne
guardo), perché escludi l'uso di mysql sul master e l'uso di slave che
piglino le zone via [AI]XFR?
 
 
(per la cronaca, e non eccessivamente connesso: ho avuto diverse dozzine
di server mysql in replica per parecchi anni. Per quanto non nutra
particolare affezione per lo stesso, "nel 99% dei casi, richiedono
sempre un intervento manuale per ripartire" è molto distante dalla mia
esperienza..)

 esperienza..)
 
Gioca al totocalcio, farai 13, con la fortuna che ti ritrovi.
La mia ultima replica scoppiata risale a 3 giorni fa, quella prima, circa 15 giorni, e così via. Tutte causate da un crash della macchina slave (il che è del tutto legittimo, essendoci un master-slave, gli slave devono poter morire)
Al riavvio dello slave, viene persa ogni volta la sincronizzazione con il master per non so quale motivo (dice che cambia il nome del file di log, boh)
 
Io odio le repliche, mi stan talmente sui maroni che non ho mai approfondito, quando posso uso dei brutali dump+restore.

 Al riavvio dello slave, viene persa ogni volta la sincronizzazione con il master per non so quale motivo (dice che cambia il nome del file di log, boh)
 
A spanne, hai qualcosa di cambiato nella configurazione, o tempi di
retention dei log di replica eccessivamente stretti.
 

 
 
s/cambiato/sbagliato/

 retention dei log di replica eccessivamente stretti.
 
Configurazione errata no, non credo, tempi di retention, forse si, dato che ne vengo a conoscenza solo ora.
 
Intendi 'expire_logs_days' ?
 
 
$ mysql -u root -p -e "SHOW VARIABLES LIKE 'expire_logs_days';"
Enter password: 
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| expire_logs_days | 10    |
+------------------+-------+

 approfondito, quando posso uso dei brutali dump+restore.
 
Quanto sei legato a MySQL? non puoi passare a PostgreSQL?
 
Enrico

 +------------------+-------+
 
 
Ergo hai 10 giorni di tempo per ripristinare lo slave da quando questo
smette di replicare per qualsivoglia ragione.
 
Se lo fai dopo questo intervallo di tempo, quando lo slave cerca di
riprendere la replica non trova più il logfile da cui sincronizzare, e
devi ri-allineare a mano (dump, snapshot, whatever).
 
 
 

 Quanto sei legato a MySQL? non puoi passare a PostgreSQL?
 
Legato 0, ma non ho esperienza su PostgreSQL, non metto in produzione software che non saprei gestire nemmeno in maniera base.

 devi ri-allineare a mano (dump, snapshot, whatever).
 
A quanto pare le due ultime volte è andato storto più del previsto....

 Questo è il sistema di cui parlavo poco sopra, ci vuole pochissimo a realizzarlo ed usando il supermaster di powerdns, non devo nemmeno creare il dominio sullo slave.
 
Idem con bind se scripti l'uso di un "rndc addzone" direttamente dal
master sugli slave.
 
Però finisci comunque con un sistema che gira attorno ad una singola
piattaforma SW, con le (potenziali, almeno) fragilità che ciò comporta.
 

 piattaforma SW, con le (potenziali, almeno) fragilità che ciò comporta.
 
Questo è vero ed effettivamente dovendo comunque creare uno script per la rimozione delle zone, lo stesso script può benissimo aggiungere il dominio al database locale.

 performante (LMDB, magari)
 
 
La mia capacità di analisi sintattica sarà limitata, ma nella tua
risposta qui sopra il io "preferirei evitare" lo riferisco a "l'uso di
slave che piglino le zone via [AI]XFR", non a mysql (che, se se la
replica avviene inline su DNS, è del tutto irrilevante per il topic,
peraltro...)

 peraltro...)
 
Colpa mia, intendevo dire che preferirei evitare l'uso di MySQL sugli slave (o, meglio ancora, l'uso di MySQL su tutta l'infrastruttura DNS, master compreso)
per questo si stava discutendo su come sincronizzare i dati, non avendo, appunto, la replica.


 
 
Mi intrometto nella discussione (MySQL) hai provato a settare il 
parametro sync_binlog = 1?
Di default è zero
 
https://dev.mysql.com/doc/refman/5.5/en/replication-options-binary-log.html#sysvar_sync_binlog
 
 
Il server rallenta in scrittura/replica ma hai sicurezza in caso di 
crash. Personalmente prima di settarlo un paio di replice si sono 
"rotte" da quando l'ho impostato a 1 anche dopo un brusco distacco 
elettrico non ho avuto problemi (toccando ferro).
 
Per i DNS non metto bocca :-)

 software che non saprei gestire nemmeno in maniera base.
 
Comincia a studiarlo :)
Una delle funzionalita` che ti avrebbero risolto questi problemi e` la 
streaming replication, che ti permette di creare una serie di master/slave 
anche a cascata (ovvero slave di slave). Questo senza contare la diatriba 
MySQL vs resto del mondo (dove resto del mondo viene preferito al prodotto 
di Oracle)
 
Enrico

 anche a cascata (ovvero slave di slave).
 
Anche su MySQL si possono fare catene.

 elettrico non ho avuto problemi (toccando ferro).
 
Buono a sapersi, non ne ero al corrente.
Resta però il fatto che preferirei evitare di usare MySQL per sincronizzare dei dati sostanzialmente testuali (senza contare che le 'zone' le posso trasferire nativamente mediante DNS, in soldoni io devo sincronizzare solo la lista dei domini)
 
E' un po come sparare con il bazooka ad una mosca.


 
Perfettamente d'accordo con te

 Anche su MySQL si possono fare catene.
 
Su PostgreSQL pero` funzionano :P
 
Enrico