We implement a distributed synchronized Sqlite database by queueing changes. In our case it is designed to permit internet operation to continue during network failures or congestion.
Virgilio Alexandre Fornazin wrote: > The best you can do actually with SQLite is a 'mirror-replicating' mode > engine > that works like Microsoft Windows Active Directory Database, to build a king > of > High Availability / Load Balancing server. > > You have a farm of servers (or workstations, etc) receiving SQL commands by > a > channel (socket, pipe, whatever). They force a 'election' do decide what´s > the > best servers to become master, then they agree on that and transactions (all > > commands that modify the database) are first applied to the master server > then > 'mirrored' to slave servers. In this design, if a 'child' server cannot > complete > the transaction that are completed by master and any other server, there is > a > critical problem in that slave node, and you must consider it offline or > some kind of state that you need to check if by hand or by one tool you > might > develop for this. In this scenario, you can do a 'load balance' in SELECT´s, > distributing querying belong all servers, creating affinities for tables, > buffering most used tables in a memory database, etc. > > I´m currently implementing services for finantial stock exchanging services > that > works in the way I told you, if you are planning something that we can have > in the > way SQLite is (not tied to any kind of restrictive license), we can share > knowledge > and implement a solution like that. (PS: I don't have full time to work on > it, but > I can help in free hours) > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Griggs, Donald > Sent: segunda-feira, 12 de maio de 2008 10:47 > To: General Discussion of SQLite Database > Subject: Re: [sqlite] Distributed transaction best practices > > Hi David, > > > Regarding: "What are the recommended "best practices" around using > SQLite in a distributed scenario?" [two-phase commit, etc.] > > I trust that someone with some actual relevant knowledge will reply to > your query later, but I imagine that many would say the the "recommend > best practice" is *not* to use sqlite, since sqlite was designed to be > an elegant embedded database -- without even one server -- let alone > multiple synchronized ones. > > I take it you have strong reasons for rejecting, say, Postgres, which > now implements two-phase commmit right out of the box? > > http://www.postgresql.org/docs/current/static/sql-prepare-transaction.ht > ml > > You may already know everything in articles such as this one > > http://en.wikipedia.org/wiki/Two_phase_commit#Distributed_two-phase_comm > it_protocol > And its references (I don't claim to), but I'm listing it here just it > case it's helpful to you. > > On the other hand, if you *do* develop a solid "distributed sqlite" > implementation, I'm sure others would be interested. > > Regards, > Donald Griggs > > > > > This email and any attachments have been scanned for known viruses using > multiple scanners. We believe that this email and any attachments are virus > free, however the recipient must take full responsibility for virus > checking. > This email message is intended for the named recipient only. It may be > privileged and/or confidential. If you are not the named recipient of this > email please notify us immediately and do not copy it or use it for any > purpose, nor disclose its contents to any other person. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
