È possibile estrarre i valori del mese scorso da un server MySQL e creare un nuovo database da tali valori?


8

Ho un compito per costruire un modello di macchina virtuale di sviluppo.

Devo aggiungere al server database MySQL da ciascuno dei prodotti della mia azienda in modo che i nuovi sviluppatori possano sviluppare per ciascuno dei prodotti.

La maggior parte dei database ha dimensioni inferiori a 1 GB.

Ma ho alcuni database che sono enormi (circa 160 G), ma sono limitato nella dimensione del modello che sto cercando di creare e non è ragionevole aggiungere lì un DB di 160 GB.

Pertanto, sto cercando di trovare il metodo giusto per estrarre, diciamo, i valori del mese scorso da questo enorme database e aggiungerli al server in modo che lo sviluppatore sarà in grado di "sentire" com'è lavorare su questo database.

È possibile fare una cosa del genere e come viene fatto? Grazie!

Modificare:

Sfortunatamente, non esiste un'opzione per un server DB principale separato che conterrà tutti i database di sviluppo, inoltre non è necessario aggiornare i dati regolarmente, ho solo bisogno di presentare gli stessi dati dei server di produzione (in un periodo di tempo casuale) come ambiente sandbox per i nuovi sviluppatori.

Risposte:


8

Se ho capito bene, stai pianificando di creare una copia DB separata per ciascun ambiente di sviluppo.

Anche se questo potrebbe essere fattibile con database di piccole dimensioni, non funzionerà altrettanto bene con database di grandi dimensioni. Quindi, a meno che tu non abbia una buona ragione per configurare un DB separato per ogni ambiente, potrebbe essere meglio considerare di avere una singola copia del database di sviluppo e impostare tutti gli ambienti di sviluppo per usarlo.

Questo approccio ti consentirà di aggiornare periodicamente il DB di sviluppo con gli ultimi dati e se qualcuno lo incasina, puoi semplicemente aggiornarlo di nuovo.

Immagina anche la situazione in cui i tuoi sviluppatori iniziano a lavorare su alcuni nuovi progetti che richiedono la creazione di nuove tabelle. Se hai una singola copia del DB di sviluppo, tu (o gli sviluppatori) dovrai creare quelle tabelle e riempirle di dati di test una sola volta. Ora immagina che gli sviluppatori si rendano conto che la struttura iniziale della tabella non è ottimale e deve essere modificata. Ancora una volta ciò dovrà essere fatto su un singolo DB al contrario di decine di ambienti.

Questo è l'approccio che ho visto essere utilizzato più volte per grandi progetti e il più delle volte funziona abbastanza bene.


2
In un negozio in cui lavoro, ogni sviluppatore ha la propria copia del database in modo che nessuno passi sui piedi degli altri. Questo ha funzionato molto bene per noi. Disponiamo di script per ricostruire il database da zero e popolarlo con i dati di test richiesti per lo sviluppo. Il singolo database è stato spesso problematico con le persone che lavorano in alcune aree del database rompendolo per altre persone. E poi tutti si fermano mentre viene ripristinato un grande db. Quindi avere un singolo database NON è una soluzione superiore. (TBH non lo è. È situazionale.)
Andrew Savinykh,

Concordato. Solo per curiosità, quanto sono grandi i tuoi DB? Non riesco a vedere come questo potrebbe funzionare con un DB di dimensioni di 160 GB.
Grekasius,

Naturalmente i database degli sviluppatori sarebbero intenzionalmente piccoli con solo il sottoinsieme di dati richiesti per testare qualunque cosa gli sviluppatori stiano lavorando. Per scopi come il test delle prestazioni verrebbe utilizzata un'istanza separata (più grande).
Andrew Savinykh,

Non sono tenuto ad aggiornare i dati regolarmente, ma solo per inserirlo una volta in questo modello.
Itai Ganot,

Dai un'occhiata se riesci a creare un piccolo set di dati di esempio dal tuo DB corrente. Purtroppo non esiste una risposta semplice qui. Quello che devi fare dipende da quali dati hai e cosa scegli di inserire in quel DB di sviluppo.
Grekasius,

4

Ciò dipende in larga misura dal tipo di dati nel database. In alcuni casi, potrebbe essere facile come

select * from table where date > ....

mentre in altri casi, è impossibile separarlo a causa della struttura dei dati. Alla fine, sarà probabilmente un mix e molto difficile da ottenere.


2
In particolare, alcuni database potrebbero contenere voci più recenti (ad esempio <1 mese) che fanno riferimento a record di voci precedenti (ad esempio> 1 mese). Il modo in cui li gestisci dipende interamente dalla modalità di impostazione di questi riferimenti ed è impossibile per tutti tranne i più elementari.
Bob,

0

Recentemente abbiamo avuto la situazione in cui un cliente voleva estrarre gli ultimi 30 giorni di un database. Se TUTTE le tabelle hanno lo stesso attributo in cui è possibile definire il datetime, è possibile eseguire un

mysqldump --where = 'datetimefield> "2014-06-28"'

ma voleva combinare tabelle diverse con dati vecchi e nuovi. Quindi questa non era una soluzione per lui, ma potrebbe esserlo per te?

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.