Russell Keith-Magee wrote:
class MasterSlaveRouter(object):
def db_for_read(self, model, db=None):
# Point all read operations to a random slave
return random.choice(['slave1','slave2'])
def db_for_write(self, model, db=None):
# Point all write operations to the master
return 'master'
def allow_relation(self, obj1, obj2):
# Allow any relation between two objects in the db pool
db_list = ('master','slave1','slave2')
if obj1 in db_list and obj2 in db_list:
return True
return None
Then, in your settings file, add the following:
DATABASE_ROUTERS = ['path.to.AuthRouter', 'path.to.MasterSlaveRouter']
And you're set.
It's more of a side note.
I understand that this is only an example but examples like this one
might give an impression that Django now solves master-slave replication
out of the box. It's not.
The hard thing about replication is that switching between master and
slaves doesn't depend on models and doesn't depend on SQL operators. It
depends on some vague notion of "operation context": if we are in some
logical multi-step process of changing state then all writes *and* reads
should happen on a master or we won't have a consistent transaction.
That said, this routing looks to me like a convenient and may be even
necessary plumbing. It just doesn't solve the whole problem.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
