An error occurred fetching the project authors.
  1. 28 Apr, 2010 1 commit
  2. 31 Mar, 2010 1 commit
    • Alfranio Correia's avatar
      BUG#51291 Unfortunate effect around variable binlog_direct_non_transactional_updates · 7827688f
      Alfranio Correia authored
      BUG#46364 introduced the flag binlog_direct_non_transactional_updates which
      would make N-changes to be written to the binary log upon committing the
      statement when "ON". On the other hand, when "OFF" the option was supposed
      to mimic the behavior in 5.1. However, the implementation was not mimicking
      the behavior correctly and the following bugs popped up:
      
        Case #1: N-changes executed within a transaction would go into
                 the S-cache. When later in the same transaction a
                 T-change occurs, N-changes following it were written
                 to the T-cache instead of the S-cache. In some cases,
                 this raises problems. For example, a
                 Table_map_log_event being written initially into the
                 S-cache, together with the initial N-changes, would be
                 absent from the T-cache. This would log N-changes
                 orphaned from a Table_map_log_event (thence discarded
                 at the slave). (MIXED and ROW)
      
         Case #2: When rolling back a transaction, the N-changes that
                  might be in the T-cache were disregarded and
                  truncated along with the T-changes. (MIXED and ROW)
      
         Case #3: When a MIXED statement (TN) is ahead of any other
                  T-changes in the transaction and it fails, it is kept
                  in the T-cache until the transaction ends. This is
                  not the case in 5.1 or Betony (5.5.2). In these, the
                  failed TN statement would be written to the binlog at
                  the same instant it had failed and not deferred until
                  transaction end. (SBR)
      
      To fix these problems, we have decided to do what follows:
      
         For Case #1 and #2, we circumvent them:
      
            1. by not letting binlog_direct_non_transactional_updates
               affect MIXED and RBR. These modes will keep the behavior
               provided by WL#2687. Although this will make Celosia to
               behave differently from 5.1, an execution will be always
               safe under such modes in the sense that slaves will never
               go out sync. In 5.1, using either MIXED or ROW while
               mixing N-statements and T-statements was not safe.
      
         For Case #3, we don't actually fix it. We:
      
            1. keep it and make all MIXED statements whether they end
               up failing or not or whether they are up front in the
               transaction or after some transactional change to always
               be stored in the T-cache. This means that it is written
               to the binary log on transaction commit/rollback only.
      
            2. We make the warning message even more specific about the
               MIXED statement and SBR.
      7827688f
  3. 02 Feb, 2010 1 commit
    • Alexander Nozdrin's avatar
      Manual merge of patch for Bug#46364 from mysql-next-mr-bugfixing. · 33e5e125
      Alexander Nozdrin authored
      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.
      33e5e125
  4. 21 Jan, 2010 1 commit
    • Alfranio Correia's avatar
      BUG#46364 MyISAM transbuffer problems (NTM problem) · 8da3fea2
      Alfranio Correia authored
            
      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.
      8da3fea2
  5. 11 Nov, 2009 1 commit
  6. 03 Nov, 2009 1 commit
    • Alfranio Correia's avatar
      WL#2687 WL#5072 BUG#40278 BUG#47175 · 60d46624
      Alfranio Correia authored
      Non-transactional updates that take place inside a transaction present problems
      for logging because they are visible to other clients before the transaction
      is committed, and they are not rolled back even if the transaction is rolled
      back. It is not always possible to log correctly in statement format when both
      transactional and non-transactional tables are used in the same transaction.
      
      In the current patch, we ensure that such scenario is completely safe under the
      ROW and MIXED modes.
      60d46624
  7. 27 Aug, 2009 1 commit
    • Alfranio Correia's avatar
      BUG#46864 Incorrect update of InnoDB table on slave when using trigger with myisam table · c21fbff3
      Alfranio Correia authored
      Slave does not correctly handle "expected errors" leading to inconsistencies
      between the mater and slave. Specifically, when a statement changes both
      transactional and non-transactional tables, the transactional changes are
      automatically rolled back on the master but the slave ignores the error and
      does not roll them back thus leading to inconsistencies.
            
      To fix the problem, we automatically roll back a statement that fails on
      the slave but note that the transaction is not rolled back unless a "rollback"
      command is in the relay log file.
      c21fbff3
  8. 26 Aug, 2009 1 commit
    • Alfranio Correia's avatar
      BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect · dbcfef4c
      Alfranio Correia authored
      binlog
      
      Mixing transactional (T) and non-transactional (N) tables on behalf of a
      transaction may lead to inconsistencies among masters and slaves in STATEMENT
      mode. The problem stems from the fact that although modifications done to
      non-transactional tables on behalf of a transaction become immediately visible
      to other connections they do not immediately get to the binary log and therefore
      consistency is broken. Although there may be issues in mixing T and M tables in
      STATEMENT mode, there are safe combinations that clients find useful.
      
      In this bug, we fix the following issue. Mixing N and T tables in multi-level
      (e.g. a statement that fires a trigger) or multi-table table statements (e.g.
      update t1, t2...) were not handled correctly. In such cases, it was not possible
      to distinguish when a T table was updated if the sequence of changes was N and T.
      In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect
      that both a N and T tables were changed. To circumvent this issue, we check if an
      engine is registered in the handler's list and changed something which means that
      a T table was modified.
      
      Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or
      ROW modes completely safe.
      dbcfef4c