MySQL - pomalé importování 13GB databáze

[db]

snazim se importovat 13gb velky sql soubor do mysql databaze na debianu.

Kód: [Vybrat]

mysql -u uzivatel -p databaze < dump.sql
urcite se to vykonava, protoze se vytvori db, tabulky a jejich struktura, ale problem je ze to trva hrozne dlouho.

pokud si vyjedu iotop tak po celou dobu vidim, ze mysql na disk zapisuje kolem 5 - 15 mb/s  ale misto na disku vubec neubyva. Po hodine neni zabrane ani GB navic?

poradi nekdo co s tim je? Kolik hodin bych mel cekat? Jak to urychlit?

[Reklama]

[JardaP .]

Kolik disku je zabrano se dozvite asi az po uzavreni souboru a dost mozna i se zpozdenim. Kolikrat treba mazete soubory a df ukazuje porad stejnou hodnotu, dokud to mazani cvici diskem a nekdy i po nejakou dobu potom. Teprve kdyz se veci uklidni, ukaze to zmenu. Tipoval bych, ze se jedna o podobnou situaci. Asi se budete muset obrnit trpelivosti a vydrzet, dokud to nedochroupe. Mezitim muzete dat na modleni, aby to opravdu delalo to, co ma.

[REMET]

Kdyz pominu, ze to hodne zalezi na jakem je to HW, tak to hodne zalezi na tom, zda je to miliarda malych polozek nebo par blobu (ty bloby budou rychlejsi). Dal kolik je to vubec tabulek a kolik je tam indexu a tak dal.


Moje DB ma neco pres 16GB* a importuje se bratru 6 hodin, ale treba replikace na novy cisty server z beziciho trva cca. 3 dny nez se sesynchronizuji. A pro zajimavost, export/dump trva jenom 31 minut.

* a je to 37 databazi, 5588 tabulek, cca 15000 indexu a nejvetsi tabulka ma 6 milionu polozek.

[ehmmm]

Nemam primo zkusenost s mysql, ale obecne soubory, ve kterych je textove SQL, jsou velke prave kvuli tomu textovemu formatu souboru. Dokazu si predstavit, ze po importovani 13 GB bude databaze na disku mit okolo 1 GB, v zavislosti na typu dat a nejake vnitrni kompresi DB.

A ze to trva hodinu? Kdyz spocitam pres palec 13 GB rychlosti 10 MB/s, tak to je cca 20 minut. Asi bych se tim netrapil, treba to k tomu jeste pise kdovico kdovikam...? Mezi tim bych zkusil vygooglit nejaky nativnejsi prenos dat mezi databazemi.

[Ivan Nový]

snazim se importovat 13gb velky sql soubor do mysql databaze na debianu.

mysql -u uzivatel -p databaze < dump.sql

urcite se to vykonava, protoze se vytvori db, tabulky a jejich struktura

ale problem je ze to trva hrozne dlouho.

pokud si vyjedu iotop tak po celou dobu vidim, ze mysql na disk zapisuje kolem 5 - 15 mb/s  ale misto na disku vubec neubyva. Po hodine neni zabrane ani GB navic?

poradi nekdo co s tim je? Kolik hodin bych mel cekat? Jak to urychlit?

Nainstalujte si mysql workbench, tam pak máte možnost sledovat aktivitu serveru pomocí grafických prostředků, vypisuje i příkazy co zrovna zpracovává (ne každý). Pro orientaci, zda server běží to stačí.

https://www.mysql.com/products/workbench/

Načítání příkazem LOAD DATA z csv souboru bude ale rychlejší.

[Reklama]

[Ivan Nový]

Soubor taky můžete rozdělit například příkazem csplit -k import.sql '/INSERT/+5000' {*} na menší soubory a ty importovat pomocí mysql ve skriptu, který vám vypíše název či číslo aktuálního segmentu.

[db]

jelikoz se jedna o InnoDB, postupoval jsem podle:

http://dba.stackexchange.com/questions/83125/mysql-any-way-to-import-a-huge-32-gb-sql-dump-faster

nyni import provadi zapisy na disk konstantne nad 12mb  (predtim to dost kolisalo), tak to asi bude rychlejsi.  Je to pres 35 milionu zaznamu, tak snad to nezabere vic jak 10 hodin, jinak budu muset zkusit radu od Ivan Nový


ta databaze zas tak moc velka neni aby s tim byl takovy porod :-(

[to_je_jedno]

1) IT je pomerne exaktni veda -> dej si v dotazech velky pozor na spravne jednotky. Nejak neverim, ze tam neco jede rychlosti 12mb/s.
2) jak presne byl dump prikaz a proti jake verzi mysql? se starou verzi jsem mel problem, ze to chtelo parametr (a ted ti ho z hlavy nepovim, ale resi jestli kazdy radek ma svuj insert nebo je to v jednom velkem) - a ta zmena dela i nekolik radu v rychlosti importu (ale zase musis mit poreseny bod 5) )
3) jaky tam mas HW? (hlavne mnoztvi RAM)
4) jak mas nastavene file per table?
5) taky by to mozna chtelo dat vetsi max_allowed_packet

obecne MySQL jako takove je by default pripraveno na minimalni HW, MariaDB o neco vice, Percona jeste vic. Vyladit to optimalne podle zateze, velikosti RAM, velikosti a frekvence pouziti te ktere DB/tabulky je na dlouho

[dustin]

V tom sql dumpu bych na začátku vypnul kontrolu unique a referenční integrity, na konci zase zapnul.

SET FOREIGN_KEY_CHECKS = 0; SET UNIQUE_CHECKS = 0;

Taky bych zkusil SET AUTOCOMMIT = 0; jestli to projde v jedné transakci, nebo mezi tabulky nastrkal commity.

Ještě používáme disable/enable keys, ale to prý nemá na innodb vliv http://stackoverflow.com/questions/8210608/mysql-disable-enable-keys .

Z testů nám jako nejrychlejší dump/load vychází txt dump tabulek mysqldump --tab a pak infile na serveru nebo i klientovi. Ale to chce trochu skriptování, protože se vyrábí soubor pro každou tabulku.

[db]

no vazne, takhle to bezi celou dobu.


http://www.imgup.cz/images/2016/08/10/io.png

[db]

jinak jedna se v podstate jen o jednu tabulku s 35+ milionama radku.
mam 6GB RAM.

nejhorsi je, ze kdyz bezi ten import, tak nemuzu provest spocitani radku protoze to bezi nekonecne  dlouho. Kdyz import zrusim tak radky to spocte hned.

Celkem  ted verim, ze se to do tech 10 hodin v pohode importuje, tak uz ted zatim nechci dohledavat jake mam nastavene dalsi veci v db.

[thcom]

 ja pro import pouzivam toto, je to opravdu rychle
https://phpfashion.com/extreme-rychly-load-sql-file

[dustin]

35M řádků v 13GB dumpu není až tak málo na 6GB RAM a předpokládám jeden rotační HDD. Pokud nemáš extended inserty (více řádků v jednom insert příkazu) a vypnuté kontroly viz výše, obávám se, že to chvilku potrvá. Snadno několik hodin. Na nalévání je potřeba myslet při generování dumpu přes mysqldump, je tam řada parametrů, které následné nalití výrazně ovlivní.

Zálohovací txt dump naší 100GB DB má po rozbzipování cca 20GB. Na 8-jádru s 32GB RAM se to na SSD Intel S3500 nalévalo včetně indexů a zapnutí referenční integrity skoro hodinu.

[Ivan Nový]

35M řádků v 13GB dumpu není až tak málo na 6GB RAM a předpokládám jeden rotační HDD. Pokud nemáš extended inserty (více řádků v jednom insert příkazu) a vypnuté kontroly viz výše, obávám se, že to chvilku potrvá. Snadno několik hodin. Na nalévání je potřeba myslet při generování dumpu přes mysqldump, je tam řada parametrů, které následné nalití výrazně ovlivní.

Zálohovací txt dump naší 100GB DB má po rozbzipování cca 20GB. Na 8-jádru s 32GB RAM se to na SSD Intel S3500 nalévalo včetně indexů a zapnutí referenční integrity skoro hodinu.

Ale ono by to ten skript šlo upravit poměrně jednoduchým skriptem, který by vybral část INSERT table(...) VALUES, tím by extended inserty vznikly.

[dustin]

To by určitě šlo, stejně jako na začátek a konec přidat ty sql modifikátory. Je to spíše pro příště...