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:
- Il server Web sul nodo A viene prelevato off-line; il traffico continua ad essere elaborato dal server Web sul nodo B.
- Le modifiche dello schema di transizione vengono applicate ai server DB
- Server Web Viene aggiornato un code-base, le cache vengono cancellate e vengono eseguite tutte le altre azioni di aggiornamento.
- Il server Web A viene portato in linea e il server Web B viene portato offline.
- Il code-base del server Web B viene aggiornato, le cache vengono cancellate e vengono eseguite tutte le altre azioni di aggiornamento.
- Il server Web B è online.
- 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:
-
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.
-
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.