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.
> 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
>> 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
>> 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,
>> requires to open and close the table, slave_relay_log_info, and this has a
>> 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
>> 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
> I see the task is of the server-scope and the replication team should not seek for a
> custom solution.
>> 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
>> allowing to change the engine in use or the table's structure in general,
>> the latter operations can apparently lead to fail-safe scenarios.