Zero downtime Deployment - Transitional Db Schema

13

Raggiungere la Zero downtime Deployment ha toccato lo stesso problema ma ho bisogno di qualche consiglio su una strategia che sto considerando.

Contesto

Un'applicazione web-based con Apache / PHP per l'elaborazione lato server e MySQL DB / filesystem per la persistenza.

Attualmente stiamo costruendo l'infrastruttura. Tutti gli hardware di rete avranno ridondanza e tutti i cavi di rete principali saranno utilizzati in coppie legate per tolleranza di errore. I server vengono configurati come coppie di disponibilità elevata per la tolleranza agli errori hardware e verranno bilanciati in base al carico di tolleranza degli errori delle macchine virtuali e alle prestazioni generali.

Il mio intento è che siamo in grado di applicare aggiornamenti all'applicazione senza tempi di inattività. Mi sono preso molta cura durante la progettazione dell'infrastruttura per garantire che possa fornire il 100% di up-time; sarebbe estremamente deludente avere quindi 10-15 minuti di inattività ogni volta che veniva applicato un aggiornamento. Ciò è particolarmente significativo in quanto intendiamo avere un ciclo di rilascio molto rapido (a volte può raggiungere uno o più rilasci al giorno.

Topologia di rete

Questo è un riepilogo della rete:

                      Load Balancer
             |----------------------------|
              /       /         \       \  
             /       /           \       \ 
 | Web Server |  DB Server | Web Server |  DB Server |
 |-------------------------|-------------------------|
 |   Host-1   |   Host-2   |   Host-1   |   Host-2   |
 |-------------------------|-------------------------|
            Node A        \ /        Node B
              |            /            |
              |           / \           |
   |---------------------|   |---------------------|
           Switch 1                  Switch 2

   And onward to VRRP enabled routers and the internet

Nota: i server DB utilizzano la replica master-master

Strategia suggerita

Per riuscirci, attualmente sto pensando di rompere gli script di aggiornamento dello schema DB in due parti. L'aggiornamento sarebbe simile a questo:

  1. Il server Web sul nodo A viene prelevato off-line; il traffico continua ad essere elaborato dal server Web sul nodo B.
  2. Le modifiche dello schema di transizione vengono applicate ai server DB
  3. Server Web Viene aggiornato un code-base, le cache vengono cancellate e vengono eseguite tutte le altre azioni di aggiornamento.
  4. Il server Web A viene portato in linea e il server Web B viene portato offline.
  5. Il code-base del server Web B viene aggiornato, le cache vengono cancellate e vengono eseguite tutte le altre azioni di aggiornamento.
  6. Il server Web B è online.
  7. Le modifiche dello schema finale vengono applicate al DB

'Schema di transizione' sarebbe progettato per stabilire un DB compatibile tra versioni. Ciò si avvantaggerebbe principalmente di visualizzazioni di tabelle che simulano lo schema della versione precedente mentre la tabella stessa verrebbe modificata nel nuovo schema. Ciò consente alla versione precedente di interagire con il DB normalmente. I nomi delle tabelle includevano i numeri di versione dello schema per garantire che non ci fosse alcuna confusione su quale tabella scrivere.

'Schema finale' rimuoverà la retrocompatibilità e riordinerà lo schema.

Domanda

In breve, funzionerà?

in particolare:

  1. Ci saranno problemi a causa del potenziale di scrittura simultanea nel punto specifico della modifica dello schema transitorio? C'è un modo per assicurarsi che il gruppo di query che modifica la tabella e crei la vista compatibile con le versioni precedenti sia eseguito consecutivamente? vale a dire con qualsiasi altra query mantenuta nel buffer fino al completamento delle modifiche dello schema, che in genere saranno solo millisecondi.

  2. Esistono metodi più semplici che forniscono questo grado di stabilità e consentono anche aggiornamenti senza tempi di attesa? Si preferisce anche evitare la strategia dello schema "evolutivo" in quanto non desidero essere bloccato nella compatibilità con schemi a ritroso.

posta Marvin 27.01.2016 - 17:14
fonte

2 risposte

4

Sembra che quello che stai cercando non sia tanto la disponibilità elevata quanto sarebbe necessario Disponibilità continua .

Essenzialmente il tuo piano funzionerà, ma sembra che tu abbia notato che il difetto principale nella tua configurazione è che le modifiche allo schema del database in una versione potrebbero comportare il downtime o il malfunzionamento del nodo ancora disponibile per il corretto funzionamento. L'approccio Continuous Availability risolve questo essenzialmente creando un numero di ambienti di produzione.

Produzione uno

Questo ambiente è la versione in tempo reale del software che viene utilizzato dagli utenti. Ha i suoi server Web, server di applicazioni, server di database e tablespace. Funziona indipendentemente da qualsiasi altro ambiente. Il Load Balancer che possiede l'endpoint di risoluzione del dominio per questi servizi punta attualmente a questi server Web.

Produzione due

Questo è fondamentalmente un ambiente di staging di rilascio identico a Production One. Puoi eseguire i tuoi aggiornamenti di rilascio qui e fare i test di sanità prima del tuo evento dal vivo. Ciò consente anche di eseguire in modo sicuro le modifiche al database in questo ambiente. Il Load Balancer non punta attualmente a questo ambiente.

Produzione DR

Questo è un altro duplicato in un data center separato che si trova in una regione diversa del mondo. Ciò consente di eseguire il failover in caso di eventi catastrofici eseguendo un commutatore DNS su Load Balancer.

Vai a vivere

Questo evento sta essenzialmente aggiornando il record DNS per passare a Production Two da Production One o viceversa. Questo richiede un po 'di tempo per propagarsi attraverso i server DNS del mondo, così da lasciare entrambi gli ambienti in esecuzione per un po'. Alcuni utenti potrebbero lavorare in sessioni esistenti sulla vecchia versione del software. La maggior parte degli utenti stabilirà nuove sessioni sulla versione aggiornata del software.

Migrazione dei dati

L'unico inconveniente qui è che non tutti i dati durante quella finestra sono disponibili per tutti gli utenti in quel momento. Nel database della versione precedente sono chiaramente presenti dati utente che ora devono essere migrati in sicurezza nel nuovo schema del database. Questo può essere ottenuto con uno script di esportazione e migrazione dei dati ben collaudato o un lavoro batch o un processo ETL simile.

Conclusione

Una volta completato completamente l'evento di rilascio, la produzione due è ora la tua principale e inizierai a lavorare sull'installazione della prossima versione a Production One per il prossimo ciclo di distribuzione.

Inconvenienti

Questa è una configurazione complessa dell'ambiente e richiede una grande quantità di risorse di sistema, spesso due o tre volte le risorse di sistema per fare con successo. Operare in questo modo può essere costoso, specialmente se si dispone di sistemi molto pesanti per l'uso pesante.

    
risposta data 27.01.2016 - 19:47
fonte
2

La tua strategia è solida. Vorrei solo considerare di estendere lo "Schema di transizione" in un set completo di "tabelle di transazione".

Con le tabelle delle transazioni, le SELECT (query) vengono eseguite rispetto alle tabelle normalizzate per garantire la correttezza. Ma tutti i database INSERT, UPDATE e DELETE vengono sempre scritti nelle tabelle di transazioni denormalizzate.

Quindi un processo concorrente separato applica le modifiche (magari utilizzando stored procedure) alle tabelle normalizzate in base alle regole aziendali e ai requisiti dello schema stabiliti.

Il più delle volte, questo sarebbe praticamente istantaneo. Ma separare le azioni consente al sistema di contenere ritardi di attività e di aggiornamento dello schema eccessivi.

Durante le modifiche dello schema sul database (B), gli aggiornamenti dei dati sul database attivo (A) andavano nelle sue tabelle di transazione e venivano immediatamente applicati alle sue tabelle normalizzate.

Per eseguire il backup del database (B), le transazioni da (A) verrebbero applicate scrivendole alle tabelle delle transazioni di (B). Una volta eseguita tale parte, (A) potrebbe essere disattivato e le modifiche dello schema verranno applicate lì. (B) finirebbe applicando le transazioni da (A) mentre gestiva anche le sue transazioni live che farebbero la coda proprio come (A) e le "vivi" sarebbero state applicate allo stesso modo quando (A) tornava indietro.

Una riga della tabella delle transazioni potrebbe essere simile a ...

| ROWID | TRANSNR | DB | TABLE | SQL STATEMENT
    0        0       A    Name   INSERT INTO Name ...
    1        0       A    Addr   INSERT INTO Addr ...
    2        0       A    Phone  INSERT INTO Phone ...
    3        1       A    Stats   UPDATE Stats SET NrOfUsers=...

Le "tabelle" di transazione potrebbero essere effettivamente righe in un database NoSQL separato o anche file sequenziali, a seconda dei requisiti di prestazione. Un vantaggio è che la codifica dell'applicazione (sito Web in questo caso) diventa un po 'più semplice poiché scrive solo sulle tabelle delle transazioni.

L'idea segue gli stessi principi della contabilità a partita doppia e per ragioni simili.

Le tabelle delle transazioni sono analoghe a un "diario" di contabilità. Le tabelle completamente normalizzate sono analoghe a un "libro mastro" di contabilità, in cui ogni tabella è simile a un "account" di contabilità.

Nella contabilità, ogni transazione ottiene due voci nel giornale. Uno per l'account del conto contabile "addebitato" e l'altro per l'account "accreditato".

In un RDBMS, un "journal" (tabella delle transazioni) ottiene una voce per ogni tabella normalizzata che deve essere modificata da quella transazione.

La colonna DB nell'illustrazione tabella sopra indica su quale database ha avuto origine la transazione, consentendo così di filtrare le righe in coda dall'altro database e di non riapplicarle quando viene eseguito il backup del secondo database.

    
risposta data 29.01.2016 - 10:59
fonte

Leggi altre domande sui tag