JB> On 10/2/07, Andrey Khavryuchenko <[EMAIL PROTECTED]> wrote: >> Shouldn't it? In case of MySQL replication (which is quite widely used) >> and transactions someone somehow *has* to decide where the whole >> transaction is going - to a master or to a slave.
JB> In the case of MySQL, use MySQL Cluster, which designates a "SQL Node" JB> to receive the queries and route them through the cluster. I know about MySQL Cluster. The obvious disadvantage is that the whole database should be in main memory. Kiss goodbye to a bunch of cheap servers sitting close to actual users. There are also replication tweaks like multi-master replication, but they are what they are - the tweaks. If they break, you keep both pieces of your db. >> The most obvious candidate for "someone" is the developer and the >> housekeeping stuff could be hidden in decorators. I wrote a bit more on >> this at [1] (no working code yet, sorry). JB> So when you change the number of databases in your cluster, do you JB> also have to update *every* view in your application? Why? The only thing django app should know is that there are two different *kinds* of servers: read-only and whole access. It doesn't matter how many servers you have - you may well have pool of masters and pool of slaves, it doesn't matter. And, completely unrelated to above, some companies made *business* decision to use MySQL Replication widely. So if django doesn't support it, no big projects using django. -- Andrey V Khavryuchenko - http://a.khavr.com/ Django NewGate - http://www.kds.com.ua/djiggit/ Chytach - http://www.chytach.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
