On Thu, Sep 16, 2010 at 11:17 AM, Davi Arnaut <Davi.Arnaut@stripped> wrote:
> On 9/16/10 1:18 PM, Weldon Whipple wrote:
>> On Thu, Sep 16, 2010 at 9:20 AM, Konstantin Osipov<kostja@stripped>
>>> * Sergei Golubchik<serg@stripped> [10/09/16 00:40]:
>>>> FLUSH TABLES WITH READ LOCK is not implemented in a way that can be
>>>> generalized to support per-database locks :(
>>> Actually, in 5.5 we added schema locks and now all DDL
>>> takes a schema lock on the affected schema. A reliable RENAME
>>> DATABASE is now possible.
>> That is precisely the functionality we need!
>> I wonder how long until 5.5 goes mainstream ...
> Will ship by the end of this calendar year (2010). Also, the schema locking
> you are planning is _significantly_ easier to implement in 5.5.
Thanks for that info! I just downloaded 5.5 from launchpad, built it,
and have it running on my CentOS development box.
I'll try to implement the START, SHOW and STOP commands in 5.5, and
see how it works. (On second thought, maybe I'll try to make
binlog-do-db a global variable in lieu of the START and STOP commands,
since I haven't tried it yet in this project. I guess I'll keep SHOW.)
Hmmm... I wonder how a list of binlog-do-db's would work as a global
variable. ... And how would I detect that a db's binlogging is to be
stopped by examining the binlog-do-db global variable? (Would that db
just be missing from the list? I don't feel comfortable using
binlog-ignore-db to turn it off. ... If I wanted to subsequently turn
on per-db binlogging for that database, I'd have to remove it from the
binlog-ignore-db and add it back into binlog-do-db ...)
Maybe I'll stick to START BINLOG FOR DATABASE db and STOP BINLOG FOR
DATABASE db for this first attempt at version 5.5 ...
Any additional advice is welcome!