Modifica tabella su database di produzione live

In che modo il sistema di database più "popolare" (MySQL, Postgres ...) gestisce le tabelle di modifica sui database di produzione live (come l'aggiunta, l'eliminazione o la modifica del tipo di colonne)?

So che il modo corretto è quello di eseguire il backup di tutti i tempi di inattività pianificati e quindi fare le modifiche.

Ma ... qualsiasi sistema di database corrente supporta queste operazioni "on-line" senza interrompere nulla? (forse solo ritardando le query che fanno riferimento a una colonna che è appena stata modificata / eliminata)

E cosa succede quando faccio un ALTER TABLE...database in esecuzione dal vivo? Tutto si ferma quando questo accade? I dati possono essere danneggiati? eccetera.

Ancora una volta, mi riferisco principalmente a Postgres o MySQL poiché questi sono ciò che incontro.

(E, sì, ogni volta che dovevo farlo prima di farlo "nel modo giusto", eseguendo il backup di cose, programmando downtine ecc ... ma voglio solo sapere se è possibile fare questo tipo e le cose "velocemente e dirty "o se esiste un sistema DB che supporta effettivamente modifiche dello schema" veloci, attive e sporche ")

Qualcuno ha appena suggerito il cambio di schema online per MySQL dallo script di Facebook (con un tutorial qui e fonte qui ) ... sembra un bel modo per automatizzare una serie di modi "hacky" per farlo ... qualcuno lo ha mai usato qualcosa somiglia alla produzione?

Quando si emette un ALTER TABLEPostgreSQL , ci vorrà un ACCESS EXCLUSIVEblocco che blocca tutto compresoSELECT . Tuttavia, questo blocco può essere molto brevi se la tabella non richiede ri-scrittura, non nuovi UNIQUE, CHECKo FOREIGN KEYvincoli hanno bisogno di costose scansioni full-tabella per verificare, etc.

In caso di dubbio, in genere puoi semplicemente provarlo! Tutto il DDL in PostgreSQL è transazionale, quindi è bene annullare un ALTER TABLEse impiega troppo tempo e inizia a trattenere altre query. I livelli di blocco richiesti da vari comandi sono documentati nella pagina di blocco .

Alcune operazioni normalmente lente possono essere accelerate per essere sicure da eseguire senza tempi di inattività. Ad esempio, se si dispone di una tabella te si desidera modificare la colonna customercode integer NOT NULLin textperché il cliente ha deciso che tutti i codici cliente devono ora iniziare con un X, è possibile scrivere:

ALTER TABLE t ALTER COLUMN customercode TYPE text USING ( 'X'||customercode::text );

... ma ciò bloccherebbe l'intera tabella per la riscrittura. Quindi l'aggiunta di una colonna con a DEFAULT. Può essere fatto in un paio di passaggi per evitare il blocco lungo, ma le applicazioni devono essere in grado di far fronte alla duplicazione temporanea:

ALTER TABLE t ADD COLUMN customercode_new text;
BEGIN;
LOCK TABLE t IN EXCLUSIVE MODE;
UPDATE t SET customercode_new = 'X'||customercode::text;
ALTER TABLE t DROP COLUMN customercode;
ALTER TABLE t RENAME COLUMN customercode_new TO customercode;
COMMIT;

Questo consentirà di evitare solo le scritture a tdurante il processo; il nome del lucchetto EXCLUSIVEè in qualche modo ingannevole in quanto esclude tutto tranneSELECT ; la ACCESS EXCLUSIVEmodalità è l'unica che esclude assolutamente tutto. Vedi le modalità di blocco . Esiste il rischio che questa operazione possa eseguire il rollback del deadlock a causa dell'aggiornamento del blocco richiesto da ALTER TABLE, ma nella peggiore delle ipotesi dovrai rifarlo.

Si può anche evitare che il blocco e fare il tutto in diretta con la creazione di una funzione di trigger su tche ogni volta che una INSERTo UPDATEviene in, inserisce automaticamente customercode_newda customercode.

Ci sono anche strumenti integrati come CREATE INDEX CONCURRENTLYe che ALTER TABLE ... ADD table_constraint_using_indexsono progettati per consentire ai DBA di ridurre le durate di blocco esclusive facendo un lavoro più lentamente in un modo concorrenziale.

Lo pg_reorgstrumento o il suo successore pg_repackpossono essere utilizzati anche per alcune operazioni di ristrutturazione dei tavoli.

Percona ha messo a punto un proprio strumento per eseguire modifiche allo schema online

Lo strumento si chiama pt-online-schema-change

Implica i trigger, quindi leggi attentamente la documentazione.

Secondo la documentazione, le principali operazioni eseguite sono

• Controlli di sanità mentale
• chunking
• Modifica dello schema online
  • Crea e modifica la tabella temporanea
  • Cattura le modifiche dalla tabella alla tabella temporanea
  • Copia le righe dalla tabella alla tabella temporanea
  • Sincronizza la tabella e la tabella temporanea
  • Scambia / rinomina la tabella e la tabella temporanea
  • Pulire

Arrestare il sistema e apportare tutte le modifiche contemporaneamente può essere molto rischioso. Se qualcosa va storto, e spesso lo fa, non è possibile tornare indietro.

Come sviluppatore Agile, a volte ho bisogno di refactoring delle tabelle senza tempi di inattività, poiché tali tabelle vengono modificate e lette.

L'approccio seguente presenta un rischio basso, poiché la modifica viene eseguita in diversi passaggi a basso rischio che sono molto facili da ripristinare:

• Assicurarsi che tutti i moduli che accedono alla tabella siano ben coperti da test automatici.
• Crea una nuova tabella. Modificare tutte le procedure che modificano la vecchia tabella, in modo che modifichino sia le vecchie che le nuove tabelle.
• Migrare i dati esistenti in una nuova struttura. Fallo in batch di piccole dimensioni, in modo che non influisca seriamente sulle prestazioni complessive sul server.
• Verificare che la migrazione dei dati sia riuscita.
• Reindirizzare alcune delle procedure di selezione dalla vecchia tabella a quelle nuove. Utilizzare test automatici per assicurarsi che i moduli modificati siano ancora corretti. Assicurati che le loro prestazioni siano accettabili. Distribuire le procedure modificate.
• Ripetere il passaggio precedente fino a quando tutti i report utilizzano la nuova tabella.
• Modificare le procedure che modificano le tabelle, in modo che accedano solo alla nuova tabella.
• Archivia la vecchia tabella e rimuovila dal sistema.

Abbiamo usato questo approccio molte volte per modificare grandi tabelle di produzione live senza tempi di inattività, senza alcun problema.

Sì, molti database moderni ti permetteranno solo di aggiungere una colonna o modificare le caratteristiche di una colonna, come aggiungere o rimuovere nullable.

Se si rilascia una colonna, i dati andranno persi, ma non c'è molta paura della corruzione.

Lo strumento Percona utilizza i trigger per facilitare l'alterazione e non funziona bene se il tuo tavolo ha già dei trigger esistenti. Ho finito per scriverne uno che in realtà gestisce bene i trigger esistenti, poiché sono estremamente importanti per il nostro database https://github.com/StirlingMarketingGroup/smg-live-alter

Per rispondere alla domanda su cosa succede con ALTER TABLEun'affermazione, dipende dall'entità delle modifiche. In casi specifici, se si aggiunge una nuova colonna, almeno in MS SQL Server, il motore creerà una copia temporanea della tabella, mentre crea la nuova definizione della tabella e quindi inserisce nuovamente i dati. Per la durata della modifica, la tabella sarebbe quindi inaccessibile agli utenti.

Un esempio delle operazioni specifiche per il server MSSQL è qui: http://support.microsoft.com/kb/956176/en-us

Suppongo che altri RMDB abbiano metodi simili, anche se l'implementazione esatta sarebbe qualcosa che dovresti verificare con la documentazione del fornitore.