it-swarm.it

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

Quali sono alcune tecniche per aggiornare la base di codice/schema del database di un server di produzione senza causare tempi di inattività?

43
Olivier Lalonde

In generale, i siti Web su cui ho lavorato che presentavano questo tipo di requisiti erano tutti alla base del bilanciamento del carico o avevano posizioni di failover separate. In questo esempio, presumo che tu abbia un unico bilanciamento del carico, 2 server Web (A e B) e 2 server di database (M & N - di solito i server DB sono collegati tramite log shipping - almeno nel mondo SQL Server ).

  1. Il server web A deve essere disconnesso dal bilanciamento del carico (quindi tutto il traffico in entrata va a B).
  2. La distribuzione dei log viene interrotta (DB Server M verrà prima aggiornato).
  3. Aggiorna server web A. Punta la configurazione su DB Server M.
  4. Verifica e verifica che l'aggiornamento abbia funzionato (di solito la gente sta colpendo direttamente l'indirizzo IP).
  5. Impostare il bilanciamento del carico in modo che le sessioni esistenti continuino a passare a B. Le nuove sessioni vanno a A.
  6. Attendi che tutte le sessioni su B scadano (potrebbe essere mezz'ora o più, di solito guardiamo il traffico e abbiamo programmato una pausa di 1 ora).
  7. Aggiornamento B e N.
  8. Verifica e verifica che l'aggiornamento abbia funzionato.
  9. Configura nuovamente il log shipping e verifica che funzioni.
  10. Impostare il bilanciamento del carico sul normale funzionamento.

In applicazioni Web molto complicate, ciò che viene descritto come passaggi 1-5 potrebbe richiedere tutta la notte ed essere un foglio di calcolo Excel da 50 pagine con orari e numeri di contatto di emergenza. In tali situazioni, l'aggiornamento della metà del sistema è programmato dalle 18:00 alle 06:00, lasciando il sistema disponibile agli utenti. La gestione dell'aggiornamento per il sito di DR di solito è programmata per la notte seguente - spero solo che non si verifichino interruzioni nel primo giorno.

Laddove il tempo di attività è un requisito, le patch vengono testate prima nell'ambiente di controllo qualità, che idealmente è lo stesso hardware della produzione. Se non mostrano alcun disturbo, possono essere applicati sul programma normale, che di solito è nel fine settimana.

20
Tangurena

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

Esistono alcuni vincoli per l'applicazione della modifica:

  • dovrebbe funzionare con il codice esistente, il che significa che il codice dovrebbe gestire sia la vecchia che la nuova versione dello schema
  • non dovrebbe sostenere un 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 compatibile con le versioni precedenti, in genere è possibile AGGIUNGERE o MODIFICARE una colonna, è possibile DROP solo se il codice esistente non lo utilizza più.

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

Semplici consigli sulla pianificazione diretta: esplicita sempre i nomi delle colonne nelle tue richieste DB (non utilizzare SELECT * FROM). In questo modo non avrai nuove colonne visualizzate nelle vecchie richieste.

9
Matthieu M.

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

Ad esempio, uno dei nostri principali sistemi che ho aiutato ad aggiornare qualche anno fa dovrebbe essere disponibile 24 ore su 24, 7 giorni su 7. Consisteva in più livelli, incluso un livello di comunicazione puro tra il livello di interfaccia utente fuori sede e il livello aziendale. A causa del modo in cui il livello di comunicazione è stato codificato, qualsiasi futura modifica allo schema del livello aziendale o DB potrebbe essere implementata senza un'interruzione reale. Nel peggiore dei casi, un utente avrebbe avuto una pausa di 10-30 secondi quando le modifiche diventavano effettive.

Se le modifiche fossero puramente modifiche al codice del livello aziendale, potrebbero essere messe in coda e "messe in ciclo" con un ritardo di soli millisecondi.

Potrebbe farlo perché:

  • Il livello di comunicazione potrebbe contenere messaggi. Questo ci ha permesso di avere un'interruzione effettiva su qualsiasi livello diverso dallo strato dell'interfaccia utente senza la necessità di ridurre l'interfaccia utente.
  • Il livello aziendale gestito da MVDB chiamato niData . Questo contiene tutto il codice in memoria. Dopo aver compilato il codice, è possibile utilizzare un comando per forzare il nuovo codice oggetto in memoria, sostituendo il vecchio.

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

5
Dan McGrath

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

Noi (McObject) siamo il fornitore della famiglia di prodotti di sistema di database embedded eXtremeDB, inclusa l'alta disponibilità di eXtremeDB.

Innanzitutto, capire che "database incorporato" significa che il sistema di database è una libreria che viene compilata e collegata al codice dell'applicazione; in tal senso, è "incorporato" nella tua applicazione.

Con eXtremeDB High Availability, esiste un'istanza MASTER dell'applicazione (che potrebbe essere uno o più processi) e una o più istanze REPLICA dell'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 principale continua a funzionare. Una volta sincronizzato, riceve le transazioni del master attraverso la replica. Pertanto, una replica ha sempre dati correnti 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 parole povere, ciò significa che il processo di popolamento del database della replica si adatta alle 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), collegare quella nuova versione dell'applicazione a un master e quindi causare che replica più recente per diventare il nuovo master (ovvero forzare un failover sulla nuova replica in modo che diventi il ​​master e il vecchio master si spenga automaticamente). Voilà, hai migrato la tua applicazione dalla versione N a N + 1, senza interrompere la disponibilità del tuo sistema. Ora puoi procedere con l'aggiornamento del vecchio master e di qualsiasi altra replica alla versione N + 1.

1
user22538