Come si aggiorna lo schema del codice di produzione / schema del database senza causare tempi di inattività?

In generale, i siti Web su cui ho lavorato richiedevano questo tipo di requisiti tutti dietro ai bilanciatori di carico o avevano posizioni di failover separate. In questo esempio, presumo che tu abbia un unico bilanciamento del carico, 2 server web (A & B) e 2 server di database (M & N - in genere i server DB sono collegati tramite log shipping - almeno in SQL Mondo server).

1. Il server Web A deve essere disconnesso dal servizio di bilanciamento del carico (quindi tutto il traffico in entrata passa a B).
2. La spedizione dei log viene interrotta (DB Server M verrà aggiornato per primo).
3. Aggiorna server Web A. Puntare la configurazione su DB Server M.
4. Verifica e verifica che l'aggiornamento abbia funzionato (in genere chi colpisce direttamente l'indirizzo IP).
5. Imposta il bilanciamento del carico in modo che le sessioni esistenti continuino a passare a B. Le nuove sessioni vanno su A.
6. Attendi che tutte le sessioni su B scadano (potrebbe essere una mezz'ora o più, di solito guardiamo il traffico e abbiamo una pausa di 1 ora pianificata).
7. Aggiornamento B e N.
8. Verifica e verifica che l'aggiornamento abbia funzionato.
9. Imposta di nuovo il log shipping e verifica che funzioni.
10. Imposta il bilanciamento del carico su operazioni regolari.

In un'applicazione web molto complicata, ciò che è descritto come i passaggi 1-5 potrebbe richiedere tutta la notte ed essere un foglio di calcolo Excel di 50 pagine con orari e numeri di contatto di emergenza. In tali situazioni, l'aggiornamento di metà del sistema è pianificato per le 18:00 alle 06:00 lasciando il sistema disponibile agli utenti. La gestione dell'aggiornamento per il sito di DR è di solito pianificata per la notte seguente: spero solo che non si rompa nulla il primo giorno.

Dove l'uptime è un requisito, le patch vengono testate prima sull'ambiente QA, che idealmente è lo stesso hardware della produzione. Se non mostrano interruzioni, possono essere applicati secondo il programma normale, che di solito si svolge nel fine settimana.

Per i database tipici (ad esempio Oracle) è possibile modificare lo schema del database mentre si eseguono ancora query in parallelo. Tuttavia richiede una pianificazione anticipata.

Ci sono alcuni vincoli per la modifica da applicare:

• dovrebbe funzionare con il codice esistente, il che significa che il codice deve occuparsi sia delle vecchie versioni sia delle nuove dello schema
• non dovrebbe incorrere in tale carico sul DB che le transazioni si fermerebbero bruscamente (ti sto guardando CREATE INDEX )
• non dovrebbe comportare la perdita di dati (non è possibile eliminare e ricreare una tabella)

Affinché lo schema sia retrocompatibile, solitamente puoi AGGIUNGERE o MODIFICARE una colonna, puoi solo DROP qualcosa se il codice esistente non la usa più.

Se il tuo codice non è in grado di gestire la modifica in modo trasparente, modifica il codice prima di modificare il database.

Consigli semplici sulla pianificazione anticipata: sempre i nomi delle colonne nelle richieste DB (non utilizzare SELECT * FROM ). In questo modo non avrai nuove colonne mostrate nelle vecchie richieste.

Non tutti i sistemi possono, deve essere impostato in modo da supportarlo.

Ad esempio, uno dei nostri principali sistemi che ho aiutato ad aggiornare alcuni anni fa dovrebbe essere disponibile 24/7. Consisteva in più livelli, compreso un livello di comunicazione puro tra il livello di interfaccia utente esterno al sito e il livello aziendale. A causa del modo in cui è stato codificato il livello di comunicazione, eventuali modifiche future allo schema Business o allo schema DB potrebbero essere implementate senza un'interruzione reale. Nel peggiore dei casi, un utente sperimenterebbe una pausa di 10-30 secondi non appena le modifiche diventeranno effettive.

Se le modifiche erano puramente modifiche al codice del livello aziendale, potrebbero essere messe in coda e "riciclate" con solo un ritardo di millisecondi.

Potrebbe farlo perché:

• Il livello di comunicazione potrebbe contenere messaggi. Questo ci ha permesso di avere un'interruzione effettiva su qualsiasi livello diverso dal livello dell'interfaccia utente senza dover far cadere l'interfaccia utente.
• Il Business Layer gestito da MVDB chiamato UniData . Questo contiene tutto il codice in memoria. Dopo aver compilato il codice, puoi usare un comando per forzare il nuovo codice oggetto in memoria, sostituendo il vecchio.

Altre tecniche implicano la replica delle transazioni su un altro mirror del sistema esistente. Applicando l'aggiornamento a uno, passare e riprodurre tutte le transazioni effettuate tra l'aggiornamento e il passaggio. YMMV a seconda dei sistemi però.

Ecco una prospettiva diversa, dal mondo dei sistemi di database incorporati e dei sistemi embedded. I sistemi integrati comprendono varie apparecchiature di infrastruttura di rete / telecomunicazioni e in questo ambito parlano spesso di uptime del 99,999% (cinque 9 secondi).

Noi (McObject) siamo il fornitore della famiglia eXtremeDB di prodotti di sistemi di database incorporati, inclusa la disponibilità elevata di eXtremeDB.

In primo luogo, comprendi che "database incorporato" significa che il sistema di database è una libreria che è compilata e collegata con il codice dell'applicazione; in questo senso, è "incorporato" nella tua applicazione.

Con eXtremeDB High Availability, c'è un'istanza MASTER della tua applicazione (che potrebbe essere uno o più processi) e una o più istanze REPLICA della tua applicazione. Quando una replica stabilisce una connessione al master, riceve una copia del database del master attraverso un processo chiamato "sincronizzazione iniziale". Questo può essere fatto mentre l'applicazione master continua il suo lavoro. Una volta sincronizzato, riceve le transazioni del master attraverso la replica. Pertanto, una replica ha sempre i dati attuali e può subentrare (attraverso un processo chiamato failover) nel caso in cui il master fallisca.

Una caratteristica della sincronizzazione iniziale è chiamata "evoluzione dello schema binario". In inglese semplice, ciò significa che il processo di popolamento del database della replica accetterà le differenze tra lo schema del database della replica e lo schema del database del master.

In pratica, ciò significa che è possibile creare una versione più recente dell'applicazione (con tabelle nuove / eliminate, campi nuovi / eliminati / modificati, indici nuovi / eliminati), allegare la nuova versione dell'applicazione a un master e quindi fa in modo che la nuova replica diventi il nuovo master (cioè imponi un failover alla nuova replica in modo che diventi il master e il vecchio master si chiuda). Voilà, hai migrato la tua applicazione dalla versione N alla N + 1, senza interrompere la disponibilità del tuo sistema. Ora puoi andare ad aggiornare il vecchio master e qualsiasi altra replica alla versione N + 1.