1. ne mozes da razmisljas o tome kako ces da napravis sinhronizaciju sa njima ako ne znas kakav interface oni mogu da ti ponude
2. idealno je ako oni mogu da ti ponude interface preko koga ti definises koji atributi kojih tabela kada se menjaju tebe zanimaju i da im das callback funkciju da pozove kada se ti atributi promene
3. sa koje god strane pogledas, tesko ti ovo ima veze sa mysql-om, ovo ces resavati programski, u kom god programskom jeziku (ili skripting jeziku) budes to radio te bi ti odgovarajuci forum bio mnogo korisniji (daj c++ ili java ili php ili sta god ces da trosis)

Hvala na odgovoru ali ovaj deo mi nije jasan:



interface bi bio? api...? jasno mi je za atribute i za koje tabele ali kakva callbac f-ja, mozda moj odgovor njima da je sve proslo u redu i da je update u mojoj bazi prosao ok? Soryy ali ne kontam, jel moze neki example ovoga, baza, neki code php? :S

A reci mi kako za unique polje za usere, tj. kako da znam kog user-a treba da updejtujem ili da updejtuju?

opet ti kazem, sve zavisi sta oni imaju tamo sa njihove strane ...

mozes na primer da im kazes "za svaki update/insert/delete tabele USERS pozovite http:/www.kukuriku.com/mojaCallBackFunkcija.php i posaljite mi action=insert|update|delete, user_id, user_data-OLD, user_data-NEW, user_stagod-OLD, user_stagod-NEW ... zapakovano u POST request" .. i onda ti implementiras tvoju mojaCallBackFunkcija.php da obradis datu koja ti stigne od njih ... naravno, ako su oni u stanju da ti naprave tako nesto .. ima milion nacina da se to odradi i sve zavisi od toga sta oni mogu da ti ponude, to uopste nije "jednostavna" prica tako da zavisno od toga sta oni imaju kao backend, sta im je rdbms, kako je organizovan sistem ti ces dobiti neki nacin da sa njima komuniciras. Ovo sa callback funkcijom je najjednostavnije, ali sve zavisi sta i kako oni nude .. dalje ako oni imaju veliki protok informacija nad podacima koje ti hoces da pratis sansa da ti hendlas to sa tupavim php-om je izmedju nema sanse i zaboravi tako da bi onda morao da napises neki svoj servis koji bi slusao negde i prihvatao komunikaciju, postoji fora da non stop imas otvoren tcp kanal ka njima i da tu tuce neki stream podataka etc etc ... postoji tu znacajan problem na sve to sta ako ti nisi u stanju da isprocesiras datu na vreme... oni sigurno ne mogu da pauziraju svoju transakciju dok ti ne obradis update, sto znaci da ce oni mozda da ti posalju 200 zahteva od kojih ce 10 recimo da timeoutuje posto ti je server bio zaboden .. oni sigurno ne mogu da te cekaju tako da - sta sad sa tom datom koju si propustio .. etc etc .. kao sto rekoh, nema tu jednostavnog resenja, treba da se napravi protokol izmedju 2 sistema koji implementira potrebne funkcionalnosti, kako se taj protokol implementira, kao sto rekoh
- zavisi od njih, posto su oni ocigledno ti koji diktiraju sve
- nema nikakve veze sa mysql-om

sve i da je sa njihove strane mysql, minimalna je sansa da bi ti oni dopustili da se kacis direkt na njihov mysql, da im menjas konfiguraciju, instaliras kojekakve skripte i udf-e na server, tako da, realno iako bi teoretski izmedju 2 mysql-a nesto moglo da se izvede, u tvom slucaju ti moras da resis problem programski

hvala na savetima, ovo najjednostavnije resenje mi i najvise odgovara... pisanje nekog mog servisa, pa ne znam uz neki example koji radi mozda snasao bi se.. sto se tice mnogo request-ova i toga, ne znam ni to, mada mislim da nece biti nesto mnogo overloadovoanja....
jel moze neki example za ovo?


pa naveo kao primer, ali videcemo vec... sutra bi trebao da stigne odgovor od njih...

hvala puno na odgovorima i savetima, javljam progress u svakom slucaju...

pogledaj sors mysql-a, vidi kako radi replikacija. Slave se okaci na master i vuce podatke o tome sta se desava...

Ako tabela nije mnogo velika, neko moguce resenje na nivou baze je istovremeni dump/restore. Nesto kao:

mysqldump --host=source DB tbl | mysql --hoste=target DB

Ne moze dump/restore jer baze nemaju identicnu semu, tj. njemu trebaju samo odredjena polja.

@peca89bg:

Mozes li predvidjeti koliko ce tih promjena biti, tj. koliko maksimalno mozes ocekivati zahtjeva u sekundi / minuti / satu tokom nekog peak perioda?

Jasno je da ces to morati rijesiti programski. Koliko ti je bitno da su podaci azurirani, tj. mozes li tolerisati recimo sat vremena kasnjenja?

Ukoliko imas pristup bazi na serveru odakle vuces podatke, jedno od rjesenja bi bilo postaviti trigere na sve tabele / polja koja te zanimaju i puniti neku dodatnu tabelu koja govori sta treba da se sinhronizuje. Onda svakih sat vremena preko cron-a (pretpostavljam da je server na nekom unix like sistemu) pozivas neku svoju skriptu koja cita ovu "sinhronizacionu" tabelu i salje podatke drugoj aplikaciji na serveru. Tu aplikaciju realizujes kao SOAP (ili jos bolje REST) servis i napravis neki svoj protokol tako da prvoj aplikaciji koja je poslala update podataka vratis status na osnovu koga se moze odrediti da li je sinhronizacija uspjela ili ne. Tek kad aplikacija na prvobitnom serveru primi ovaj odgovor onda oznacis te podake kao poslane (ili ih obrises iz sinhronizacione tabele). Na ovaj nacin ako neko slanje podataka i propadne, podaci ce ponovo biti poslani u sledecem izvrsavanju.

Naravno ovaj cron mozes smanjiti pa da se izvrsava i svaki minut ukoliko je vrijeme kriticno.

Skoro sam radio nesto slicno ovome sto sam gore opisao. Podatke sam slao kao XML koji je kompresovan, kriptovan, propusten kroz base64_encode i onda poslan na REST servis. Takodje sam nezavisno slao md5 izvornog XML-a da bih mogao potvrditi da je XML dobijen dekriptovanjem i dekompresovanjem validan. Sigurnost nije bila od znacaja pa nisam koristio neke naprednije kriptografske postupke, ali ako ti je i to bitno (jer spominjes update nekih privatnih podataka), mozda bi trebao razmisliti o koristenju SSL-a.

Sve ovo gore vazi pod uslovom da imas gotovo kompletan pristup sistemu (da mozes da cackas po izvornoj bazi). Ako ne onda nam treba vise detalja koje to opcije vlasnik izvorne baze podrzava, da ne nagadjamo dzabe.

Pa ne verujem da je kriticno da podaci budu azurirani kod mene iste sekunde.
Sto se tice broja zahteva, pa en bi trebalo da bude mnogo, mozda 10ak na jedan sat.



Znaci, u njihovoj bazi pravim tabelu sa podacima koji mi trebaju, cron ide na mom serveru i vadim podatke iz njihove baze tj, tabele sa podacima koji mi trebaju? E sad ova druga aplikacija kojoj se salju podaci iz crona je gde? Na mom serveru? Ova aplikacija bi trebalo da vrsi update mojih tabela i ova aplikacija vraca koji su podaci uspesno update i njih brise ili npr. mark as updated na toj "privremenoj" tabeli? Sto se tice realizacije aplikacije, zasto mi preporucujes web servis kao sto je soap ili rest? Zar npr ne bi mogao jednostavan curl ka nekoj mojoj skripti, kao update.php?sta=user&koji=342443534&tel=0644234254?

Sve sam se pogubio, spava mi se :)
Ovo mi je donekle jasno i polako mi se stvara slika kako bi moglo da se odradi, ali ono sto me najvise buni je kako da znam npr. kom se user-u menja telefon? Moram da imam neki unique identifier koji se nalazi i kod njih i kod mene da bi znao tacno kog usera da updejtujem.. Jel tako?



Jel moze example, tutorial za REST servis gde je objasnjeno sve od nule?



Ne znam jos uvek nista o njihovom server, bazi itd.. Trebali smo danas da imamo sastanak ali nismo... :S Cim dobijem neki info javljam.
Hvala puno!

Nisam stručnjak za MySQL, ali preduslov za ikakvu sinhronizaciju je da u tabelama koje sinhronizuješ imaš zaista jedinstven primarni ključ. Moj savet je da se koristi UUID. Drugo je da u svakoj tabeli imaš polje u koje u trigeru beležiš podatak o tome kada je slog poslednji put sinhronizovan. Zatim i posebnu synk_journal tabelu u kojoj za saki slog svake tabele koju sinhronizuješ beležiš akciju: dodat, modifikovan ili obrisan i čiji sadržaj brišeš posle uspešne sinhronizacije. Ima tu još dosta stvari na koje treba paziti, nimalo lako za implementirati, iako početni zahtev ne izgleda tako.

ne mora. Bilo koji unique kljuc je dovoljan, uopste ne mora da bude primarni, za neke tipove sinhronizacije cak ni to nije neophodno.
jedini preduslov za sinhronizaciju je da znas sta hoces da izvedes. Postavljac teme nema pojma sta hoce, "tamo neki >>oni<< imaju tamo neku aplikaciju sa tamo nekakvom bazom i ja bi sa tim da se sinhronizuijem preko php-a" .. dakle niti zna sta tamo ima, ni sta odande moze da dobije a ocigledno nema ideju ni sta da im trazi. Sve u svemu, jedini nacin da se pomogne je ako neko ima staklenu kuglu pa da se pogleda u nju, posto ocigledno drugih informacija nema. Ne postoji ni informacija da li "sinhronizacija" treba da bude dvosmerna.




koji je benefit uuid-a pri sinhronizacije tabele sa luzerima? kako god okrenes user_name (ili kako god da se zove polje) mora da bude unique. Cak i ako je u originalnoj tabeli PK verovatnije neki user_id koji je numeric, ti radis sync preko user_name koji je unique value i koji te zanima .. doduse, opet zavisi od milion stvari - za koji klinac uopste koristis te vrednosti, kakva je integracija u pitanju, mozda ti terba i taj id .. mozda ne .. opet rekoh, kristalna kugla mi ostala u radionici a prstenje ne nosim ..




ima milion nacina da se to izvede, od implementacije toga u samo aplikaciju koja menja datu u bazi, preko udf-a do parsiranja binloga, sa skokovima na proxy i lua skript .. ali "koji nacin" zavisi od toga sta treba izvesti, dakle sta je zahtev. Ja sam 99% siguran da ga "tamo >>neki<<" likovi nece pustiti da im on instalira udf-ove na db server (za koji ne znamo ni sta je, mozda je oracle, mozda je mysql, mozda je neki pos*ani mssql, mozda je cvs fajl i perl skripta koja cita i pise po njemu) niti ce ga pustiti da im dzara po njihovim masinama na bilo koji nacin .. dakle zavisno od toga sta su oni spremni da urade dobice neki xml stream, ili neki api i to je to, kako ce "oni" to da izvedu - kakve to veze sa bilo cim ima

Mi smo za sinhronizaciju vrlo uspjesno koristili (i dalje koristimo za neke sinhronizacije robnog knjigovodstva) SQLyog Job Agent (SJA), i to "command line" varijantu koju smo ubacili u crontab.
Proguglaj malo i pogledaj njihov sajt. (http://www.webyog.com/)