Come gestire uno script SQL di avvio una tantum

4

Sto cercando di capire il modo migliore per affrontare l'esecuzione di uno script SQL monouso all'avvio di un'istanza di servizio. Ecco lo scenario:

  • Eseguiamo più istanze Amazon del nostro servizio in parallelo.
  • Ogni istanza si connette allo stesso database MySQL.
  • Con ogni aggiornamento del servizio, vogliamo eseguire uno script SQL monouso per aggiornare lo schema del DB.
  • Vogliamo solo un'istanza per eseguire lo script.
  • Vogliamo che altre istanze attenderanno / blocceranno fino al completamento dell'aggiornamento.

La maggior parte delle operazioni nello script sono idempotenti e finora l'esecuzione dello script su tutte le istanze non rappresentava un problema. Le ultime modifiche includono alcune gocce di colonna e altre dichiarazioni non idempotenti. Questi stanno causando errori durante l'avvio.

Posso pensare ad alcuni modi per affrontare questo problema:

  • Designare un'istanza del server "primaria" per eseguire l'aggiornamento e avere non primari controlla che l'aggiornamento sia stato eseguito.
  • Blocco su una tabella specifica prima di eseguire lo script e il rilascio del blocco solo al termine dell'aggiornamento.
  • Racchiudere con cura ogni istruzione non idempotente nei controlli.

Quali problemi esistono con queste potenziali soluzioni? C'è un approccio migliore? Esiste un approccio best-practice?

    
posta Nick Gotch 19.05.2016 - 17:03
fonte

2 risposte

3

Solo opzione tre

Carefully wrapping each non-idempotent statement in checks.

ha qualche appello per me.

Questa opzione è l'unica che non richiede che lo script dipenda da qualsiasi altra cosa (hardware, software o altro) per la sua funzione appropriata.

    
risposta data 19.05.2016 - 20:06
fonte
0

Riesco a vedere il n. 3 che introduce alcune condizioni di gara potenzialmente pericolose, e anche il n. 1 potrebbe soffrire di una condizione di competizione se l'aggiornamento dello schema avviene subito dopo che un'altra istanza si è connessa al database. Se si prende in prestito una tecnica dalle migrazioni di Active Record e si designa una tabella per tenere traccia della versione dello schema, non solo è possibile bloccare in modo sicuro la tabella, ma è anche possibile verificare facilmente che non si effettui la stessa modifica dello schema due volte per errore.

    
risposta data 21.05.2016 - 09:11
fonte

Leggi altre domande sui tag