Zero tempi di inattività (o quasi zero) modifiche dello schema db

Question

Mi chiedevo come/se le persone hanno lavorato attorno alle modifiche dello schema db che altrimenti causerebbero un down del sistema di produzione. Sembra che con le modifiche additive che sono vincolate in qualche modo (ad esempio un vincolo univoco) sarebbe difficile fare b/c l'app e il db deve cambiare nello stesso momento, altrimenti si verificheranno errori nei dati o nell'applicazione.

Ho pensato di passare a uno slave db (usando la replica mysql) e di eseguire le modifiche dello schema sul master ma poi avresti bisogno di catturare in qualche modo le query di aggiornamento applicate allo slave che non erano applicate al master e corri il rischio di non avere un server di backup.

Quali tecniche hanno utilizzato le persone per risolvere questi problemi?

Grazie, Manish

Answer 1

direi che sei vicino l'idea; in effetti, avrei un master e uno schiavo, con il master in diretta e lo slave con le modifiche replicate ad esso; sospendere la replica sullo slave e quindi eseguire le modifiche dello schema sullo slave e una volta eseguite le modifiche allo schema, riattivare la replica; una volta completato l'intero processo, mettere in pausa il master per un periodo di tempo molto breve per assicurarsi che le modifiche replicate vengano scaricate sullo slave e quindi cambiare master e slave. Quello dovrebbe fare quello che ti serve.

Si noti che questo funziona solo se le modifiche apportate allo schema non vengono toccate dai comandi di replica in sospeso; questo in genere è meglio farlo in orari di traffico ridotto per assicurare che la collisione sia improbabile. Si noti che poiché ciò non apporta modifiche al master fino a quando lo slave non ha completamente aggiornato lo schema e replicando le modifiche, è molto sicuro sul master.

Answer 2

Dipende da come si apportano le modifiche dello schema, in precedenza si sarebbe cercato di assicurarsi che le modifiche dello schema implementate fossero compatibili con le versioni precedenti dell'applicazione. Questo ha funzionato bene per progetti minori (e piuttosto importanti). Significava anche che se avessimo avuto un serio problema di prestazioni con l'applicazione (perire il pensiero), il rollback del codice era un compito semplice, piuttosto che arduo.

Answer 3

L'unico vero modo per aggirare questo è avere un database di cluster o uno master/slave come suggerito. Solitamente si prende un nodo offline e si eseguono gli aggiornamenti. Una volta che è stato eseguito, in genere si esegue una sincronizzazione dal master corrente al sistema appena aggiornato che comprende come tradurre i dati dal vecchio schema al nuovo. (Durante la sincronizzazione, il master può essere brevemente messo in modalità di sola lettura.)

Quindi si passa ai ruoli master/slave e si aggiorna l'altro schema del database. Sincronizzarli e riportare online lo slave aggiornato.

In pratica, questo può essere molto difficile da correggere, soprattutto se si dispone di modifiche significative dello schema.