On Jun 29, 2:28 am, Mark Mandel <[email protected]> wrote: > > And in that, when doing reads, it would round robin through the read-only > datasources, and then when doing writes, it would simply go to the default > datasource. > ...
This is much better, but you can't round-robin except at the end of each request. Otherwise reads on different readonly slaves that are in different phases of a large sync can cause inconsistencies in the cache or your code. That is, any sequence of read actions should be guaranteed to execute on the same read datasource as long as it's happening inside the same request. > > For those of you who know more about HA than me, > > a) Would you only ever have 1 read-write master database? I've seen strategies where different kinds of writes happen on different databases with different replication rules. I'm not sure MySQL implements that well though. For instance you might do writing for page view and statistics logging on a separate write datasource since that alone might generate a lot of load, and then replicate it at a slower pace. User submission information that needs to be visible immediately would happen on a separate one. The fact that the two writing databases are out of sync is not an issue since they write different things and no reads happen on them that would ever cause a join across it. The most common implementation I've seen though consist of having a single writing source and a large number of slaves. DELAYED (in MySQL) is generally then used for logging since it provides similar and less complicated load reducing results. > b) What other strategies other than round-robin would you want for choosing > which datasource you would want next in the queue? Last loaded per type would also probably work well depending on load. The database is going to cache the execution plan, and if you can use the cached execution plan you can potentially get performance gains, especially on large sequential loads where you load many of some type in sequence. I'd venture to say round-robin and sticky per type (or even smaller round robins inside a type group) could both find their place but I'd be curious to see the result in load testing given the added complexity. --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
