Bekijk Volledige Versie : Grote database importeren (MySQL, 3.1GB groot)
Beste,
Eén van de sites die ik host is een vrij groot forum rond hulpdiensten. Daar deze een vrij oude versie van vBulletin gebruikten zijn deze in het weekend het slachtoffer geworden van een exploit waardoor letterlijk alles is verdwenen. In de backups vind ik helaas ook niks meer terug (exploit moet gebeurd zijn enkele minuten voor de backup gebeurde want alle PHP files zijn weg, maar andere zaken zoals databases, mail, settings, ... zijn OK).
Dan maar aan de webbeheerder gevraagd of hij nog een backup had liggen die kon teruggezet worden. Dit kon hij zeker...een backup van 2010 helaas.
Er is dus besloten om de oude vBulletin waarvan ze een licentie hebben terug te installeren, de database die intact is terug te koppelen hieraan en daarna de boel te upgraden naar de laatste versie van vBulletin. En meteen het oude account deleten en nieuw account aanmaken voor alles, zodat ze geheel vanaf 0 kunnen beginnen.
Zo gezegd, zo gedaan... Oud account weggegooid, nieuw accountje aangemaakt in DA, via FTP is alles van de oude vBulletin teruggezet op een verborgen submap (zo staat die voorlopig veilig). Alleen...Hoe kan je nu makkelijk een MySQL backup terugzetten? Voor ik het account heb weggegooid heb ik de sql-file gedownload (via phpmyadmin) zodat ik deze alvast dubbel had liggen. Even uploaden via phpmyadmin blijkt niet te gaan (sql file is 3.1GB groot...), net als het openen met kladblok/notepad++ dat 3.1GB ook net eventjes te groot vind...
Ik vermoed dat je dit via bvb ftp kan uploaden naar de server en dan via mysql zelf dit importeren, of heb ik het fout?
Dank voor uw antwoord, tip of hulp!
Je kan de database dump uploaden en vervolgens importeren met BigDump (http://www.ozerov.de/bigdump/)
Tim.Bracquez
26/12/12, 14:44
Of via de command line importeren?
mysql -u USER -pPASS DB < file.sql
@pierce, @tim,
Bedankt voor beide antwoorden. Wou het eerst via de command line doen zoals tim omschreef, maar ga eerst eens die bigdump proberen (reeds mee bezig).
Bedankt!!!
Vlak voor een backup gebeurd? Backup is toch juist bedoeld voor dit soort issues (total data loss). Met andere woorden jullie behouden maximaal 1 backup?
Maar idd via CLI is beste optie. En anders voor mac Sequel Pro gebruiken (gratis client voor mac) of windows Heidi SQL proberen.
golden,
Ik heb thuis enkele servers staan, waarvan een paar onder verdeeld zijn in een paar vps'jes. 90% van de hosting is voor mezelf, de overigen 10% is voor wat vrienden, familie etc. Ik heb hier dus zeker geen winst aan, laat staan dat je mij een bedrijf kan noemen. Dus ja, ik maak/behoud één backup per 24u.
AAls u mij kan helpen om dit te optimaliseren, dan hoor ik het graag! Backupserver is aanwezig in datacenter overigens.
Zowel via bigdump als via CLI problemen...
Bigdump
Stopped at the line 479.
At this place the current query includes more than 300 dump lines. That can happen if your dump file was created by some tool which doesn't place a semicolon followed by a linebreak at the end of each query, or if your dump contains extended inserts or very long procedure definitions. Please read the BigDump usage notes for more infos. Ask for our support services in order to handle dump files containing extended inserts.
CLI
[root@v01 bigdump]# mysql -u blaat_xxx -pPass blaat_xxx < blaat.xxx.sql
ERROR 1064 (42000) at line 138242: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '<br />
<b>Fatal error</b>: Maximum execution time of 300 seconds exceeded in <b' at line 2
Bigdump Usage Notes:
Note 1: BigDump will fail processing large tables containing extended inserts. An extended insert contains all table entries within one SQL query. BigDump isn’t able to split such SQL queries. In most cases BigDump will stop if some query includes to many lines. But if PHP complains that allowed memory size exhausted or MySQL server has gone away your dump probably also contains extended inserts. Please turn off extended inserts when exporting database from phpMyAdmin. If you only have a dump file with extended inserts please ask for our support service in order to convert it into a file usable by BigDump.
Zal dus eens naar die support service moeten mailen :)
systemdeveloper
26/12/12, 15:42
Je kunt een scriptje maken om het sql bestand te splitten op de tabellen. Dan krijg je wel méér bestanden, maar het zijn wel kleinere.
Een extended insert kun je overigens ook opknippen in kleinere extended inserts door de eerste INSERT INTO regel bij een tabel te kopieeren en om de paar 100 regels in de export te inserten.
Edit: Even een stukje php geklopt waarmee je de grote tabel uit je export kunt trekken. Niet getest, maar zal er niet veel naast zitten:
<?php
$a = fopen("export.sql", 'r');
$tblname = "detabel";
$b = fopen("$tblname", 'w');
if ($a && $b) {
$l = fgets($a, 40960);
$break_from = "-- Table structure for table `$tblname`";
while (substr($l, 0, strlen($break_from)) != "$break_from") {
$l = fgets($a, 40960);
}
$l = fgets($a, 40960);
$break_until = "-- Table structure";
while (substr($l, 0, strlen($break_until)) != "$break_until") {
fputs($b, $l);
$l = fgets($a, 40960);
}
}
fclose($b);
fclose($a);
?>
Optie om die sql file te delen via een ftp van ons of download uri? Als je remote toegang geeft op mysql server wil ik het wel even proberen voor je. PM maar als je interesse hebt ;).
Of probeer Sequel Pro als je een mac hebt ;). Deze insert het in delen.
golden : helaas geen mac :) De file op zich staat online en kan ik per PM sturen naar je (evenals remote toegang geven).
Mocht je nog steeds interesse hebben om eens te kijken naar deze problemen, laat gerust iets weten, inclusief je uurtarief! :)
E-mail mag op kris (a) derocker (.) name
Stuur maar pm met gegevens. Probeer ik het even ;). Geen kosten voor nu even :). Kunnen mede Whters best even helpen met het kerstgevoel ;).
Tim.Bracquez
26/12/12, 16:39
@IT-worX:
[root@v01 bigdump]# mysql -u blaat_xxx -pPass blaat_xxx < blaat.xxx.sql
ERROR 1064 (42000) at line 138242: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '<br />
<b>Fatal error</b>: Maximum execution time of 300 seconds exceeded in <b' at line 2
Lijkt me dat je sql file zelf al corrupt is, je hebt deze vermoedelijk vanuit PHPMYADMIN in een export gegooid? Want een "<br />' in de command line is niet normaal... Lijkt mij eerder een php error tijdens export.
@IT-worX:
Lijkt me dat je sql file zelf al corrupt is, je hebt deze vermoedelijk vanuit PHPMYADMIN in een export gegooid? Want een "<br />' in de command line is niet normaal... Lijkt mij eerder een php error tijdens export.
Ik heb dat zelf wel eens wanneer je database backup niet exact overeenkomt met sql versie. Maar kan ook corrupt zijn inderdaad. Maar hij is bezig met importeren dus ben benieuwd.
Als dit op regel 2 staat:
<br /><b>Fatal error</b>: Maximum execution time of 300 seconds exceeded in <b
Dan maak ik me zorgen over de rest van de inhoud en zou ik geen import starten tot ik op de cli (met less of head) gekeken heb hoe de dump eruit ziet.
Ondertussen is gebleken dat ook de database niks meer waard is...helaas...
Erg vervelend, valt er nog iets op een andere manier te redden denk je?
Volgens ik heb mogen vernemen van Golden amper iets. Hij ging morgen een collega eens wat laten proberen, dus hout vasthouden dat dit lukt!
CeeReM.com
27/12/12, 08:28
Lastig, je kan ook echt het beste een dump maken via de commandline
PimEffting
27/12/12, 09:14
phpmyadmin is na 300 seconden gestopt met het dumpen van je database. Die was dus waarschijnlijk groter dan de genoemde 3 GB.
Beete achteraf natuurlijk, maar dit formaat databases altijd via de commandline dumpen.
En wellicht nog belangrijker: controleren van de back-ups. Geen leuk werk, maar wel noodzakelijk.
systemdeveloper
27/12/12, 09:51
Heel vervelend natuurlijk maar hier komen 2 dingen uit die je leven in het vervolg makkelijker maken:
- betere manier om backups te maken
- historie van backups
Always look on the bright site of IT :)
Volgens mij is er een publicatie hierover op security.nl verschenen -> https://www.security.nl/artikel/44513/1/Hacker_vernietigt_Vlaams_Hulpdienstenforum.html