Quali pratiche o strumenti consentono la distribuzione continua di database?

La consegna continua o la distribuzione continua di infrastruttura e codice è relativamente semplice rispetto a provare gli stessi approcci per database, in particolare RDBMS. Codice e infrastruttura non cambieranno o evolveranno una volta completata la distribuzione. I database, tuttavia, avranno nuovi dati aggiunti a loro rendendo i dati se non lo schema componenti intrinsecamente mutabili.

Sono consapevole che esistono pratiche come l'aggiunta di soli oggetti di database, ovvero tabelle e colonne, senza mai modificarli o rimuoverli - questo modo puramente additivo di avvicinarsi agli schemi di database ha il vantaggio di garantire che gli schemi siano retrocompatibili a scapito di successi più complicati schemi.

Allo stesso modo ci sono prodotti come Flyway e Ready Roll che aiutano a scrivere le migrazioni da scrivere tra le versioni di uno schema.

Quali altre pratiche e strumenti esistono attualmente per consentire la distribuzione continua di schemi di database in un ambiente di produzione in cui l'integrità dei dati è preoccupante?

Pramod Sadalage e Scott Ambler hanno scritto un libro Refactoring D Database: Evolutionary Database Design che è un primer incredibilmente solido sull'argomento dei DB in una organizzazione / squadra di CD.

Le sfide

Sono consapevole che esistono pratiche come l'aggiunta di soli oggetti di database, ovvero tabelle e colonne, senza mai modificarli o rimuoverli

In un'azienda per cui ho lavorato, una finestra mobile di dati grezzi equivaleva a circa 6 mesi e ha consumato fino a 10 TB. I dati sono stati quindi elaborati in un formato RDBMS che costava 6 TB di dati utilizzabili che rappresentavano circa 10 anni di dati da segnalare. Il punto è che su larga scala, questo tipo di pratiche non sono semplicemente pratiche. Lo spazio di archiviazione è costoso - probabilmente la più grande spesa di calcolo. Ciò offre diverse sfide interessanti:

1. Backup : i plugin innodb sono fantastici e tutti, ma i tempi di backup su così tanti dati non sono poi così pratici
2. Tempi di ripristino - per set di dati di grandi dimensioni - soprattutto se è necessario eseguire la replica per recuperare dopo che un ripristino per tornare a uno stato operativo può richiedere giorni o addirittura settimane
3. Creazione / seeding di nuove istanze : spesso il lavoro che si sta svolgendo in sviluppo / test comporta processi ETL (Estrai, Trasforma e Carica) nel set di dati. Questi devono essere convalidati utilizzando le unità di test QA, ma ciò deve essere fatto in modo non distruttivo in modo da preservare il set di dati di produzione originale. Durante un disastro, potresti essere disposto a gestire un lungo periodo di ripristino sulla comprensione del fatto che i backup sono una polizza assicurativa e l'intenzione è di evitarli, il flusso di lavoro di sviluppo DevOps richiede che, essenzialmente, tu sia in grado di eseguire un ripristino o copia dei dati su base regolare (forse più volte al giorno)
4. Capacità : la gestione di molti dati sulla scala appena descritta può richiedere molto I / O. Non solo devi affrontare i problemi descritti in 1-3, ma devi farlo in un modo che non causi interruzioni o rallentamenti delle prestazioni dei tuoi sistemi di produzione.

Mentre le considerazioni di cui sopra potrebbero non essere una preoccupazione su scale più piccole, su scale più grandi, questi diventano enormi problemi. Ciò significa che è estremamente importante definire i requisiti e prevedere le dimensioni del set di dati.

Definizione dei requisiti

Di conseguenza, è necessario definire diversi requisiti:

1. RTO - RTO o Restore Time Objective per i backup sono uno dei driver più importanti delle soluzioni di backup del database. Mentre all'inizio potrebbe non sembrare pertinente per la maggior parte degli altri problemi, diventa estremamente rilevante quando mi chiedi "Cosa succede se ho usato la mia soluzione di backup per creare o eseguire il seeding di nuove istanze?". Tratterò alcune tecniche per farlo nella prossima sezione.
2. RPO - RPO o Obiettivo punto di ripristino per i backup definisce A) quanto tempo è possibile ripristinare (minuti, ore, giorni, settimane, mesi o anni) B) L'intervallo di backup a diversi livelli e C) con quanta precisione è possibile ripristinare . Ad esempio, per i database di posta elettronica, vengono spesso cercati backup a livello di messaggio - ripristino di una specifica posta elettronica. Allo stesso modo, potresti scoprire che i dati nel giro di pochi giorni sono completamente inutili, quindi non ha senso ripristinare un anno.
3. Dimensioni del set di dati : questo è importante perché per un database da 1 MB, l'RTO può essere realizzato con la maggior parte dei prodotti e delle soluzioni di backup. Tuttavia, per un database da 10 TB, scoprirai che un backup completo a livello di riga sul nastro LTO 3 probabilmente non raggiungerà il tuo RTO e potrebbe interferire con il tuo RPO perché i backup iniziano a superare la finestra di backup. Non puoi semplicemente fare un mysqldump su un set di dati così grande, ma probabilmente potresti farcela con questo sul database da 1 MB.
4. Coerenza del database - Un'ultima cosa che fa un'enorme differenza nella distribuzione continua, nell'affidabilità del sito, nella scalabilità e nell'alta disponibilità quando si lavora con i database è la necessità (o la mancanza di ciò) di coerenza. Esistono tre tipi di base: coerenza immediata, coerenza Just-In-Time (JIT) ed eventuale coerenza

Oltre alle precedenti considerazioni principali, è necessario considerare anche i requisiti di licenza e supporto (open source o closed source; in house support, supporto di terze parti o supporto del fornitore) requisiti di applicazione / lingua (i connettori per molti database possono essere importanti; è la tua app è compilata? Hai accesso al codice sorgente? Puoi ricompilarlo o è fornito da un fornitore? O funziona in un linguaggio interpretato?) Requisiti politici (La tua organizzazione si fida solo di Oracle? Odiano l'oracolo? ? Non si fidano di MySql? Cosa ne pensi di MariaDB o Postgres?) E del motore di database (innoDB? MyISAM? Blackhole? NDB Cluster? Spider?) E requisiti storici o di compatibilità (abbiamo usato PL / SQL per anni e metà del nostro codice è integrato nel motore Oracle! Come potremmo mai portarci su MariaDB?!?)

Tutte queste cose (significativamente) incidono sugli strumenti a tua disposizione.

Alcune opzioni per la gestione interna dei dati

Nota: quanto segue non è esaustivo e gli altri utenti SE dovrebbero intervenire con ulteriori suggerimenti.

Con le considerazioni generiche fuori mano, lascia che ti fornisca alcune tecniche e tecnologie per affrontare quanto sopra. Innanzitutto, chiediti se hai davvero bisogno di usare un RDBMS o se i dati non strutturati con qualcosa come Hadoop, CouchDB o anche Object Oriented Storage (qualcosa come swift) sono un'opzione.

In secondo luogo, considera la possibilità di esaminare una soluzione basata su cloud. Ciò esternalizza parte di questo mal di testa e lascia i complicati problemi a persone altamente qualificate (e pagate). Su vasta scala, tuttavia, puoi trovare che questo influisce davvero sul tuo budget (i fornitori di servizi cloud ne traggono profitto e, a una certa scala, puoi semplicemente permetterti di impiegare questi esperti tu stesso) o se stai lavorando in sicurezza o politica specifica requisiti (leggi: non possiamo fare cloud) considerare un filer ibrido NFS / FibreChannel. La maggior parte di questi filer, come quelli di NetApp, Pure Storage e Tegile, supporta una tecnica di snapshot e clonazione basata su delta che può essere molto utile per A) eseguire backup, B) Ripristinare backup e C) Effettuare il seeding di nuovi backup.

A questo punto, devo notare che non sono un esperto di backup e archiviazione, quindi ci sono alcune parti di questo problema che non sono mai stato in grado di risolvere prima di passare ad altri problemi (e pascoli più verdi).

Ma questo detto, questi prodotti consentono di scattare istantanee differenziali sotto il vostro databse. Dovrai creare uno script di "tabelle di blocco con blocco di lettura" complete su una delle istanze del tuo database (si consiglia uno slave di sola lettura) e scaricare la posizione binlog o GTID, ma per questi filer, una volta fatto, sarai in grado per utilizzare questi snap per creare nuove istanze del database. Dovrai mettere i binlog su una partizione separata e mettere solo i dati del tuo database su queste partizioni. Una volta fatto, sarai in grado di clonare queste partizioni (su NetApps, questo è noto come " FlexClone "

Questo perché per ogni blocco letto il filer deve determinare se i dati risiedono nell'istantanea originale congelata o nel delta. Per volumi / negozi con più istantanee, potrebbe essere necessario verificarlo più volte. Puoi ovviare a questo aggiornando i dati (ovvero scartando la tua istantanea e clonandola di nuovo periodicamente - cosa che potrebbe accadere in modo naturale e organico per un buon ambiente di distribuzione continua) o dividendo permanentemente il volume (noto come "divisione flessibile" nella terminologia di NetApp ), che richiederà un momento per risolvere definitivamente i delta e creare un volume completamente nuovo e separato.

Questi cloni delta hanno l'ulteriore vantaggio di ridurre i requisiti di archiviazione complessivi: è possibile generare diversi cloni o istanze dei dati del database di produzione per eseguire sviluppo, test e convalida. Se stai conservando solo una copia del tuo set di dati di grandi dimensioni più i piccoli delta (che probabilmente saranno), riduci i costi di archiviazione e il footprint complessivi.

L'unico trucco qui è che questo potrebbe non costituire una soluzione di backup completo poiché il "backup" risiede ancora nel tuo filer. Per questo potrebbe essere necessario utilizzare qualcosa che NetApp chiama Snap Mirror che rispecchierà i dati (utilizzando la tecnologia in stile rsync) tra filer e persino datacenter, oppure utilizzare un tipo di soluzione di backup integrata che può eseguire il backup su nastro di uno dei tuoi snapshot delta o un flex-clone.

Questo ha tuttavia un grosso difetto: tutti i tuoi dati - dev, test e prod stanno ancora usando l'I / O sullo stesso filer e sulla stessa testa di archiviazione. Per ovviare a questo, prendere in considerazione la creazione di un'istanza del database slave su un secondo filer che può essere il punto di seeding per il tuo test e / o dev filer, oppure prendere in considerazione l'utilizzo di un bilanciamento del carico / controller di consegna applcation per il livello dell'applicazione per rispecchiare le richieste di produzione nel ambienti di testing (e / o dev). Ciò ha l'ulteriore vantaggio di lanciare traffico di prodcution nell'ambiente QA / Test prima di promuoverlo alla produzione per problemi che potrebbero non essere immediatamente notati. È quindi possibile verificare la presenza di errori nei registri in base al traffico di produzione e al comportamento dell'utente.

Ciò dovrebbe quindi consentire di utilizzare alcuni script per generare e distruggere programmaticamente interi (e grandi) set di dati da utilizzare con metodologie di distribuzione continua.

Scalabilità e alta disponibilità

Mentre hai chiesto informazioni sulla distribuzione continua, DevOps non si preoccupa solo della distribuzione continua, quindi includerò alcune informazioni su ridondanza, scalabilità e disponibilità elevata.

Ho detto, JIT, coerenza immediata ed eventuale. È qui che entrano in gioco vari motori RDBMS. L'eventuale coerenza è relativamente semplice semplicemente configurando la replica asincrona circolare. Ciò può tuttavia causare alcune collisioni * (cosa succede se il livello dell'applicazione aggiorna i dati su un lato del cluster e sull'altro lato del cluster prima che la replica sia completata?) Per consistenza immediata, guarda il cluster Galera che forza la replica sincrona, ma causa problemi di scalabilità (come eseguirai la replica sul tuo sito di Disaster Recovery o il bilanciamento del carico geograficamente senza incorrere in una latenza significativa a causa del ritardo di propulsione a livello di rete?) Puoi anche vedere se puoi eseguire la replica sincrona all'interno del datacenter e la replica asincrona tra siti, ma questo sembra il peggiore di entrambi i mondi.

In genere, tuttavia, la maggior parte delle persone non ha bisogno di una replica completamente sincrona, di solito è necessaria solo per ambienti molto specifici (ed esotici) a scrittura elevata in cui è necessario il multi-master con lo sharding della tabella. La maggior parte delle app è in grado di gestire la coerenza Just-In-Time utilizzando un proxy del database. Ad esempio, ScaleArc monitorerà lo stato della replica e traccerà dove sono appena state scritte le scritture (per inviare richieste di lettura secondarie fino a quando la replica non raggiunge) per fornire coerenza e aspetto just-in-timedi coerenza del database. ScaleArc è compatibile con Postgres, MySQL, MariaDB, Oracle e MSSQL e può utilizzare espressioni regolari per frammentare / partizionare i database per applicazioni che non possono usare le chiavi shard. Ha anche una robusta API REST per interagire con il tuo software di gestione della configurazione - e il loro team di supporto è eccezionale

Allo stesso modo, potresti prendere in considerazione un'alternativa gratuita, MaxScale sviluppata dal team MariaDB per MariaDB. Manca tuttavia la GUI e alcune delle funzionalità di memorizzazione nella cache di ScaleArc.

Infine, il tessuto MySQL (e il solo cluster MySQL in-RAM - se puoi permetterti così tanta RAM) sono altri potenziali - specialmente con il nuovo proxy MySQL. Ciò può fornire la componente di ridondanza e scalabilità al proprio ambiente.

Postgres e Oracle dovrebbero avere le funzionalità di replica e sharding di cui hai bisogno, ma ScaleArc si accoppierà bene se hai bisogno di un proxy.

In definitiva, tutti questi peices si sommano a un ambiente altamente flessibile adatto alla distribuzione e allo sviluppo continui se non si è in grado di utilizzare semplicemente un ambiente basato su cloud e lasciare che il proprio fornitore di servizi cloud si occupi dei suddetti problemi.

Utilizziamo Flyway al lavoro per la gestione degli schemi di Postgres nell'app e Pillar per la gestione degli schemi di Cassandra. Lo abbiamo trovato migliore se l'app gestisce il proprio schema.

Abbiamo avuto una brutta esperienza con ansible gestire schemi prima che le applicazioni gestite i propri schemi.

Direi che uno strumento da solo non aiuterà davvero a meno che non si sposta la responsabilità dello schema sul team dell'applicazione.

Usiamo liquibase o flyway al lavoro, in cui il team applicativo è responsabile della creazione dei changeset.

Insieme a questo, puoi evitare un modo puramente additivo.
Ogni applicazione deve essere compatibile con la sua versione precedente, quando è necessario apportare una modifica dello schema, quindi l'applicazione integrerà una nuova colonna nello schema, scriverà su di essa e continuerà a leggere e scrivere da / alla colonna precedente (consentendo versione precedente per avere ancora gli stessi dati).
Alla prossima versione dell'applicazione è consentito interrompere l'aggiornamento della vecchia colonna e solo la terza versione potrà rimuovere la colonna ora non utilizzata.

Ovviamente, sono necessari backup regolari nel caso in cui qualcosa vada storto.
È anche una buona idea un sottoinsieme di dati che potrebbe creare problemi nei test di integrazione per evitarli nella produzione. Il caso ideale ottiene un sottoinsieme anonimo di dati di produzione.

Usiamo la liquibase nel nostro lavoro e parlerò bene per questo. Inoltre è utilizzato dal nostro strumento QA QASymphony .

Lo stiamo utilizzando all'interno dei database MSSQL e Oracle internamente e QASymphony lo utilizza / lo ha utilizzato con entrambe le istanze postgres + mysql.

Per rispondere a questa domanda nel contesto di un ambiente mainframe e specifico per i database DB2, in genere ci sono 2 alternative comunemente usate (non economiche ...) tra cui scegliere:

• Amministrazione oggetti per DB2 , da BMC. Ecco alcuni dettagli al riguardo (citazione dalla pagina collegata):

  Apportare modifiche agli oggetti nel database, o anche solo eseguire attività amministrative di routine, può essere un lavoro difficile e rischioso. Esistono dozzine di attività da tenere traccia e un singolo passo falso potrebbe avere un impatto disastroso sulla disponibilità e sull'integrità dei dati. Puoi ridurre sia gli sforzi che i rischi con BMC Object Administration per DB2 11, una raccolta di strumenti per aiutarti a:

  • Ridurre il tempo necessario per amministrare ambienti DB2 complessi e disparati.
  • Automatizza le attività di routine durante il ciclo di vita dell'applicazione per una migliore integrità.
  • Migliora la produttività con la navigazione del catalogo DB2 semplificata e la gestione delle modifiche.
  • Migliora la disponibilità delle applicazioni eseguendo modifiche e manutenzione con interruzioni minime.

• DB2 Administration Tool per z / OS , da IBM.

  Semplifica le complesse attività associate alla gestione sicura degli oggetti e dello schema DB2 durante il ciclo di vita dell'applicazione con il minor impatto possibile sulla disponibilità.

  • Consente agli utenti di navigare nel catalogo DB2 in modo rapido e semplice
  • Crea ed esegue istruzioni SQL dinamiche senza conoscere l'esatta sintassi SQL
  • Gestisce e tiene traccia delle modifiche apportate alle definizioni degli oggetti DB2 risolvendo eventuali conflitti prima dell'esecuzione
  • Aiuta a costruire comandi DB2 da eseguire su database e tabelle
  • Consente agli utenti di creare, modificare, migrare, eliminare e decodificare oggetti DB2
  • Crea ed esegue lavori di utilità, consentendo agli utenti di sfruttare LISTDEF e MODELLI per una maggiore produttività

Integrazione con strumenti SCM

Qualche tempo fa un cliente mi ha sfidato a "integrare" effettivamente l'alternativa BMC nel suo ciclo di vita SCM (gestito da SERENA ChangeMan ZMF ). L'idea alla base di tale integrazione è " Considera il nostro team DBA DB2 (facendo cose con DDL) come un caso speciale di un team di sviluppo, usando accidentalmente un editor esotico (lo strumento BMC) per produrre il codice (DDL) da migrare ".

L'unica (ma reale !) Sfida di questa integrazione era quella di facilitare anche la "restartability", che è uno dei principali vantaggi di tale strumento DBA:

• Restartability significa che quando questo strumento DBA sta facendo la sua cosa (tramite lavori a volte di lunga durata, secondo la natura del lavoro da completare), possono accadere cose inaspettate (deadlock, time abends, ecc.).

• Se si verifica una di queste cose e non si desidera riavviare dal backup (prima di iniziare), lo strumento DBA si aspetta che si riavvii dal punto (check-) da cui le cose hanno iniziato a non funzionare (e da dove vuoi che tutto venga rieseguito).

• Meglio ancora (o dovrei dire "anche peggio"?), Se un nuovo utente dello strumento DBA non sa davvero come ricominciare da tale punto di controllo e semplicemente riprova (dall'inizio), lo strumento DBA semplicemente fallirà con qualche tipo di errore dell'utente. E questo con un'indicazione con qualcosa del tipo " Fino a quando non mi dici come vuoi che proceda dopo il mio ultimo punto di fallimento, mi rifiuto di fare qualsiasi cosa (per non peggiorare le cose) ".

• Alla fine, il vero indizio per implementare questa restartabilità nello strumento SCM in uso, richiedeva che anche lo strumento SCM fosse sintonizzato. In realtà per consentirne l'utilizzo per il riavvio delle procedure SCM non riuscite (in genere legate alle consegne agli ambienti test / prod target) ... invece di inviare nuovamente la procedura SCM non riuscita (che è il modo in cui tali strumenti SCM si riprendono da tali situazioni ).

Bonus: dopo che l'integrazione SCM dell'alternativa BMC è stata completata, il cliente ha deciso di cambiare il suo strumento DBA con l'alternativa IBM. E anche se entrambe le alternative non sembrano davvero uguali, il suo impatto sull'integrazione di SCM è stato piuttosto minimo: semplicemente una questione di sostituzione (in qualche personalizzazione SCM riutilizzabile) di alcune chiamate all'alternativa BMC con equivalenti chiamate all'IBM alternativa ... che (usando la terminologia DevOps) è stata implementata da feature-flags / feature-toggles .