Podrška #31156
Zatvoren
F18 offline instalacija, rubyrep, itd
0%
Izmjenjeno od Ernad Husremović prije skoro 13 godina
- Projekat promijenjeno iz 103 u F18
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
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
RR::Initializer::run do |config|
config.left = {
:adapter => 'postgresql',
:database => 'bringout_2010',
:username => 'bjasko',
:password => 'bjasko',
:host => '192.168.45.170',
:schema_search_path => 'fmk'
}
config.right = {
:adapter => 'postgresql',
:database => 'bringout_2010',
:username => 'bjasko',
:password => 'bjasko',
:host => '192.168.46.119',
:schema_search_path => 'fmk'
}
# potrebno zbog pucanja konekcije ako je IDLE duže od 60
config.options[:database_connection_timeout] = 600
# daj mi sve tabele
config.include_tables /./
#SYNC -lijeva strana pobjeđuje
config.options[:right_record_handling] = :ignore
config.options[:sync_conflict_handling] = :left_wins
#Replication - -lijeva strana pobjeđuje
config.options[:right_change_handling] = :ignore
config.options[:replication_conflict_handling] = :left_wins
end
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
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.
fakt_fakt Exception caught: Table 'fakt_fakt' doesn't have a primary key. Cannot scan.
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
banke Exception caught: Table 'banke' doesn't have a primary key. Cannot scan
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
ima opcija da se definiše PKEY za tabelu ali to je malo bezveze
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
SELECT table_catalog, table_schema, table_name
FROM information_schema.tables
WHERE (table_catalog, table_schema, table_name) NOT IN
(SELECT table_catalog, table_schema, table_name
FROM information_schema.table_constraints
WHERE constraint_type = 'PRIMARY KEY')
AND table_schema NOT IN ('information_schema', 'pg_catalog')
AND table_schema = 'fmk';
.... more tabela
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
"bringout_2012";"fmk";"banke" "bringout_2012";"fmk";"adres" "bringout_2012";"fmk";"dest" "bringout_2012";"fmk";"dopr" "bringout_2012";"fmk";"epdv_kif" "bringout_2012";"fmk";"epdv_pdv" "bringout_2012";"fmk";"epdv_sg_kif" "bringout_2012";"fmk";"epdv_sg_kuf" "bringout_2012";"fmk";"f18_rules" "bringout_2012";"fmk";"fakt_doks2" "bringout_2012";"fmk";"fakt_rugov" "bringout_2012";"fmk";"fakt_upl" "bringout_2012";"fmk";"fin_buiz" "bringout_2012";"fmk";"fin_fond" "bringout_2012";"fmk";"fin_funk" "bringout_2012";"fmk";"fin_parek" "bringout_2012";"fmk";"fin_ulimit" "bringout_2012";"fmk";"kalk_doks2" "bringout_2012";"fmk";"kalvir" "bringout_2012";"fmk";"kbenef" "bringout_2012";"fmk";"koncij" "bringout_2012";"fmk";"ld_norsiht" "bringout_2012";"fmk";"ld_obracuni" "bringout_2012";"fmk";"ld_parobr" "bringout_2012";"fmk";"ld_pk_data" "bringout_2012";"fmk";"ld_pk_radn" "bringout_2012";"fmk";"ld_radkr" "bringout_2012";"fmk";"ld_radsat" "bringout_2012";"fmk";"ld_radsiht" "bringout_2012";"fmk";"ld_tprsiht" "bringout_2012";"fmk";"ldvirm" "bringout_2012";"fmk";"fakt_gen_ug_p" "bringout_2012";"fmk";"fakt_gen_ug" "bringout_2012";"fmk";"ops" "bringout_2012";"fmk";"os_k1" "bringout_2012";"fmk";"objekti" "bringout_2012";"fmk";"os_amort" "bringout_2012";"fmk";"os_os" "bringout_2012";"fmk";"os_reval" "bringout_2012";"fmk";"os_promj" "bringout_2012";"fmk";"mat_karkon" "bringout_2012";"fmk";"ks" "bringout_2012";"fmk";"pkonto" "bringout_2012";"fmk";"pos_strad" "bringout_2012";"fmk";"por" "bringout_2012";"fmk";"pos_dokspf" "bringout_2012";"fmk";"pos_kase" "bringout_2012";"fmk";"pos_odj" "bringout_2012";"fmk";"pos_promvp" "bringout_2012";"fmk";"refer" "bringout_2012";"fmk";"relation" "bringout_2012";"fmk";"tdok" "bringout_2012";"fmk";"sii_sii" "bringout_2012";"fmk";"sii_promj" "bringout_2012";"fmk";"strspr" "bringout_2012";"fmk";"tnal" "bringout_2012";"fmk";"trfp" "bringout_2012";"fmk";"trfp2" "bringout_2012";"fmk";"trfp3" "bringout_2012";"fmk";"vrprim" "bringout_2012";"fmk";"vprih" "bringout_2012";"fmk";"v_fin_anal_list_all" "bringout_2012";"fmk";"v_fin_nalog_list_all" "bringout_2012";"fmk";"v_fin_sint_list_all" "bringout_2012";"fmk";"v_fin_suban_list_all" "bringout_2012";"fmk";"vrstep" "bringout_2012";"fmk";"fakt_ftxt" "bringout_2012";"fmk";"lokal" "bringout_2012";"fmk";"epdv_kuf" "bringout_2012";"fmk";"jprih" "bringout_2012";"fmk";"sast" "bringout_2012";"fmk";"pos_osob" "bringout_2012";"fmk";"pos_pos" "bringout_2012";"fmk";"sifk" "bringout_2012";"fmk";"sifv"
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
Ovo ispravno ?? ili ova testna baze !OK
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
Izmjenjeno od Saša Vranić prije skoro 13 godina
Implementacija u F18
- sinhro svih baza (sve sezone ili samo top sezona )
- sinhro jedne baze (sve sezone ili samo top sezona )
Izmjenjeno od Saša Vranić prije skoro 13 godina
Jasmin Beganović je napisao/la:
Ovo ispravno ?? ili ova testna baze !OK
moguće je sasvim da mnoge nemaju pkey...
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
Saša Vranić je napisao/la:
Jasmin Beganović je napisao/la:
Ovo ispravno ?? ili ova testna baze !OK
moguće je sasvim da mnoge nemaju pkey...
jeste to su sve tabele bez pkey-a
setujem
# tabele bez PKEY config.options[:auto_key_limit] = 100
ovo će sigurno usporiti provjeru ali šta je tu je
Izmjenjeno od Ernad Husremović prije skoro 13 godina
Jasmin Beganović je napisao/la:
Saša Vranić je napisao/la:
Jasmin Beganović je napisao/la:
Ovo ispravno ?? ili ova testna baze !OK
moguće je sasvim da mnoge nemaju pkey...
jeste to su sve tabele bez pkey-a
setujem
[...]
ovo će sigurno usporiti provjeru ali šta je tu je
ovo što radite je pogrešno
tim tabelama se treba setovati pkey a ne raditi ovo
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
dobro ja zbog testa imam workaround a setovanje svakako treba
Izmjenjeno od Ernad Husremović prije skoro 13 godina
Jasmin Beganović je napisao/la:
dobro ja zbog testa imam workaround a setovanje svakako treba
bolji test ćeš uraditi ako te tabele isključiš
Izmjenjeno od Ernad Husremović prije skoro 13 godina
i otvoriš ticket za upgrade baze u skladu sa zapažanjima
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
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.
Izmjenjeno od Ernad Husremović prije skoro 13 godina
nije noramlno da red tabele nema jedinstvenu identifikaciju
ako ništa iz niza praktičnih razloga.
Izmjenjeno od Ernad Husremović prije skoro 13 godina
a o principima konstrukcije relacijske baze da ne govorim
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
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
Izmjenjeno od Ernad Husremović prije skoro 13 godina
log tabela ?
pa nju ne trebaš sinhronizirati
nju treba isključiti iz replikacije dislociranih baza
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
config.exclude_tables /^semaphores/ config.exclude_tables /log/
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
fin_anal puca na init_sync-u
fin_anal Exception caught: ActiveRecord::JDBCError: ERROR: relation "rr_running_flags" does not exist
Position: 13: insert into rr_running_flags values(1)
Izmjenjeno od Ernad Husremović prije skoro 13 godina
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 onda dodavati postupno nove tabele
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
Jasmin Beganović je napisao/la:
fin_anal puca na init_sync-u
[...]
#config.options[:rep_prefix] = 'rr1' sređuje ovaj problem
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
init sync prođe na praznu bazu ali naknadni puca
fin_anal Exception caught: ActiveRecord::JDBCError: ERROR: duplicate key value violates unique constraint "fin_anal_pkey"
Detail: Key (idfirma, idvn, brnal, rbr)=(10, 00, 00000004, 2) already exists.: insert into "fin_anal"("idfirma", "idkonto", "idvn", "brnal", "rbr", "datnal", "dugbhd", "potbhd", "dugdem", "potdem") values('10', '0147 ', '00', '00000004', ' 2', '2013-01-01', 2898.0, 0.0, 0.0, 0.0)
iako su obje baze identične on vidi neke razlike
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
bjasko@bjasko-Vostro-1015:~/Desktop/rubyrep-1.2.0$ time ./rubyrep scan -s -c /home/bjasko/.f18/f18_sync.conf
fin_anal 100% ......................... 466 <<<< ,kaže 466 razlika nako init synca ????
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
init sync samo fin tabela prođe bez ptoblema, evo loga
bjasko@bjasko-Vostro-1015:~/Desktop/rubyrep-1.2.0$ time ./rubyrep sync -c /home/bjasko/.f18/f18_sync.conf
fin_koliz 100% ......................... 0
fin_anal 100% ......................... 1376
fin_koniz 100% ......................... 0
fin_funk 100% ......................... 0
fin_parek 100% ......................... 0
fin_buiz 100% ......................... 0
fin_sint 100% ......................... 1012
fin_fond 100% ......................... 0
fin_nalog 100% ......................... 242
fin_budzet 100% ......................... 0
fin_izvje 100% ......................... 0
fin_zagli 100% ......................... 0
fin_ulimit 100% ......................... 0
fin_suban 100% ......................... 3586
real 1m23.942s
user 1m35.494s
sys 0m2.820s
Izmjenjeno od Ernad Husremović prije skoro 13 godina
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
Izmjenjeno od Ernad Husremović prije skoro 13 godina
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žrirati
pustiti sync
i sl.
Izmjenjeno od Ernad Husremović prije skoro 13 godina
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
Izmjenjeno od Ernad Husremović prije skoro 13 godina
takođe lokalno se može testirati i network bandwdith/latency sa tc-om
Izmjenjeno od Saša Vranić prije skoro 13 godina
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 baze...
međutim i ne mora, koliko vidim projekat je zamišljen prvenstveno za aktivnu replikaciju baze, što znači da je scenario
- master baza - ima zapisa
- slave baza (backup) -nema zapisa
pustimo replikaciju, dešava se:
- init sync (napune se tabele iz master tabele), kako smo i mi dobili također
- proces repicate je živ i praktično ako radim na master tabeli sve će se promjene automatski syncati u slave bazu itd...
mislim da ovo što nama treba nije to to
Izmjenjeno od Ernad Husremović prije skoro 13 godina
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.
Izmjenjeno od Ernad Husremović prije skoro 13 godina
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
Izmjenjeno od Ernad Husremović prije skoro 13 godina
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
Izmjenjeno od Ernad Husremović prije skoro 13 godina
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
Izmjenjeno od Ernad Husremović prije skoro 13 godina
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 jeste a šta nije, šta može itd.
Bez toga, moje i sašine konstatacije "jeste/nije za nas" su obično nagađanje.
Izmjenjeno od Ernad Husremović prije skoro 13 godina
može se instalirati jruby i ruby varijanta. jruby je brža varijanta jer koristi, pretpostavlja multithreading osobine jvm-a odnosno jdbc-a.
Izmjenjeno od Saša Vranić prije skoro 13 godina
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 sa fin_anal tabelom - jednom jedinom
Izmjenjeno od Saša Vranić prije skoro 13 godina
rekao sam jasku, ili to ne radi ili mi nešto nismo dobro postavili u conf fajl
Izmjenjeno od Jasmin Beganović prije skoro 13 godina
- Status promijenjeno iz Dodijeljeno u Odbačeno