Doesn't seem like anyone has any thoughts here.   Its certainly not something 
I've tried, but the general area of study here is "multi-master replication":  
http://en.wikipedia.org/wiki/Multi-master_replication .   The various ways of 
dealing with whos "dirty" and whatnot fall under that realm of study.   For 
this kind of thing I'd try to use existing techniques and tools as much as 
possible since its not a trivial affair.





On Dec 15, 2010, at 7:31 AM, Marcin Krol wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello everyone,
> 
> I'm in process of writing a distributed application and I'd like to use
> SQLAlchemy as backend.
> 
> However, it's not performance that is my concern, but reliability.
> 
> Suppose I have n server nodes.
> 
> Writing:
> 
> I would like to be able to write on any node from 1 to n, and have write
> results being sent to DB on every node.
> 
> Reading:
> 
> I would like to randomly select one of the n clean (up-to-date) nodes
> and use it for reading objects (normal SA session handling).
> 
> 
> Rationale: the write stream in my case is not going to be very large
> (storing test results), while read stream is going to be heavy, so I can
> afford this sort of architecture.
> 
> On the face of it, implementing such scenario manually should be simple:
> just wrap around SA session and have the object sent to each backend in
> turn (yes, I know, it's a performance hit but that's not a big problem
> in this project).
> 
> However, suppose one of the nodes gets offline at some moment: it would
> have to be marked as 'dirty' and synchronized somehow with other nodes
> when returned to 'online' status. This gets complex and risky.
> 
> Alternatively, I could go with the "low tech" version: always assign
> particular client to a particular server node, and back the DB up /
> replicate it elsewhere. But this cuts into availability and makes me
> maintain n backups / replicas.
> 
> 
> - --
> 
> Regards,
> mk
> 
> - --
> Premature optimization is the root of all fun.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEcBAEBAgAGBQJNCLU/AAoJEFMgHzhQQ7hO/VYH+wXF08U/+dSJ0op9/h9KgnO3
> fclL3eTuRu1ppZtISoEf3VFoJoE6bzlOU2FYd/YviGHHgU3MoK+QsgL6rPiA1lGp
> wITsKExnl4jZPvGBe4pT+QQivzVMdENNTuIClGjLJq+DiqXYL7gkdzU2qukdHQB7
> JhyVyvKicU0h+E6jvlv8CpVg2WpLNyGXrmpSTap0Fs3FnUcs18P7hZCsZWNxt+mw
> nMFD9Zp/BTGiB0eOJDC6reL+ZtjDc23/oKskTp3tFI4m3KOri+k1XyO8i1DEPbiH
> fVvUPy2610+Im8/y3a1gnyxktECIhpDRsErE5lm4pXfe01dDchSkQc5eDIyECdY=
> =whqS
> -----END PGP SIGNATURE-----
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sqlalchemy" group.
> To post to this group, send email to sqlalch...@googlegroups.com.
> To unsubscribe from this group, send email to 
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/sqlalchemy?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Reply via email to