database/mariadb
database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-06-03 07:02:23 +03:00
Code
201,915 Commits 3,015 Branches 355 Tags
Commit Graph

4 Commits

Author SHA1 Message Date
Bill Qu
cdb8e6ed38 Bug #15868071 USING SET GLOBAL SQL_LOG_BIN SHOULD NOT BE ALLOWED 
Normally, SET SESSION SQL_LOG_BIN is used by DBAs to run a
non-conflicting command locally only, ensuring it does not
get replicated.
Setting GLOBAL SQL_LOG_BIN would not require all sessions to
disconnect. When SQL_LOG_BIN is changed globally, it does not
immediately take effect for any sessions. It takes effect by
becoming the session-level default inherited at the start of
each new session, and this setting is kept and cached for the
duration of that session. Setting it intentionally is unlikely
to have a useful effect under any circumstance; setting it
unintentionally, such as while intending to use SET [SESSION]
is potentially disastrous. Accidentally using SET GLOBAL
SQL_LOG_BIN will not show an immediate effect to the user,
instead not having the desired session-level effect, and thus
causing other potential problems with local-only maintenance
being binlogged and executed on slaves; And transactions from
new sessions (after SQL_LOG_BIN is changed globally) are not
binlogged and replicated, which would result in irrecoverable
or difficult data loss.
This is the regular GLOBAL variables way to work, but in
replication context it does not look right on a working server
(with connected sessions) 'set global sql_log_bin' and none of
that connections is affected. Unexperienced DBA after noticing
that the command did "nothing" will change the session var and
most probably won't unset the global var, causing new sessions
to not be binlog.
Setting GLOBAL SQL_LOG_BIN allows DBA to stop binlogging on all
new sessions, which can be used to make a server "replication
read-only" without restarting the server. But this has such big
requirements, stop all existing connections, that it is more
likely to make a mess, it is too risky to allow the GLOBAL variable.

The statement 'SET GLOBAL SQL_LOG_BIN=N' will produce an error
in 5.5, 5.6 and 5.7. Reading the GLOBAL SQL_LOG_BIN will produce
a deprecation warning in 5.7.
 2014-09-24 09:44:48 +08:00
Alfranio Correia
8357596035 BUG#53437 @@session.sql_bin_log support in substatements is incorrect 
The thd->variables.option_bits & OPTION_BIN_LOG is currently abused: 
it's both a system variable and an implementation switch. The current
approach to this option bit breaks the session variable encapsulation. 
      
Besides it is allowed to change @@session.sql_bin_log within a
transaction what may lead to not correctly logging a transaction.
      
To fix the problems,  we created a thd->variables variable to represent
the "sql_log_bin" and prohibited its update inside a transaction or
sub-statement.

mysql-test/suite/binlog/r/binlog_stm_unsafe_warning.result:
  Updated result file. The reason the warnings are removed is
  related to BUG#50312.
mysql-test/suite/binlog/r/binlog_switch_inside_trans.result:
  Checks when is possible to change the option @@session.sql_log_bin.
mysql-test/suite/binlog/t/binlog_switch_inside_trans.test:
  Checks when is possible to change the option @@session.sql_log_bin.
mysql-test/suite/rpl/r/rpl_non_direct_stm_mixing_engines.result:
  Updated the result file with warnings that were being printed
  due to the wrong use of the thd->variables.option_bits and
  sql_log_bin_top_level variables.
mysql-test/suite/rpl/r/rpl_stm_mixing_engines.result:
  Updated the result file with warnings that were being printed
  due to the wrong use of the thd->variables.option_bits and
  sql_log_bin_top_level variables.
sql/share/errmsg-utf8.txt:
  Introduces two error messages to notify that the @@session.sql_log_bin
  cannot be changed inside a sub-statement or transaction.
sql/sql_base.cc:
  Removes the variable sql_log_bin_toplevel and uses
  the session variable sql_log_bin.
sql/sql_class.cc:
  Replaces the variable sql_log_bin_toplevel by the
  (variables.option_bits & OPTION_BIN_LOG).
sql/sql_class.h:
  Removes the variable sql_log_bin_toplevel and creates 
  a session variable sql_log_bin.
sql/sys_vars.cc:
  Checks when the sql_log_bin can be correctly updated.
 2010-05-27 16:43:08 +01:00
Alfranio Correia
3300ff7a89 BUG#51277 SUPER_ACL should be checked unconditionally (binlog_format and binlog_direct) 
SUPER_ACL should be checked unconditionally while verifying if the binlog_format
or the binlog_direct_non_transactional_updates might be changed.

Roughly speaking, both session values cannot be changed in the context of a
transaction or a stored function. Note that changing the global value does
not cause any effect until a new connection is created.

So, we fixed the problem by first checking the permissions and right after further
verifications are ignored if the global value is being updated. In this patch, we
also re-structure the test case to make it more readable.
 2010-02-24 12:45:15 +00:00
Alexander Nozdrin
6f95733406 Manual merge of patch for Bug#46364 from mysql-next-mr-bugfixing. 
Conflicts:
  - mysql-test/r/mysqld--help-win.result
  - sql/sys_vars.cc

Original revsion (in next-mr-bugfixing):
------------------------------------------------------------
revno: 2971 [merge]
revision-id: alfranio.correia@sun.com-20100121210527-rbuheu5rnsmcakh1
committer: Alfranio Correia <alfranio.correia@sun.com>
branch nick: mysql-next-mr-bugfixing
timestamp: Thu 2010-01-21 21:05:27 +0000
message:
  BUG#46364 MyISAM transbuffer problems (NTM problem)
        
  It is well-known that due to concurrency issues, a slave can become
  inconsistent when a transaction contains updates to both transaction and
  non-transactional tables.
                      
  In a nutshell, the current code-base tries to preserve causality among the
  statements by writing non-transactional statements to the txn-cache which
  is flushed upon commit. However, modifications done to non-transactional
  tables on behalf of a transaction become immediately visible to other
  connections but may not immediately get into the binary log and therefore
  consistency may be broken.
              
  In general, it is impossible to automatically detect causality/dependency
  among statements by just analyzing the statements sent to the server. This
  happen because dependency may be hidden in the application code and it is
  necessary to know a priori all the statements processed in the context of
  a transaction such as in a procedure. Moreover, even for the few cases that
  we could automatically address in the server, the computation effort
  required could make the approach infeasible.
              
  So, in this patch we introduce the option
        - "--binlog-direct-non-transactional-updates" that can be used to bypass
        the current behavior in order to write directly to binary log statements
        that change non-transactional tables.
  
  Besides, it is used to enable the WL#2687 which is disabled by default.
    ------------------------------------------------------------
    revno: 2970.1.1
    revision-id: alfranio.correia@sun.com-20100121131034-183r4qdyld7an5a0
    parent: alik@sun.com-20100121083914-r9rz2myto3tkdya0
    committer: Alfranio Correia <alfranio.correia@sun.com>
    branch nick: mysql-next-mr-bugfixing
    timestamp: Thu 2010-01-21 13:10:34 +0000
    message:
      BUG#46364 MyISAM transbuffer problems (NTM problem)
            
      It is well-known that due to concurrency issues, a slave can become
      inconsistent when a transaction contains updates to both transaction and
      non-transactional tables.
                          
      In a nutshell, the current code-base tries to preserve causality among the
      statements by writing non-transactional statements to the txn-cache which
      is flushed upon commit. However, modifications done to non-transactional
      tables on behalf of a transaction become immediately visible to other
      connections but may not immediately get into the binary log and therefore
      consistency may be broken.
                  
      In general, it is impossible to automatically detect causality/dependency
      among statements by just analyzing the statements sent to the server. This
      happen because dependency may be hidden in the application code and it is
      necessary to know a priori all the statements processed in the context of
      a transaction such as in a procedure. Moreover, even for the few cases that
      we could automatically address in the server, the computation effort
      required could make the approach infeasible.
                  
      So, in this patch we introduce the option
            - "--binlog-direct-non-transactional-updates" that can be used to bypass
            the current behavior in order to write directly to binary log statements
            that change non-transactional tables.
      
      Besides, it is used to enable the WL#2687 which is disabled by default.
 2010-02-02 10:56:42 +03:00