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

42

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

deployment

— Olivier Lalonde
fonte

1

Bella domanda perché vedo così tante persone trascurare questo. Il tempo è denaro e i tempi di fermo non sono mai belli per gli utenti finali, indipendentemente da quanto sia legittima la ragione.

— Dan McGrath,

@Dan McGrath: supponendo che tu possa effettivamente avere un tempo morto, lavoro per un sistema che è (normalmente) inattivo solo 4 volte l'anno (interruzione di un quarto) e per un massimo di 15 minuti ogni volta (durante il quale il traffico è in coda). .. le modifiche al database sono attentamente esaminate :)

— Matthieu M.

2

Questa sarebbe una grande domanda per dba.stackexchange.com , che entrerà nella beta pubblica in poche ore.

— Larry Coleman,

20

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 ).

Il server web A deve essere disconnesso dal bilanciamento del carico (quindi tutto il traffico in entrata va a B).
La distribuzione dei log viene interrotta (DB Server M verrà prima aggiornato).
Aggiorna server web A. Punta la configurazione su DB Server M.
Verifica e verifica che l'aggiornamento abbia funzionato (di solito la gente sta colpendo direttamente l'indirizzo IP).
Impostare il bilanciamento del carico in modo che le sessioni esistenti continuino a passare a B. Le nuove sessioni vanno a A.
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).
Aggiornamento B e N.
Verifica e verifica che l'aggiornamento abbia funzionato.
Configura nuovamente il log shipping e verifica che funzioni.
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 QA, che idealmente è lo stesso hardware della produzione. Se non mostrano alcun disturbo, possono essere applicati sul programma normale, che di solito è nel fine settimana.

— Tangurena
fonte

7

Come proponete di unire nuovi dati da DB M e DB N? Avranno entrambi record nuovi, aggiornati ed eliminati che l'altro non ha.

— sixtyfootersdude,

@Tangurena, puoi rispondere al commento sopra?

— sino

9

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 retrocompatibile, di solito è possibile AGGIUNGERE o MODIFICARE una colonna, è possibile DROP qualcosa 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 anticipata: 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.

— Matthieu M.
fonte

1

In realtà, per la pianificazione futura e l'adattabilità, selezionare * da è infinitamente migliore rispetto all'elenco manuale delle colonne. L'uso di nomi di colonne espliciti comporta molti debiti tecnici nella maggior parte dei casi. Se il tuo codice si rompe da nuove colonne, il tuo codice è già rotto.

— Morg.

@Morg .: Non proprio. Per motivi di sicurezza è necessario utilizzare le variabili bind, che nel framework che uso (almeno) richiedono di fornire le variabili su cui scrivere, e devono esserci esattamente tante variabili quante sono le colonne di output, quindi select *il codice si interrompe se un viene aggiunta una nuova colonna (per mancanza di una variabile in cui scrivere). Naturalmente, questo può essere il risultato dell'uso di un linguaggio fortemente tipizzato.

— Matthieu M.,

Sì, davvero, non esiste alcuna sicurezza aggiuntiva per evitare la selezione *. Non ha nulla a che fare con linguaggi fortemente tipizzati e tutto ha a che fare con un pessimo design. Se il tuo framework non è in grado di gestire il cambiamento senza soluzione di continuità, è inutile. Quando cambio una colonna, la mia applicazione non smette mai di funzionare. Quando lo fai si rompe. Non credo che ci siano dubbi su quale sia più affidabile o sicuro.

— Morg.

@Morg .: Non riesco a vedere come select *è più affidabile e sicuro. Se lo avevi usato select one, two from ...allora utilizzavi solo onee two; se thirdviene aggiunto alla tabella, non è necessario (qui), quindi non c'è motivo di recuperarlo. E se hai bisogno di usarlo improvvisamente, allora modificherai il codice, quindi potresti anche modificare la query a questo punto!

— Matthieu M.

@Morg .: Beh, sembra che stiamo parlando uno dopo l'altro, probabilmente perché le nostre esperienze sono diverse. Lavoro su prodotti in cui le prestazioni sono una proprietà fondamentale, e ciò significa che selectdevono essere il più selettivi possibile (e coperti da un indice), altrimenti sono brindisi (anche prima dei join obbligatori). Mi dispiace dirlo, ma l'approccio che stai descrivendo è stato un totale fallimento per quei prodotti.

— Matthieu M.,

5

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 di livello aziendale o DB potrebbe essere implementata senza un'interruzione reale. Nel peggiore dei casi, un utente dovrebbe sperimentare una pausa di 10-30 secondi quando le modifiche diventano effettive.

Se le modifiche fossero puramente modifiche al codice del livello aziendale, potrebbero essere messe in coda e "inserite 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 UniData . 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ò.

— Dan McGrath
fonte

1

Ecco una prospettiva diversa, dal mondo dei sistemi di database integrati e dei sistemi integrati. I sistemi integrati includono varie apparecchiature di rete / infrastruttura di telecomunicazione 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 alla N + 1, senza interrompere la disponibilità del tuo sistema. Ora puoi eseguire l'aggiornamento del vecchio master e di qualsiasi altra replica alla versione N + 1.