Evo upravo startovao script, za razliku od onog danas koji bi digao load na 300 30-tak sekundi posle startovanja ovaj radi okay. Mana je sto ne mozes praviti nijedan drugi query dok se ceo fetch ne zavrsi, a to izgleda vazi i za ostale db konekcije iz istog scripta. No u mom slucaju easy to fix, ja cu podatke upisati u fajl i uvesti sa "load data local ..." opcijom u odgovarajucu tabelu.
@ivanhoe
Obzirom na velicinu tabele nisam kreirao nikakve primarne kljuceve vec samo sadrzi domene (90 miliona), tako da to resenje otpada. Nije frka za blokiranje konekcije.
@eraser
Workaroundovi su relativna stvar, mozda nece funkcionisati kod tebe.
Dakle, u prvom slucaju trebao sam da najjednostavnije iskopiram jednu tabelu sa jednog servera na drugi (takodje povecu). Fetch cele tabele i /insert into je brzo ubijao server, kao i u slucaju danas. Resenje je bilo da upisem iz mysql klijenta sve podatke u fajl a onda importujem sa "load data local" u tabelu. Napominjem da nisam koristio mysqldump upravo zbog velicine podataka, ranije je on uzrokovao ogromne probleme jer je trebalo postaviti pravu vrednost za parametar (ne mogu da se setim sada tacnog imena) koji regulise broj recorda po redu (default je prevelik za vece tabele tako da import efikasno ubije server zbog broja query-a u jednoj liniji).
Ukrako workaround 1:
mysql -uuser -ppass baza -e "select data from tabela" > fajl.txt
bzip2 fajl.txt
scp fajl.txt.bz2 drugi.server:/path/to/file
unpack
mysql -udrugiuser -pdrugipss baza
load data local infile 'fajl.txt' into table foo(data);
Workaround 2 se odnosi na danasnju situaciju (nisam ga doduse primenio). Dodao sam jedno enum (checked no/yes) polje tako da se mogu uzimati podaci u chunkovima od po 1000 npr, setovati na checked i tako u krug dok se ne obrade svi.
Mana tog workarounda je sam alter ... trajao je bogami cirka 2 sata (plus jos toliko kada ga budem uklanja)
