23 berichten aan het bekijken - 1 tot 23 (van in totaal 23)
  • Q:
    Bijdrager
    Shmoo

    Importeer een zware SQL database in phpMyAdmin

    Zoals de titel al omschrijft.  Ik ben een WordPress site aan het overzetten van host A naar host B (TransIP). Deze site heb ik niet gemaakt, mijn schatting is dat er ergens tussen 1400 en 1700 items in de database zullen zitten.

     

    Waarom de database zo onhandelbaar groot is weet ik nog steeds niet. Het .SQL exportbestand is 116MB gecomprimeerd in .zip formaat. Als ik ‘m uitpak is ‘ie 2,68GB. Waar dat allemaal in gaat zitten, ik heb geen idee.

     

     

    Ik heb de php.ini instellingen van MAMP op extreem breed gezet zodat ik ongelimiteerd ruimte krijg van de server.

     

    Toch wil er niets geïmporteerd worden.

     

    En het ergste is… Dit is nog in de MAMP omgeving op mijn computer, enkel testen. Ik begrijp heel erg goed dat ze mij bij TransIP never en nooit deze bewegingsruimte gaan geven.

     

     

    Wat kan dit zijn en heeft iemand een idee hoe dit op te lossen. Mijn handen zitten in het beton want ik heb zelf geen toegang tot de huidige database om een eigen export te maken. ☹️

     

    Bijdrager
    Chorro

    Je kan proberen het .sql bestand via SFTP op de server te zetten en vervolgens middels SSH MySQL dit bestand laten importeren. Is over het algemeen sowieso de snelste manier en daarmee omzeil je altijd een PHP timeout.

    Bijdrager
    feek

    Ik ken dat:(

    Heb je wel toegang tot de huidige WordPress site?

     

    Bijdrager
    feek

    @Chorro, @Shmoo is al niet eens in staat om lokaal de database te importeren:(

     

    Bijdrager
    Chorro

    <p class=”cite”>feek op 28 februari 2020 om 11:49</p>
    @Chorro, @Shmoo is al niet eens in staat om lokaal de database te importeren:(

     

    PHPMyAdmin heeft bepaalde nukken die niet altijd te verklaren zijn, heb dat vaak genoeg meegemaakt. Configuratie die net verschilt met de andere server en MyAdmin zeurt al. Uiteraard goed backuppen, maar SSH klaagt een heel stuk minder en levert mij tot nu toe altijd een keurige import op. Lokaal of niet.

    Bijdrager
    feek

    ALs je eens de timeout voor PHP eens groot maakt via php.ini

     
     
    max_execution_time = 180
     
     
    Bijdrager
    feek

    En kijk anders eens naar TablePlus, ik heb daar fijne ervaringen mee.

     

    En @Chorro heeft me ook weer wat geleerd;) . Connect via terminal met jouw MAMP MySQL server

     
     
    /Applications/MAMP/Library/bin/mysql --host=localhost -uroot -proot
     
    Vervolgens in MySQL
     
    use database  jouw_database_naam
     
    SOURCE /path/to/sql/file.sql
     
     

     

     

    Bijdrager
    Jorik

    Kun je op je lokale mysql server iets doen met een client als DBeaver of MySQLWorkbench ipv phpMyAdmin? phpMyAdmin zal in het algemeen wat meer beperkingen hebben, dan een client die met een jdbc of native driver rechtstreeks met de database server communiceert.

    Bijdrager
    Shmoo

    Ik heb nergens toegang tot. Ik heb alleen via WeTransfer een kopie van de bestanden (FTP) gekregen + een .SQL export.

     

     

    Toen ik de bestanden ging doorpluizen om te kijken waar als die GB’s in gingen zitten zag ik dit tussen de bestanden staan.

     

    De oorzaak blijkt een WooCommerce Request Quote plugin te zijn die sinds 5 augustus vorig jaar Errors staat te sturen.  A je to!!! 💪

     

     

    Ik had wel een idee met wat voor kwaliteit ik te maken had maar ik dacht, als ik het eenmaal overgezet heb dan sloop ik die plugin er tussenuit en dan ben ik klaar. Niet te veel doen, alleen overzetten zodat het bedrijf verlost is van de facturen die dit bedrijf stuurt. Dat kunnen ze blijkbaar veel beter dan websites maken.

     

     

    Nu was ik op het idee gekomen om het .SQL bestand te splitten.

    
    
    split -l 5000 ./path/to/mysqldump.sql ./mysqldump/dbpart-
    
    

    Gewoon ruw in stukjes hakken. Dit gaat natuurlijk nooit werken als import maar je kunt wel een beetje controleren waar het fout gaat.

    En dan krijg je dit…

     

     

     

    ☹️🔫  Pang!

     

    Bijdrager
    feek

    En als het eenmaal is gelukt jouw database flink opschonen. Ik verwacht dat er heel veel tijdelijke versies van pagina’s in de database staan.

    Bijdrager
    Jorik

    Tja een sql bestand op willekeurige plaatsen splitten gaat zeker niet werken. SQL is uiteindelijk een query language en geen data format. Dus je zult dan op z’n minst moeten splitten tussen de SQL Statements in. Zolang het SQL bestand niet corrupt geraakt is, zou je het wel moeten kunnen importeren op een systeem met voldoende resources. Ik zou dit echt eens met DBeaver/MySQLWorkbench/TablePlus/SQLPro Studio/mysql in een interactive shell proberen op een lokale MySQL of MariaDB server.

    Succes!

    Bijdrager
    EagerB0bNerd

    Probeer het eens met Sequel Pro.

    Die heeft geen moeite met grote databases (als dat tenminste het probleem is)

     

     

    Bijdrager
    Shmoo

    Sequel Pro is niet meer in ontwikkeling, daar heb ik vorig jaar op school mee gewerkt en toen crashte de app al bij zo’n beetje elke beweging.

     

    Eens wat klooien met TablePlus. Please don’t hate me…. 🙏 🤞

     

     

     

    Als het maar eens een gedeelte erin krijgt.

    Bijdrager
    Shmoo

    De TablePlus app crashte bij ongeveer 1,8GB geïmporteerd te hebben maar nu zit er wel al iets van data in mijn database.

     

    Ik heb dit serieus nog nooit van mijn leven gezien. 😳

    Bijdrager
    feek

    mssn toch ook maar eens proberen via mijn bovenstaande terminal methode? Je had nog maar 0,8 GB te gaan:)

    TablePlus is overigens een fijne App! Zeker ten opzichte van Sequel Pro, dat inderdaad niet meer wordt onderhouden en bovendien oneindig vaak crashte!

    Bijdrager
    Shmoo

    Ik heb ‘m eens aangezet via Terminal.

     

    Zal wel een tijdje nodig hebben, dus fiets ik eerst maar eens naar de winkel.

     

    Bijdrager
    Shmoo

    Hahaha volgens mij zit het erin. Duurde even.

     

    Bijdrager
    Shmoo

    Ik denk dat het gelukt is. Data eindelijk geïmporteerd, thanks voor het wijzen richting Terminal. Ik heb de database opgeschoond, nu ga ik de PHP Errors fixen en dan overzetten. 😓

     

    Het bestandje is wel ineens handelbaar geworden voor elke webserver.

    Bijdrager
    Jorik

    Dat heb je goed opgeschoond! Kun je ons nog even laten weten welke bulk je hebt kunnen verwijderen? Waren het allerlei logs of oude versies van pagina’s/posts? Of nog iets anders?

    Bijdrager
    pruus

    Let er ook op dat de indexen goed overgenomen zijn en auto increment. Want anders krijg je straks weer de nodige trammelant. Met dit rukweer is dit een mooie klus.

    Bijdrager
    feek

    Mooi zo dat het zoals het er nu naar uit ziet gelukt is:)

    En…. ik denk dat @shmoo terminal weer iets meer is gaan waarderen:)

    Bijdrager
    Shmoo

    Het waren vooral sessions.  Nutteloze data dat opgeslagen werd in de database en gecreëerd door crawlers tijdens het indexeren. Het winkelmandje dus niet uitgesloten in robots.txt

     

    screenshot

    Dit was nog niet eens de volledige import. Dit was de eerste import die relatief succesvol verliep via TablePlus en crashte op 1.8GB. Hierdoor kreeg ik wel voor het eerst inzicht waar al het volume in de database zat, en waar ik mee te maken had.

     

    Ik had vooraf geen toegang tot, of inzicht in iets. Ik kreeg alleen een extreem zwaar bestand via WeTransfer waar ik niets mee kon. Het enige dat ik wist was dat er maximaal 1800 producten in deze website konden zitten (zijn er 1100 en een beetje) dus ik was extreem nieuwsgierig waarom deze export zo ongelofelijk zwaar kon zijn. Op school had geleerd over het BLOB data-type dus ik dacht nog, ze hebben toch niet alle productafbeeldingen in de database zelf gestopt!?

     

    Het is eigenlijk allemaal te triest voor woorden want zodra ik wist dat het om sessions ging (nutteloze data), heb ik het bedrijf nog eens gemaild en gevraagd of ze deze sessions wilde verwijderen/opschonen uit de database  voordat  er een export werd gemaakt. Ik bedoel, er is een knop voor gemaakt in WooCommerce > Tools. Je hoeft er alleen maar op te drukken. 👇

     

    Dan krijg je zoiets terug.

     

     

    Het draait ook alleen maar om geld bij bepaalde mensen.  Stel je voor de eigenaar van de site had nu akkoord gegeven dan had dit bedrijf waarschijnlijk een factuur van 150,- gestuurd voor ‘hulp tijdens het verhuizen’ … dat alleen nodig was omdat ik geen toegang kreeg tot iets. En dan had ik ze later ook nog moeten vertellen, druk even op bovenstaande knop, voordat je een export maakt. Dankjewel.

     

    Het maakt mij alleen maar verdrietig want ik heb niets tegen geld verdienen maar als je de broncode ziet en wat ze weer allemaal bij elkaar geknutseld hebben dan ga je huilen.

    Dit soort meldingen staan gewoon continu te genereren – zijn alleen niet zichtbaar omdat Debug modus UIT staat. Zeker 300 foutmeldingen van dit kaliber en dan heb ik nog niet eens met PHP versie 7.4 getest.

     

    Bijdrager
    EagerB0bNerd

    Het waren vooral sessions.  Nutteloze data dat opgeslagen werd in de database en gecreëerd door crawlers tijdens het indexeren. Het winkelmandje dus niet uitgesloten in robots.txt

    WooCommerce sessions worden standaard na 48 uur vanzelf opgeschoond. Daardoor nemen ze -als het goed is- weinig ruimte in in je database.

    Voorbeeld:

    woocommerce sessions

     

    Als dat wel het geval is is er iets anders aan de hand.

    Dat indexeren door crawlers is flauwekul, een session is uniek voor een gebruiker. Alleen op mijn computer kan ik zien wat er (nog) in mijn winkelmandje zit, een crawler heeft geen idee, laat staan dat het opgeslagen wordt in de db van de shop.

     

     

     

     

23 berichten aan het bekijken - 1 tot 23 (van in totaal 23)

Je moet ingelogd zijn om een reactie op dit onderwerp te kunnen geven.