[ bjevta @ 26.09.2012. 10:41 ] @
pustio sam juce popodne da se kopira jedna poveca, MyISAM, baza u InnoDB ekvivalent. Tabela jedva 10-ak ali, jedna ima 10e7 slogova, manja oko 10e6

INSERT INTO pd421jacktest.REPOSITORY_DEFAULT_NAMES SELECT * FROM pd421jackmerriot.REPOSITORY_DEFAULT_NAMES;

sve ok, krenulo da radi, nikad nije zavrsio. jutros nesto mulja, vidim da nece da odradi. kako da kopiram velike tabele (5.5.17), osim slog po slog?
[ bogdan.kecman @ 26.09.2012. 12:49 ] @
insert select je ogromna transakcija, kod myisam-a te bas briga ali sa innodb-om to je jedna veeeelika transakcija i naravno da je problem... tebi masina odavno swapuje po meni tako da se sve extra usporilo i velike su sanse (ako je tabela toliko velika) da ce na kraju mysql samo da prsne, tj da ce kernel da ga ubije zato sto trosi previse resursa

imas 4 resenja
1. napravis skript koji ce da radi 10000 po 10000 rekorda: insert select order by .. limit offset,10000 (ne zaboravi order by, jedino tako ti limit ima smisla!!)
2. uradis select into outfile iz myisam, pa load infile u innodb
3. ugasis mysql, fizicki iskopiras FRM, MYI i MYD fajlove iz baze1 u bazu2 (budi siguran da fajlovi imaju ok permissione kada ih iskopiras), startujes mysql, uradis alter table baza2.tabela engine=innodb
3a. ako ti ne treba original tabela, napravis bekap iste i onda uradis alter table engine=innodb i tu tabelu direkt prebacis u innodb bez ikakvog kopiranja
4. uradis dump bez create iz myisam-a pa izvrsis taj dump nad novom bazom

Ja licno najvise volim prvo resenje (nije najbolje niti najbrze) zato sto sa njim mogu da imam progress report :), stavim po 1k ili 10k slogova i ispisem neki progress bar kako se izvrsavaju upiti i znam dokle sam stigao ... sve ostale varijante pustis i onda cekas a nemas pojma el se nesto uopste desava ili ne





[ bogdan.kecman @ 26.09.2012. 12:56 ] @
btw, zaboravih da napisem, najbrze je select into outfile i onda load infile (ili mysqlimport) toga u innodb, to ce da radi multithreaded, ubedljivo najbrze, jedino sto nemas nikakav progress report
[ bjevta @ 26.09.2012. 14:39 ] @
pustio sam 3a da vrti i odoh kuci.
[ bogdan.kecman @ 27.09.2012. 03:00 ] @
:D
nadam se da si napravio prvo bekap
[ bjevta @ 27.09.2012. 07:55 ] @
nisam napravio backup, imam dump :D

dakle, dosao ja jutros, kad ono i dalje mulja. dakle, NE preporucujem 3a. idemo na varijantu 1, kao sto je trebalo odmah
[ bogdan.kecman @ 27.09.2012. 09:22 ] @
pazi v2 ti je najbrze posto on jedini kreira tabelu sa vise tredova, v1 ima prednost "progress bar" sto ume da znaci mnogo :)
[ Tyler Durden @ 27.09.2012. 10:15 ] @
Ali sa obzirom na količinu podataka, zar se neće zabosti i sa v2, kao što se desilo i sa prethodnim varijantama?
Ja sam jednom prebacivao na innodb tabelu sa 3-4M rekorda (sa alter table, a probao sam i sa dumpom) i to je bilo mučenje od par sati...

Meni se čini da je v1 jedina sigurna i kontrolisana kombinacija.
[ tarla @ 27.09.2012. 14:52 ] @
Meni je i sa 2 mil. redova zabadalo prilikom prebacivanja na InnoDB


Varijanta 1 je po meni ispravna solucija...
[ bogdan.kecman @ 27.09.2012. 19:45 ] @
Citat:
Tyler Durden:
Ali sa obzirom na količinu podataka, zar se neće zabosti i sa v2, kao što se desilo i sa prethodnim varijantama?


nece zato sto load infile radi kompletno drugacije

Citat:
Tyler Durden:
to je bilo mučenje od par sati...


nema nacina da napravis tabelu te velicine a da ne traje satima, posebno ako ti nije konfigurisan rdbms kako valja

inace v1 je medju sporijim metodama, jedino sto imas progress bar pa tacno znas sta se desava i dokle si stigao. Dodatno ces primetiti kako v1 usporava vremenom posebno ako imas dosta indexa posto exponencijalno traje vreme za regenerisanje indexa za svaki taj insert. insert select svega odjednom bi teoretski bio super brz kada bi imao dovoljno rama da celu transakciju obavis tamo..