Aggiornamento senza problemi di Azure quando lo schema del database cambia

Question

Supponiamo di avere una distribuzione di produzione e gestione temporanea utilizzando entrambi i loro database (SQL Azure). Se lo schema nella gestione temporanea è stato modificato e deve essere distribuito in produzione, esiste un modo definito per raggiungere l'aggiornamento del database nel database di produzione (senza tempi di inattività)?

ad es. Se scambio lo staging VIP < -> produzione (e allo stesso tempo automatizzo il cambiamento delle stringhe di connessione in qualche modo) qual è il miglior processo per automatizzare l'aggiornamento del database sql azure.

Il mio pensiero sarebbe quello di individuare la modifica dell'ambiente in RoleEnvironmentChanging (anche se non sono sicuro che lo scambio VIP spari anche RoleEnvironmentChanginng) ed eseguire lo script sql sul database to-be (cioè prod) in quel punto, tuttavia devo fare sicuro che lo script venga eseguito una sola volta e che ci saranno più istanze di transizione.

Answer 1

Così si dispone di un'implementazione di produzione che ha il proprio database SQL Azure e la distribuzione di staging che ha il proprio database SQL Azure. In questa situazione, entrambe le stringhe di connessione dell'applicazione hanno due diversi database.

Il primo requisito è quello di cambiare lo schema del database sul volo quando si scambia la distribuzione o fare qualcosa e ho il seguente problema con quel disegno:

1. Se si scrive qualsiasi codice all'interno del ruolo di fare Azione "UNA VOLTA E SOLO UNA VOLTA", non vi è alcuna garanzia che ciò accada solo una volta. Accadrà tempo multiplo dipende da diversi scenari come

   1.1 In ogni situazione che VM ha bisogno di essere re-imaging dal sistema e questo codice farà esattamente lo stesso ciò che ha fatto durante l'ultima Reimage

   1.2 Si potrebbe proteggere non succede all'avvio del ruolo o all'avvio della macchina virtuale da qualche metodo di registro di qualche chiave esterna ma esiste un meccanismo di prova completo che non si verifica.

2. A causa di esso vorrei suggerire quando si è pronti per scambiare le distribuzioni è possibile:

   2.1 Eseguire lo script per aggiornare lo schema di SQL Azure relativi alla produzione (con questo non avrà alcun impatto sul download dell'applicazione, perché non viene toccato ma mentre lo schema del database viene aggiornato, è possibile conoscere meglio l'impatto della propria applicazione)

   2.2 Modificare la configurazione nella distribuzione di gestione temporanea in modo che punti a SQL Azure di produzione (Non ci sarà alcun tempo di inattività dell'applicazione di produzione)

   2.3 SWAP il deplo yment (Ciò avrà anche senza downtime delle applicazioni)

Quindi, anche quando si aggiorna manualmente il DB Schema e poi scambiare il dispiegamento non c'è tempo di inattività significativo oltre il tempo prendere da DB per aggiornare lo schema.

Answer 2

Ho cercato le best practice per tutto questo e non ne ho trovato. Finora questo è quello che faccio:

• Deploy per mettere in scena (produzione è già in esecuzione)
• file di app_offline.htm Copia alla radice web su Produzione. In questo modo blocco gli utenti dall'utilizzo dell'applicazione, bloccando così le modifiche al database. Sto usando solo un'istanza.
• Eseguire il backup del database.
• Esegui script DDL, DML e SP. Questo aggiorna il database di produzione allo schema più recente.
• Applicazione di prova su Staging.
• Scambia VIP. Ciò riporta l'applicazione online poiché il file app_offline.htm non è presente su Staging (nuova produzione).
• Se qualcosa va storto, scambiare nuovamente VIP, ripristinare il database ed eliminare app_offline.htm.

Con questo approccio ho un tempo di inattività di ~ 5 minuti circa; il mio database è piccolo, il che è meglio che aspettare che Vm sia creato e che gli utenti ricevano errori.