Conversation
Various Rails rake tasks make assumptions on the adapter absed on whether or not it starts with 'mysql'
db:create passes in nil for the database connection and db:migrate uses the idnexes method
For example, this will allow local development with a readonly user against the same database.
- Actually leaving off slaves in the yml supported - A slave will be dropped if unable to connect - Adapter will fall back on the master connection in that case Possible TODO: Refresh the list and try to reconnect every so often, maybe at exponential intervals.
|
Added use of master connection on the reload method. The probability of the slave not being up to date seems high. |
There was a problem hiding this comment.
This doesn't seem like a good idea. What if you can't connect to /any/ slave? Your master is probably going to be busted then...
I think that if you want to be tolerant against slave availability, the logic needs to be way more sophisticated.
There was a problem hiding this comment.
Maybe. I just don't like the requirement for the site to be up at all to be spread across N servers. Before doing this, it's a single point of failure, but if you require all slaves to be on / reachable, then it's the number of slaves + 1 that bring the whole situation down. So overall, I say to just not worry about that. There are other notifications in place to know that happened, but the app should stay alive.
2 participants
These are some changes I made to