Load Balancer
Per il secondo punto, utilizzare un bilanciatore di carico adatto. È possibile spostare una parte del traffico attraverso, prima per dimostrare la nuova implementazione, quindi accelerare lentamente. Permette anche una rapida strategia di backout.
Controllo delle versioni del database
Ci sono due modi per farlo:
- Rendi compatibile il modulo dati autoritativo (lo schema SQL) con versioni precedenti di Green / Blue (qualsiasi versione precedente dello schema / procs / etc può essere abbandonata / cancellata / scaricata).
- Spostare l'origine autorevole dei dati altrove e trattare lo schema SQL come una vista aggiornata dinamicamente. È sufficiente ricreare quella vista su ogni distribuzione con tutti i procs / schema / ecc con un prefisso di versione di qualche tipo.
Nel primo metodo, potrebbe essere opportuno distanziare l'applicazione dalla rappresentazione dei dati e spostare tutti i trasferimenti di dati tramite le stored procedure. Ciò garantisce un'interfaccia pulita che può essere portata in avanti. Ciò consente al percorso di migrazione di essere come:
- Crea nuovi tipi / tabelle e aggiungi solo nuove colonne alle tabelle correnti, effettua qualsiasi pulizia della vecchia versione.
- Distribuire stored procedure in grado di gestire strutture di dati vecchie e nuove. Leggi tutto, scrivi nuovo.
- Eseguire la migrazione dei dati e il massaggio essenziali per la nuova distribuzione.
- Scambia il traffico sull'applicazione appena distribuita.
- Esegui qualsiasi ulteriore migrazione e massaggio dei dati per eseguire il porting alla nuova struttura dati.
- Attendi una nuova distribuzione o distribuisci stored procedure in grado di gestire solo le nuove strutture dati.
- se non in attesa esegue la pulizia di vecchi dati, processi memorizzati, tabelle, ecc ...
Se questo sembra troppo complesso, o eseguire manipolazioni su dati in tempo reale è troppo pericoloso, spostare la definizione di ciò che è autorevole in un'altra fonte di dati potrebbe essere ciò di cui hai bisogno. Con questo non importa più cosa ci sia nell'archivio dati sql (a meno che non stia memorizzando il registro eventi nel qual caso tranne quella parte). La distribuzione ora sembra:
- Crea nuovo schema, proc stored, tipi, ecc. con un nuovo spazio dei nomi o con un prefisso.
- Esegui la scansione del registro eventi dal primo record, aggiorna lo schema come pertinente.
- Una volta raggiunti in gran parte, passa lentamente il traffico alla nuova distribuzione.
- gli utenti della vecchia distribuzione possono ancora interagire con gli utenti nella nuova distribuzione, entrambi leggono il registro eventi e ricevono gli aggiornamenti.
- Se sei felice che tutti siano nella nuova distribuzione e non sia necessario eseguire il rollback, interrompi il vecchio sistema.
- cancella il vecchio schema, procs, ecc ...
L'applicazione dovrà inserire i dati due volte, prima nel registro eventi, quindi dovrà leggere il registro eventi e aggiornare i dati della tabella associati. Tra l'altro, questo permetterà a diverse versioni del prodotto di lavorare insieme per un po 'di tempo a costo di un lavoro extra.