When a DB in the dbs table switches from isalive no to yes, it
pretty much gets slammed by the whole website, as every process
notices in short order that it's available again.
MySQL typically will be slow to respond at first, but then as the
incoming queries load indexes into RAM and fall into the query
cache, it gets up to full speed.
This morning I got reader28 back up and running, and let the db-
angel turn its isalive back on. Once it did, the DB went from
inactivity to suddenly being wedged on a number of different
queries. It took about 20-30 seconds for that initial crush of
queries to complete (some finished earlier than others). But once
that first boggage was cleared, the DB had everything cached and
was running fine.
I wonder if we couldn't implement a layer of weighting over the
existing weight parameter, such that for the first minute a DB
comes back alive, it is fed a gradually increasing amount of traffic,
instead of slamming it with its fair share all at once.
The code could keep track of when a DB came back alive. When
the check for aliveness is re-done, all DBs that were not-alive less
than 60 seconds ago could have their weights adjusted. So if it
came alive t seconds ago and its weight in the dbs table is w, then:
w = w*(t/60) if t < 60
Of course, on the flip side, when a DB goes down, it should go
down instantly, that behavior shouldn't change.
Log in to post a comment.