Hi again I have been thinking further on this subject.
It appears it would be essential to organise inter-master replication via the Bucardo masters so that an event originally may occur on base-server-0 then it would communicate with bucardo-server-0 which would communicate with every other bucardo sevrer, which would then cause their own base-servers to be updated, and some time after this, enter into an ordering process (between the range of bucardo-servers) of a Block of transactions for committal. In this way bucardo servers only update "their own" base-servers unless the bucardo server is updating other bucardo servers on behalf of the base servers. John Olsen IT/OT Chain & Cloud Australia On Sun, Jul 3, 2022 at 2:31 AM John Olsen <[email protected]> wrote: > Hi everyone, > > I initially sent emails elsewhere until I found this list. I am copying > them here. The comments are in relation to an IBM Article from IBM India in > 2019 to be found at > > https://arxiv.org/pdf/1903.01919.pdf > > > " > Yes, Ben, I am searching for multi-master replication solutions, but with > a difference .. the idea is to allow automated Trust to be developed on a > database system by doing away with your standard single superuser system on > bucardo and replacing it with multiple bucardo masters on top of multiple > substrate masters.. > My idea is to copy IBM's research and to build-in a consensus-seeking > solution for the proposed multi-master bucardo system. The consensus being > sought is intended to order transactions appropriately before final > committing..Please refer to the previously attached IBM research paper" > > " > Sorry to carry on before receiving any response, but I have been thinking > about how to implement these Automated Trust ideas. > > If there were as many bucardo servers as there were base-level database > servers, and each bucardo server were configured to only replicate from > changes on its own (base) database server, then the problem would reduce to > obtaining consensus (per transaction "block") from all bucardo servers as > to the order in which the executed transactions are to be committed. The > Consensus Algorithm outlined in the IBM paper, is given in sufficient > detail to reproduce on bucardo (I claim!) > > I am now thinking I should look at your github site. > > From our point of view as Enterprise Application developers and operators > we are looking toward customers such as those companies involved in Supply > Chain operations which require smart contracts you can implement on > postgres databases, if bulk data is involved. Also we intend to provide > distributed applications in non-internetworked areas eg Real Estate > Agencies, NGO Housing Providers, Conveyancing etc. We organise our > customers by "Member Class" meaning they would share IT "Mission" and a lot > of activities daily (as far as what was actually done during the day) and > fit into the same business network (if internetworked at all). One member > Class per database server. Operated by a consortium-employed operator - a > consortium of Members (Companies) in the Class. Our only involvement as a > player, is to have the numbers of users etc etc reported monthly for > Billing purposes. The idea that nobody has to trust anyone else during > daily operations is attractive. Member Class Operators are being kept > honest by the nature of the system, as are we. That is why I am hoping we > can somehow organise an adaptation to bucardo for these purposes. > > It is worth noting that we are looking towards the Elastos Blockchain with > its "Carrier" security system for web communication as the provider of > "Distributed" Id's to allow signing of every transaction securely The only > thing in the IBM agenda of shortcomings of databases (from the point of > view of a Blockchain) is how can we make a PLpgSQL function as > "deterministic" as a transaction on a blockchain? We could also possibly > utilise the insurance of Elastos to check the database for integrity (as, > if more than 50% of bucardo servers were somehow caused to act fraudulently > in concert, Trust would be destroyed). > " > We think this is a very attractive idea of IBM's and feel that bucardo > could play a role in its development. bucardo would act both as replicating > agent as well as ordering agent. > > John Olsen > IT/OT Chain & Cloud Australia >
_______________________________________________ Bucardo-general mailing list [email protected] https://bucardo.org/mailman/listinfo/bucardo-general
