List:Internals« Previous MessageNext Message »
From:Davi Arnaut Date:September 17 2010 12:15am
Subject:Re: Seeking command syntax feedback (Still Re: Per-db binlogging)
View as plain text  
On 9/16/10 6:28 PM, Weldon Whipple wrote:
> 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>   
> wrote:
>>>>
>>>> * Sergei Golubchik<serg@stripped>    [10/09/16 00:40]:
>
> <snip/>
>
>>>>> 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.
>
> <snip/>
>
> 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 ...)

If there are going to be dozens of different dbs to binlog, I would 
suggest using a table. Otherwise just keep a global string variable 
which is guarded by a mutex. See sys_vars.cc for examples of variables 
(grep for Sys_var_charptr) or use the plugin API.

The system variable class also has hooks for reading and updating the 
variable, which means you can parse the string and store it in a more 
convenient format.. like in a hash table or something like.

Regards,

Davi
Thread
Seeking command syntax feedback (Still Re: Per-db binlogging)Weldon Whipple15 Sep
  • Re: Seeking command syntax feedback (Still Re: Per-db binlogging)Sergei Golubchik15 Sep
    • Re: Seeking command syntax feedback (Still Re: Per-db binlogging)Weldon Whipple16 Sep
      • Re: Seeking command syntax feedback (Still Re: Per-db binlogging)Sergei Golubchik16 Sep
    • Re: Seeking command syntax feedback (Still Re: Per-db binlogging)Konstantin Osipov16 Sep
      • Re: Seeking command syntax feedback (Still Re: Per-db binlogging)Weldon Whipple16 Sep
        • Re: Seeking command syntax feedback (Still Re: Per-db binlogging)Davi Arnaut16 Sep
          • Re: Seeking command syntax feedback (Still Re: Per-db binlogging)Weldon Whipple16 Sep
            • Re: Seeking command syntax feedback (Still Re: Per-db binlogging)Davi Arnaut17 Sep
              • Re: Seeking command syntax feedback (Still Re: Per-db binlogging)Weldon Whipple17 Sep
  • Re: Seeking command syntax feedback (Still Re: Per-db binlogging)Konstantin Osipov16 Sep
    • Re: Seeking command syntax feedback (Still Re: Per-db binlogging)Weldon Whipple16 Sep