On Wed, Sep 15, 2010 at 2:00 PM, Sergei Golubchik <serg@stripped> wrote:
> Hi, Weldon!
> On Sep 15, Weldon Whipple wrote:
>> 2. FLUSH TABLES WITH READ LOCK FOR DATABASE dbname;
>> (I just added an optional 'FOR DATABASE dbname' to the already
>> existing command--which still works, BTW. Is this a misuse of the word
>> This is the command that locks the tables before someone (some
>> program) dumps/copies the tables that will be moved to another server.
>> It flushes and locks only one database.
> This would be difficult to implement.
> FLUSH TABLES WITH READ LOCK is not implemented in a way that can be
> generalized to support per-database locks :(
I had guessed as much. (The method in my DB_BINLOG_MGR method that
implements that functionality consists of a mutex lock, a comment
about some sort of miracle happening, then a mutex unlock.)
I wonder if there might be a way of inhibiting some user database
(temporarily) from changing ...
Alternately, I suppose we could do a global FLUSH TABLE WITH READ
LOCK/ UNLOCK TABLES.
Or ... (???)
> Besides, I personally wouldn't worry much about the syntax. It's
> something you can easily change anytime - e.g. replace BINLOG with
> BINLOGGING or FOR with something else.
Yeah, every time I write a new prototype I tweak the syntax a bit.
At the moment I'm just trying to settle on an implementation that
would work for our company (and still be of some sort of general use).