Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-14721

Big transaction events get lost on semisync master when replicate_events_marked_for_skip=FILTER_ON_MASTER

Details

    • 10.2.12, 10.0.34, 10.1.31, 10.2.13

    Description

      In a regular Master-Slave configuration the Slave sql erros out a dup key.

      The slave has been set up via backup restore and is claimed not to have
      any local updates. The backup restore procedure is standard to include
      `set global gtid_slave_pos=$GTID_from_backup` where the gtid value is
      extracted from `xtrabackup_info`. Barring a mistake of the slave gtid state setting,
      the following
      ``change master to master_host='xx.xx.xxx', master_port=zzzz master_user='user', master_password='xxxxx', master_use_gtid=slave_pos;
      start slave;```

      should've worked out without any issue.
      However the slave stopped. More details can be found on the customer issue page.

      Attachments

        Issue Links

          is duplicated by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-16001 parallel replication appears in deadlock

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            monty Michael Widenius added a comment -

            When events of a big transaction are binlogged offsetting over 2GB from
            the beginning of the log the semisync master's dump thread
            lost such events.
            The events were skipped by the Dump thread that found their skipping
            status erroneously.

            The current fixes make sure the skipping status is computed correctly.
            The test verifies them simulating the 2GB offset.

            monty Michael Widenius added a comment - When events of a big transaction are binlogged offsetting over 2GB from the beginning of the log the semisync master's dump thread lost such events. The events were skipped by the Dump thread that found their skipping status erroneously. The current fixes make sure the skipping status is computed correctly. The test verifies them simulating the 2GB offset.
            Elkin Andrei Elkin added a comment -

            Pushed as c09371dce66c483 to 10.2 and up.

            Elkin Andrei Elkin added a comment - Pushed as c09371dce66c483 to 10.2 and up.
            Elkin Andrei Elkin added a comment - - edited

            The 10.1 branch was patched as well with the commit id
            9005108234ca97ce9e86935fd79ea0b3fb97ec43

            The release can be seen from here:
            git describe --contains 9005108234ca97ce9e86935fd79ea0b3fb97ec43
            mariadb-10.1.32~66

            Elkin Andrei Elkin added a comment - - edited The 10.1 branch was patched as well with the commit id 9005108234ca97ce9e86935fd79ea0b3fb97ec43 The release can be seen from here: git describe --contains 9005108234ca97ce9e86935fd79ea0b3fb97ec43 mariadb-10.1.32~66

            People

              Elkin Andrei Elkin
              Elkin Andrei Elkin
              Votes:
              2 Vote for this issue
              Watchers:
              6 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.