Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 10.0.2
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      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.

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            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.

            Show
            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.
            Hide
            knielsen Kristian Nielsen added a comment -

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

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

              People

              • Assignee:
                knielsen Kristian Nielsen
                Reporter:
                pivanof Pavel Ivanov
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: