List:Commits« Previous MessageNext Message »
From:Alfranio Correia Date:March 24 2011 8:45am
Subject:Re: bzr commit into mysql-trunk branch (alfranio.correia:3305) Bug#58897
View as plain text  
Hi Andrei,

Let's have this discussion in the context of a different bug as we had agreed on.


On 03/24/2011 08:40 AM, Andrei Elkin wrote:
> Alfranio, hello.
> The latest patch is good.  I am cc-ing dev-private@ in order to get
> possible feedback on the actual "blind-eye" policy towards inadvertent
> or terroristically-minded modification of the system tables which is
> relevant to *all* server components, not just replication.  That
> paragraph is outlined.
>> #At
> file:///home/acorreia/
> based on revid:mayank.prasad@stripped
>>  3305 Alfranio Correia	2011-03-23
>>       BUG#11765887 BUG#58897 Rpl_info_table::do_is_transactional causes too much
> overhead
>>       After WL#2775, Slave's information,i.e. IO Thread and SQL Thread's
> information, can be
>>       stored into different types of repositories. The current implementation
> provides two
>>       repositories, i.e. FILE or TABLE, and any type of engine can be used.
>>       However, only transactional engines, such as Innodb, can provide a
> crash-safe behavior
>>       in the sense that a slave can continue operating after a crash without
> requiring any
>>       manual-intervention.
>>       If a transactional table is in use, a different execution path is called to
> provide a
>>       crash-safe behavior. Testing if a transactional engine is in use,
> unfortunately,
>>       requires to open and close the table, slave_relay_log_info, and this has a
> negative
>>       impact on performance.
>>       To fix this, we have cached the type of the repository in use,
> transactional or
>>       non-transactional, while starting the slave. This is done by introducing a
> member
>>       variable into the Rpl_info class.
>>       Changing the engine in use while the slave is running is not recommend and
> most likely
>>       will cause inconsistency issues. 
> I think we need a general concept for the server to secure the system
> database or maybe arbitrary database from modifications of both DDL and
> DML kinds. Currently the super-user can do everything to any system
> table, that is `mysql.slave_*` tables included, any time to cause
> unpredictable consequences.
> What the replicaton case requires is to have a permanent exclusive to a
> replication system threads privilege to `mysql.slave_*` tables. That is
> even the super-user that run in a different thread should not be able to
> modify the tables.
> Once the threads exit the tables get back to control of
> `mysql.tables_priv`.
> I see the task is of the server-scope and the replication team should not seek for a
> custom solution.

I agree.

>>       We do nothing in this patch to prevent such changes.
> What I would suggest is to write few (sure, the full coverage is just
> infeasible) run-time changes simulations - ddl & dml - to demo/memo 
> what's wrong that could lead to.

See comments above.

>>       In the future, however, we are going to check if the replication is stopped
> before
>>       allowing to change the engine in use or the table's structure in general,
> although
>>       the latter operations can apparently lead to fail-safe scenarios.
> cheers,
> Andrei

bzr commit into mysql-trunk branch (alfranio.correia:3305) Bug#58897Bug#11765887Alfranio Correia24 Mar
  • Re: bzr commit into mysql-trunk branch (alfranio.correia:3305) Bug#58897Bug#11765887Luís Soares24 Mar
    • Re: bzr commit into mysql-trunk branch (alfranio.correia:3305) Bug#58897Bug#11765887Davi Arnaut24 Mar
      • Re: bzr commit into mysql-trunk branch (alfranio.correia:3305) Bug#58897Bug#11765887Luís Soares24 Mar
Re: bzr commit into mysql-trunk branch (alfranio.correia:3305) Bug#58897Bug#11765887Alfranio Correia24 Mar