Aktivnost
Od 11.05.2013 do 09.06.2013
07.06.2013
-
21:38 Podrška #31156: F18 offline instalacija, rubyrep, itd
- rekao sam jasku, ili to ne radi ili mi nešto nismo dobro postavili u conf fajl
-
- jednostavno to nama nije proradilo ni pod razno.
* prvi sync prođe - ok
* kada drugi put pustiš, on opet krene sa filovanjem tabela i tad pukne na primary key kontroli - logično umjesto da preskače te zapise
znači, test je rađen s... -
16:09 Podrška #31156: F18 offline instalacija, rubyrep, itd
- može se instalirati jruby i ruby varijanta. jruby je brža varijanta jer koristi, pretpostavlja multithreading osobine jvm-a odnosno jdbc-a.
-
- kako rekoh u par navrata, ovdje je glavni problem što ste krenuli od kraja - pokušali staviti u produkcijsku bazu odjednom
podesiti jednostano testno okruženje prema komentarima koje sam naveo pa onda možemo pričati o tome šta rubyrep... -
- rubyrep je upravo ono što nama treba:
http://tantrajnana.blogspot.com/2011/10/postgresmysql-database-synchronization.html
jedino ako svi ovi ljudi što su pisali nisu pisali stvari napamet -
- konkretno, gledajući kod, to je ovaj two-way-sync proces:
https://github.com/rubyrep/rubyrep/blob/master/lib/rubyrep/syncers/two_way_syncer.rb
-
- > mislim da ovo što nama treba nije to to
nama ne treba replicate režim, samo0 sync.
sync bi trebao raditi posao koji mi trebamo -
- http://piyush.me/2010/07/05/rubyrep-master-mater-replication-postgresql/
alat, kako si rekao ima replicate i sync režim
sync režim odgovara scenariju offline sinhronizacije koji mi trebamo - veza između dvije baze nije konstantna.
-
- *rubyrep - replication*
ovo je režim gdje se tabele izsinkaju i imamo aktivan ruby proces konstantno, tako da kada dodamo zapis ovamo ili tamo dešava se sinkanje zapisa...
*rubyrep - sync*
ovo bi trebao da bude proces koji sinka... -
- http://www.linuxfoundation.org/collaborate/workgroups/networking/netem#Rate_control
-
- takođe lokalno se može testirati i network bandwdith/latency sa tc-om
http://superuser.com/questions/147156/simulating-a-low-bandwidth-high-latency-network-connection-on-linux
-
- ograničiti se za početak samo na fin_anal, suban, sint, nalog
i na <100-njak zapisa
onda ubaciti prave podatke od od cca 1000 zapisa
i za kraj najveću bazu što imaš > 10000 zapisa
-
- prije svega ovdje se treba dobro postaviti testno okruženje.
recimo postaviti dvije virtualbox sesije, tako da jednostavno možeš simulirati offline, online scenario
prekid mreže
lijeva baza ažurirati
pustity sync
desna strana až... -
- 1) prije svega vidi kakvo je stvarno stanje nakon synca na lijevoj i desnoj strani
2) prva testiranja uradi na manje tabela i manje zapisa
3) nakon toga "širi" se na pravo korištenje, postepeno
-
15:09 Podrška #31156: F18 offline instalacija, rubyrep, itd
- init sync samo fin tabela prođe bez ptoblema, evo loga
-
-
- init sync prođe na praznu bazu ali naknadni puca
-
- Jasmin Beganović je napisao/la:
> fin_anal puca na init_sync-u
> ...
#config.options[:rep_prefix] = 'rr1' sređuje ovaj problem -
- izbaci sve tabele koje prave probleme da bi došao do uspješne sinhronizacije
dovoljno je testirati sinhronizaciju par glavnih tabela (npr. samo fakt_fakt, fakt_doks)
kako se ponaša u offline/online režimu
kada/ako to uspije o... -
- fin_anal puca na init_sync-u
-
-
- to i govorim
-
- log tabela ?
pa nju ne trebaš sinhronizirati
nju treba isključiti iz replikacije dislociranih baza -
- tabele za ignorisanje
u ovoj varijanti nemamo nikakve koristi od tabela semafora, svakako će full sync okinuti zbog redova, tu je još log tabela.
To je ono što ja znam, nadodajte se -
- a o principima konstrukcije relacijske baze da ne govorim
-
- nije noramlno da red tabele nema jedinstvenu identifikaciju
ako ništa iz niza praktičnih razloga. -
- Ernad Husremović je napisao/la:
> i otvoriš ticket za upgrade baze u skladu sa zapažanjima
OK, nego nemam pojma jeli to normalno ili ne u skladu sa F18 načinom rada zato ste vi na notifikaciji.
-
- i otvoriš ticket za upgrade baze u skladu sa zapažanjima
-
- Jasmin Beganović je napisao/la:
> dobro ja zbog testa imam workaround a setovanje svakako treba
bolji test ćeš uraditi ako te tabele isključiš
-
- dobro ja zbog testa imam workaround a setovanje svakako treba
-
- Jasmin Beganović je napisao/la:
> Saša Vranić je napisao/la:
> ...
ovo što radite je pogrešno
tim tabelama se treba setovati pkey a ne raditi ovo -
- Saša Vranić je napisao/la:
> Jasmin Beganović je napisao/la:
> ...
jeste to su sve tabele bez pkey-a
setujem -
- Jasmin Beganović je napisao/la:
> Ovo ispravno ?? ili ova testna baze !OK
moguće je sasvim da mnoge nemaju pkey...
-
- Implementacija u F18
"commit":https://github.com/knowhow/F18_knowhow/commit/e45f114ac0966b8735ef9a0f3c62db0ffdf988c4
* sinhro svih baza (sve sezone ili samo top sezona )
* sinhro jedne baze (sve sezone ili samo top sezona )
-
- http://www.rubyrep.org/manually_specifying_key_columns.html
-
- Ovo ispravno ?? ili ova testna baze !OK
-
-
-
- ima opcija da se definiše PKEY za tabelu ali to je malo bezveze
-
-
- tabele moraju imati PKEY da bi ovo ferceralo, ovo je problem kod sezona u kojima nema ključeva.
s obzirom da su sezone samo za čitanje ovo nebi trebao biti problem jer se nakon inicijalnog restore-a neće više dirati. -
- lijeva strana je naša baza na testnom serveru
desna moja lokalna baza
po defaultu se gleda samo public shema, >>>>> dodao :schema_search_path => 'fmk'
test.conf -
- http://www.rubyrep.org/
-
04.06.2013
-
- nešto sam u međuvremenu radio na ovome, pa treba provjeriti
28.05.2013
-
- napravljen pored postojećih template-a i
f-stdm.odt
tako se na osnovu vrste dokumenta određuje koji će se template koristiti
već se vrši provjera za otpremnice i slično, pa se koristi f-stdk.odt gdje su prikazane samo količne
... -
-
- "commit":https://github.com/knowhow/F18_knowhow/commit/0222dd1500871bd826e8cc0aea62a85ae9d8780e
ažuriranje podataka na pgserver -
-
- sad treba napraviti ispravke ažuriranja brisanja itd... prema semaforima
-
- build stavljen u funkciju
https://github.com/knowhow/F18_knowhow/commit/87f99748fe9e7e53333b5b7b0fabbeb7857af3aa -
- kod "KADEV" prebačen iz fmk bring.out branch-a
https://github.com/knowhow/F18_knowhow/commit/c3d5b72c8e1d007cfcf129b67a545335f910e142 -
- sql tabele i fmk update paket
https://github.com/knowhow/fmk/commit/92d0827fd6ff2560e9f7cd667fcafbd95bc93a7d -
-
21.05.2013
-
- info je na #31044
-
- bjasko je napravio i posebne prvilegije na samoj bazi i userima direktno na serveru, tako da praktično i ako imamo vidljivu bazu na login meniju ne možemo pristupiti...
bjasko stavi detalje -
-
- bitno je kod logiranja ovih stvari postaviti
-
- na sve operacije, kao što su
* ažuriranje
* povrat
* brisanje
* itd...
napravio logiranje sa prefiksom "F18_DOK_OPER"
U pregledu loga postavljen uslov
* prikaži logove za dokument operacije D/N
tako da ako kažemo D u... -
-
- ako nije ništa navedeno, sve baze su prikazane
-
- za sada napravljeno u .f18_config.ini
-
20.05.2013
-
-
- napravljen template fajl *kred_spec.odt*
dostupan u paketu 1.3.3 template-a -
- "commit":https://github.com/knowhow/F18_knowhow/commit/cc7a326f62ade502bb1c36558a1078ce5ed669e9
-
- podaci koji nam trebaju su praktično specifikacija kredita...
a to su po 2 načina sortiranja:
1) po radnicima
2) po kreditorima
| RADNIK | KREDITOR | OSNOVA | UKUPNI BROJ RATA | UKUPNI IZNOS KREDITA | BROJ OTPLACENIH RATA | IZN... -
- recimo treba nam izvještaj po
* kreditoru
* radniku
* datumskom periodu -
-
- kreditni izvještaji su nam jako loši...
potrebno napraviti bolji izvještaj
-
16.05.2013
-
- nisam primjetio ovaj problem, mislim da je ispravljeno
-
- to je ispravljeno
-
- implementirano i za prodavnicu i za magacin