[PHP/MySQL] Hoe importeer jij zelf je backups ?

[Verwijderd]

Titel geeft misschien niet helemaal weer wat ik bedoel, maar dat is het volgende :

Wanneer ik een backup maak met phpmyadmin dan krijg ik een mooie tekstfile met alles erin en eraan.

Leuk... en als ik die file in stukken hak (omdat ze groot is) dan kan ik die zo terug importeren omdat ik geen shell access heb.

Nu was ik een kort scriptje aan het maken om die file lijn voor lijn uit te lezen om zo in korte blokken te kunnen inserten.

Maar nu was ik die output file van phpmyadmin aan het analyzeren en blijkt dat dat script op bepaalde onverwachte plaatsen ook returns en linefeeds zet. Dit maakt het heel moeilijk (lees : bijna onmogelijk) om die deftig te parsen om er zelf iets mee te doen.

Een hoop gegooglel levert niet veel nuttig op, buiten de melding dat de beste manier de command line is om dan zelf met mysqldump en mysql zelf een database te dumpen en in te voeren.

Maar zoals ik zei, die access heb ik niet bij mijn hoster.

Dus mijn vraag : hoe doen jullie het om op een betrouwbare manier een backup te maken en die probleemloos terug te zetten indien nodig ?

[Varienaja]

Ik werk vaker met Oracle, eigenlijk nooit met MySQL. Maar dat zal niet al teveel uitmaken.

Ik zorg ervoor dat ik met de client-pc een database-verbinding kan opzetten met de server. Vervolgens gebruik ik 'imp' om de dump te importeren. (En 'exp' om te exporteren.)

OF

Ik zorg ervoor dat ik een terminal-venster kan krijgen op de database-server. Dan upload ik mijn dump naar de server, en tik het 'imp'-commando in het terminal-venster in.

Voor PostgreSQL (gebruik ik ook veel) werk ik op exact dezelfde manier. Voor DB2 werkt 't net weer anders, dan ben je haast verplicht om via een terminal-venster te werken.

[ Voor 9% gewijzigd door Varienaja op 28-11-2005 19:52 . Reden: typo ]

[chris]

Is de file groot of te groot? En wat voor formaat is het? Standaard dump met INSERTs enzo? Of is het CSV?

Je kan natuurlijk altijd splitsen op "INSERT", je mag er vanuit gaan dat voor een INSERT operatie geen andere dingen komen. Of je moet toevallig velden in je db hebben staan waar ook 'INSERT' in voorkomt. Je kan natuurlijk ook splitten op "\nINSERT" oid.

[Alain]

Dit maakt het heel moeilijk (lees : bijna onmogelijk) om die deftig te parsen om er zelf iets mee te doen.

Is de -xml optie dan misschien een mogelijkheid?

[ Voor 8% gewijzigd door Alain op 28-11-2005 20:50 ]

[dingstje]

Als je zelf iets wil schrijven zou je kunnen overwegen gebruik te maken van de SQLParser uit phpMyAdmin. Je moet maar een beetje snorren door de comments ivm de functie PMA_SQP_analyze.

[Verwijderd]

chris schreef op maandag 28 november 2005 @ 20:28:
Is de file groot of te groot? En wat voor formaat is het? Standaard dump met INSERTs enzo? Of is het CSV?

Je kan natuurlijk altijd splitsen op "INSERT", je mag er vanuit gaan dat voor een INSERT operatie geen andere dingen komen. Of je moet toevallig velden in je db hebben staan waar ook 'INSERT' in voorkomt. Je kan natuurlijk ook splitten op "\nINSERT" oid.

Dat is net wat ik bedoel... die linebreaks staan soms op heel onlogische plaatsen waardoor het heel lastig is het boeltje te parsen en splitsen...

Bijvoorbeeld :

code:

1068827980328465667669327370326988738384833296999711697108111103117115965913
22. DROP TABLE IF EXISTS `catalogus`;
10678269658469328465667669329699971169710811110311711596324013
23. CREATE TABLE `catalogus` (
10323296100118100959911110010196321189711499104971144051504132787984327885767632100101102971171081163239394413
24. `dvd_code` varchar(32) NOT NULL default '',

Hier had ik heel snel een linecounter gemaakt (vooraan) en dan de .sql file beginnen splitten op carriage return chars (ascii 13 dus), en dan krijg je dit soort onbruikbare lijnen bij de definitie van de table. De getalrij ervoor is een acii overzicht van de letters in die string, dit om een idee van de file layout te krijgen.

De inserts zelf zijn wel allemaal netjes 1 lijn, maar op deze wijze is het wel heel lastig om zelfs iets simpels als een auto-import scriptje te maken want mysql gaat helemaal niet gelukkig zijn met geknipte sql commando's...

Ik vraag me af hoe mysql zelf zijn eigen dump file interpreteert want ik zie er echt geen rode draad meer in...

[Verwijderd]

Bij SQL is ';' normaliter het scheidingsteken tussen de diverse commando's. Kun je niet beter daarop splitsen?

[Verwijderd]

Verwijderd schreef op maandag 28 november 2005 @ 22:12:
Bij SQL is ';' normaliter het scheidingsteken tussen de diverse commando's. Kun je niet beter daarop splitsen?

Lastig als er text fields tussenzitten in de records waarin een ; kan voorkomen...

Ik kan rekening gaan houden met de ( en )'s om zo ;'s te vermijden die in een field zitten...

Op zich zeker niet onmogelijk maar dat lijkt me allemaal geen nette manier van werken.

Of bestaat er gewoon geen zekere, nette manier ?

[Verwijderd]

In die text fields kunnen ook CR's staan, dus daar zul je bij 't parsen toch al rekening mee moeten houden...

[Verwijderd]

Verwijderd schreef op maandag 28 november 2005 @ 22:25:
In die text fields kunnen ook CR's staan, dus daar zul je bij 't parsen toch al rekening mee moeten houden...

Die staan normaal netjes als \n en/of \r in de tekst zelf en zitten daar niet als code 13 of 10 in...

[flashin]

dumps >5MB uploaden naar phpMyAdmin wil niet echt meer..
Ik gebruik tegenwoordig altijd de CLI, er is volgens mij ook geen andere manier die wel snel is.

Staat safemode aan bij je hoster of niet?

[maartenba]

Stom idee, maar kan je niet:
- Upload je exportfile via FTP
- Run een scriptje (via HTTP zelfs, waarom niet) dat die file inleest, en in 1 ruk in de DB zwiert
- Delete exportfile en scriptje voor kwaadwillige gebruikers

[Arto]

als je de rechtn heb zou je de myqsl files kunnen kopieeren

windows : %mysql_map%\data
linux : /var/lib/mysql

met voor elke DB een aparte dir.
de mySQL dir zelf staat een DB met alle rechten in dus die valt ook mee te kopieeren

[pietje63]

Ik werk zelf meestal met csv bestanden, die dan regel voor regel worden uitgelezen, maar volgens mij maakt dit niet heel veel verschil.
Wat je ook kunt proberen is een programma als mysql-front (www.mysqlfront.de) omdat je dan iig geen 'gekloot' met php hebt.

[orf]

Als je met PHP gebruikt kunt maken van exec() kun je wellicht dit gebruiken:

PHP:

<?php

exec('mysql -u gebruikersnaam -pwachtwoord -h localhost < /path/naar/sql_file');

?>

[KabouterSuper]

Ik herken het probleem met phpMyAdmin. Ik heb weleens in php iets geschreven wat op basis van een tabel een lijst met insert statements genereert. Om dit overzichtelijk te houden kon ik filteren op de primary key (in mijn geval een account_id). Zo kon ik gedeelten van tabellen backuppen. Het scriptje genereert ook de nodige delete statements zodat ik de output ook direct kon uitvoeren in een andere omgeving (en daarmee een account kon synchronizeren).

Omdat ik het zelf geschreven heb, had ik ook alle controle, in tegenstelling tot de output van phpMyAdmin. Het gebruik van een filter maakte het geheel daarbij handelbaar (want ik backup veel minder data per keer). Nadeel is natuurlijk dat het niet zo fancy is als phpMyAdmin en ik ongetwijfeld een boel uitzonderingen niet meeneem. Ook de performance zal wat minder zijn (aan de andere kant, je moet toch een full table access doen als je een table volledig dumpt, dus hoeveel kan je daaraan optimaliseren )

[Verwijderd]

Waauuw... had vanmiddag ff geen tijd te volgen hier

Euh SAFE MODE bij mijn hoster... ik volg ff niet... wat bedoel je juist ?

Verder krijg ik de indruk dat er meer mensen hetzelfde probleem hebben.

De optie om zelf met een exec dat in te voeren ga ik straks nog eens testen. Dat had ik al eens getest maar toen werkte dat niet, maaaaaar toen zat mijn hosting ook op een heel andere server bij die hoster. Ondertussen is alles verhuist naar nieuwe servers met andere control panels enzo, dus dat kan ik nog eens testen.

Eigelijk is het blijkbaar niet zo evident om op eenvoudige wijze > 5mb dumps in te voeren na een crash of verhuis of whatever...