[MySQL] Testomgeving

[Meijuh]

Hoi.

Ik zit met een vraag.
Ik schrijf voor mijn werk vaak een nieuwe functionaliteit voor een webapplicatie. Om deze goed te testen is een goede testomgeving nodig. We gaan nu een systeem opzetten die ervoor zorgt dat er een test-mysql-server is die precies dezelfde data bevat als de productie-server. Om preciezer te zijn: een exacte kopie van een database.
Stel dat ik nu mijn geprogrammeerde functie af heb en deze wil gaan testen in de testomgeving.
Maar deze functionaliteit moet data manipuleren van 1 tabel, maar dit zorgt er weer voor (met foreign keys) dat er data in 7 andere tabellen gewijzigd wordt.
En stel nu dat mijn functionaliteit niet goed werkt en dat de data in de testdatabase verkeerd gemanipuleerd wordt is er een manier om deze data weer in de oorspronkelijke staat terug te zetten?
Een hele backup terugzetten gaat niet, dit duurt 5-10 uur.
Handmatig delen van tabellen terugzetten is niet te doen.

Iemand een leuk idee?(een rollback/save state)?

[DukeBox]

rollback kan met innodb, anders zou je naar snapshotting kunnen kijken. Dat kan zefs standaard onder windows met VSS. Vrij eenvoudig om een scriptje te maken een halt doet van je database, een snapshot maakt en vervolgens weer opstart. Een restore is binnen enkele sec. gedaan. Vergeet niet na de restore meteen weer een nieuwe snapshot te maken, met het terugzetten van een VSS snapshot ben je het origineel kwijt.

[ Voor 19% gewijzigd door DukeBox op 31-10-2009 17:13 ]

[cariolive23]

Het wijzigen van data binnen een transactie en deze eventueel met een rollback ongedaan maken, dat is met innoDB geen probleem. Wanneer je echter de structuur van de database gaat aanpassen, bv. een extra kolom o.i.d., dat is niet mogelijk met MySQL/innoDB. Andere databases kunnen dat wel, MySQL niet. Wanneer je een DDL-opdracht geeft (bv. een ALTER TABLE) zal MySQL impliciet een commit uitvoeren, ook wanneer je dat niet wilt. Let hier heel goed op, je zal niet de eerste zijn die hiermee de mist in gaat.

[Meijuh]

Nu heb ik een andere vraag.

Wat is een goede manier om een test-database te synchroniseren met de productie server?
Ik zie zo 4 mogelijkheden:
- Automatisch een mysqldump doen elke nacht. (duurt waarschijnlijk veel te lang).
- De map (mysql/data/[database naam]) kopieren. (is dit een normale oplossing?).
- Synchronisatie software gebruiken. (duurt denk ik ook heel lang)
- MySQL replication: http://dev.mysql.com/doc/refman/5.0/en/replication.html (is dit bedoelt voor een testomgeving?)

Wat is een geschikte oplossing?

[burne]

Meijuh schreef op maandag 02 november 2009 @ 21:36:
Wat is een goede manier om een test-database te synchroniseren met de productie server?
Ik zie zo 4 mogelijkheden:
- Automatisch een mysqldump doen elke nacht. (duurt waarschijnlijk veel te lang).
- De map (mysql/data/[database naam]) kopieren. (is dit een normale oplossing?).
- Synchronisatie software gebruiken. (duurt denk ik ook heel lang)
- MySQL replication: http://dev.mysql.com/doc/refman/5.0/en/replication.html (is dit bedoelt voor een testomgeving?)

Eerst: wat is je probleem met een dump? Ik maakte iedere nacht een dump van een server met 2500 databases met gemiddeld 20-30 tabellen met honderden tot honderdduizenden rows in een uurtje, totaal iets van 16Gbyte aan data. Terugzetten duurde iets langer wegens indices, maar niet meer dan 1.5 uur.

Mysql-replicatie is een optie met een potentieele beperking. Als je tabellen aanpast in je slave zul je problemen krijgen met het wegschrijven van nieuwe records in de master naar de slave. Tabellen moeten identiek zijn. Records kunnen afwijken, zolang je key-fields maar identiek zijn.

Mappen kopieeren is een optie, maar alleen als je je 'master' stopt voor het kopieeren of je tables lockt. De procedures daarvoor staan ook beschreven in de mysql-documentatie, als 1 van de 2 manieren om een slave op te zetten.

[Meijuh]

burne schreef op maandag 02 november 2009 @ 21:46:
[...]


Eerst: wat is je probleem met een dump? Ik maakte iedere nacht een dump van een server met 2500 databases met gemiddeld 20-30 tabellen met honderden tot honderdduizenden rows in een uurtje, totaal iets van 16Gbyte aan data. Terugzetten duurde iets langer wegens indices, maar niet meer dan 1.5 uur.

Hmm ik gebruikte mysql administrator, die backup functie.
Later las ik de mysqldump functie en ik zag dat die gewoon sql produceerde.
Maar het kan best zijn dat als ik ook mysqldump < restorefile gebruik het wel sneller gaat, dit zou ik kunnen testen.
Als ik de restore functie gebruik in mysqladministrator dan duurt het restoren als snel 10 uur. Terwijl de database niet groter is dan 5 gigabyte.

Ik kan ga dit nog even testen

[Voutloos]

Dat is wellicht sowieso wel leuk om te testen, want dat moet flink sneller kunnen, wat tijdens (nood-) onderhoud ook wel handig kan zijn.

[Meijuh]

Kan ik met mysqldump een dumpfile direct lokaal opslaan in plaats van eerst op de (remote) server?
Er is namelijk geen ruimte op de server om het bestand daar eerst op te slaan.
Ik kan met putty (ssh) verbinding maken met de server.

[Voutloos]

Ja dat kan.

[Meijuh]

Heb je misschien een link naar een voorbeeld. Ik heb al wat rondgekeken op google, maar ik vind alleen voorbeelden waarbij ik het eerst remote moet opslaan.

[burne]

Meijuh schreef op maandag 02 november 2009 @ 22:15:
Kan ik met mysqldump een dumpfile direct lokaal opslaan in plaats van eerst op de (remote) server?

Putty komt met een commandline-variant. Met die is het een eitje:

code:

plink user@remotehost "mysqldump -h localhost -u mysqluser -pP@$$W3rD databasename | gzip -cf" > database.sql.gz

Dat levert je wel een gecomprimeerde database op, maar dat maakt voor enkel opslaan niet uit. Voor het uitpakken heb je iets als http://gnuwin32.sourceforge.net/packages/gzip.htm nodig.

Ik ga er vanuit dat je lokaal windows gebruikt. Als linux- of OS-X-gebruiker heb je waarschijnlijk gzip en gunzip al paraat, net zoals ssh:

code:

ssh user@host "mysqldump -h localhost -u mysqluser -pP@$$W3rD databasename | gzip -cf" | gunzip -c > database.sql

Je my.cnf goed 'tunen' doet overigens *wonderen* voor de snelheid van je database. Hoewel ik het verhaal begin over mailservers gaat het eigenlijk over mysql: http://www.nutz.nl/archiv...-hanging-fruit-first.html

[Meijuh]

burne schreef op maandag 02 november 2009 @ 22:31:
[...]

Putty komt met een commandline-variant. Met die is het een eitje:

code:

plink user@remotehost "mysqldump -h localhost -u mysqluser -pP@$$W3rD databasename | gzip -cf" > database.sql.gz

Dit vond ik ook al, ik heb het niet geprobeerd, maar met "-h localhost" geef je daar niet mee aan dat je verbinding maakt met de localhost?

[burne]

het tweede deel, na user@host, is een commando wat via ssh/plink remote uitgevoerd wordt. Dus localhost klopt, maar wel op je mysql-server, en da's precies wat je wilt.

De output van het commando komt via gzip en ssh/plink terug bij je, en dat schrijf je weg naar een bestand.

[Meijuh]

ah ok nice. ik dacht dat het bestand dan remote zou worden opgeslagen. ik ga dit morgens eens proberen.

bedankt.