If your primary goal is redundancy (not scalability) then you could maybe get away with using the master for all queries while keeping the slave as a "hot spare".
We've been using this master-slave configuration with a django-based app. All queries (read and write) go to the master. When master dies, we promote the slave to master and point django app to it. No changes to django framework were needed. Depending on your performance requirements this model can be further improved by adding transactions and semi-synchronous replication (see http://code.google.com/p/google-mysql-tools/wiki/SemiSyncReplication) If the goal is scalability, one needs to assume a cache-based solution isn't appropriate or isn't enough, right? If so, a solution would have to work for n slaves. Making things work for a single slave won't likely be too limiting in general case. Alexis On 8/22/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Hi! > > I am now at the prospect of using a MySQL database in the form of a > 2-machine master-slave cluster. If I understand things right this > requires Django to actually know which queries should be directed to > which host, i.e. writes on master, reads on both master and slave. > > I'm about to start thinking of what changes are required to Django's > backends, how the choosing itself can be implemented (as view decorators > or middleware). Does anyone has any thoughts on the matter? May be there > are already some working solutions? > > Thanks! > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
