BDR handles this exact scenario. It will be an excellent choice for ofbiz. Most multi master solutions are trigger based. BDR can easily handle the 800 tables that ofbiz has and it doesn't need a table to have a primary key, nor does it use triggers. If two or more masters updates the same table, the last update wins. If a remote node is down, the BDR node will save the WAL files until the remote node picks them up.
On Jan 17, 2017 8:16 AM, "Bahaa Alamood" < [email protected]> wrote: > Hi Jaques, > > thanks for the tip, I have seen this post before. I tried it today and it > seems to do the trick for the sequences. I think I do not need the rest of > the setup in the post because I want to use the brd which sync the database. > > I have a questions regarding the sync. So i have a scenario as an example > where one user on one server changes a record and I have another user on > another server changed the same record. would the system be able to handle > this when they sync? will I see both changes as history? > > > On 1/17/2017 4:29 AM, Jacques Le Roux wrote: > >> The now removed POS component used a solution for similar cases. This >> solution still exists and is reliable on a LAN ("less" on Internet) >> >> You can find the documentation at https://cwiki.apache.org/confl >> uence/display/OFBIZ/Sync+Setup+Notes+and+Example >> >> Disclaimer: it's not very easy to understand and use... >> >> HTH >> >> Jacques >> >> >> Le 17/01/2017 à 00:01, Bahaa Alamood a écrit : >> >>> Hello All, >>> >>> We have a situation that we need to have more than 2 servers of ofbiz >>> running, server A, B, and C. The scenario is like this >>> >>> 1. Server A is the main server and it is online all the time with its >>> own database. some people do connect to that and make changes to the data >>> (create, delete, modify) >>> >>> 2. Server B is a server in one office (own database) and they do not >>> have a reliable internet connection so it goes offline some times while the >>> users in this office continue to use their local ofbiz >>> >>> 3. Server C is the same as server B with its own database as well >>> >>> I have been looking at the bdr from 2nd Quadrant >>> https://2ndquadrant.com/en/resources/bdr/ to do the data >>> replicationamong the servers. I realize that this could create conflicts in >>> the primary keys of many things in the system. So I looked at >>> SequenceUtil.java and I can see if I change the stagger in getNextSeqId >>> from 1 to 2 in one of the systems I can avoid this conflict in two of them, >>> but what about the third one? also in the above scenario what else I need >>> to look out for other than the sequences that might create conflicts? >>> >>> >> >
