Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.0.2
    • None
    • None
    • None

    Description

      Current GTID implementation allows situations when slave is not configured read-only and accepts any transactions from clients. These transactions get inserted in the middle of replication stream and then don't go anywhere. So essentially they generate data drift without any error messages and without easy methods of detection.

      To make production environments more bullet-proof there should be a flag turning on the "strict mode" for GTID replication in which slave accepts from master and binlog allows to commit only transactions with strictly increasing seq_no for each domain.

      Attachments

        Activity

          pivanof Pavel Ivanov added a comment -

          After some thinking on this I realized that we would like to see the following here:

          1) MariaDB requires sequence numbers in each domain to strictly grow. Any repeating number or number less than before should stop replication.
          2) Master prohibits slave connections with GTIDs that don't exist in the binlogs even if there are events with the same domain_id and server_id, and with seq_no before and after requested GTID.
          3) If slave connects with GTID that doesn't exists in binlogs master can issue two (or more if you'd like) different errors:

          • One error if GTID appears to be before the very first event in the binlogs or after the very last one. This error mean that requested GTID is too old and there's no binlogs for that, or connecting slave is further in replication than the master.
          • Another error if there is event in binlog with the same seq_no as requested GTID but different server_id, or if there's no such seq_no in the binlogs but there are sequence numbers less than requested and greater than requested. Both situations mean that connecting slave has an alternate future.
            4) Probably with a separate flag we want to prohibit any writes to binlog on the slave except from the slave thread(s), i.e. whenever MASTER_HOST is configured server works as if sql_log_bin = 0 globally except for the slave thread(s) which work as if sql_log_bin = 1 and SELECT @@global.sql_log_bin still returns 1.

          These changes will match our current MySQL tree and if you don't have strong objections we would really like to see these changes upstream.

          pivanof Pavel Ivanov added a comment - After some thinking on this I realized that we would like to see the following here: 1) MariaDB requires sequence numbers in each domain to strictly grow. Any repeating number or number less than before should stop replication. 2) Master prohibits slave connections with GTIDs that don't exist in the binlogs even if there are events with the same domain_id and server_id, and with seq_no before and after requested GTID. 3) If slave connects with GTID that doesn't exists in binlogs master can issue two (or more if you'd like) different errors: One error if GTID appears to be before the very first event in the binlogs or after the very last one. This error mean that requested GTID is too old and there's no binlogs for that, or connecting slave is further in replication than the master. Another error if there is event in binlog with the same seq_no as requested GTID but different server_id, or if there's no such seq_no in the binlogs but there are sequence numbers less than requested and greater than requested. Both situations mean that connecting slave has an alternate future. 4) Probably with a separate flag we want to prohibit any writes to binlog on the slave except from the slave thread(s), i.e. whenever MASTER_HOST is configured server works as if sql_log_bin = 0 globally except for the slave thread(s) which work as if sql_log_bin = 1 and SELECT @@global.sql_log_bin still returns 1. These changes will match our current MySQL tree and if you don't have strong objections we would really like to see these changes upstream.

          Pushed to 10.0-base, and documented in the Knowledgebase.

          knielsen Kristian Nielsen added a comment - Pushed to 10.0-base, and documented in the Knowledgebase.

          People

            knielsen Kristian Nielsen
            pivanof Pavel Ivanov
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.