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

MariaDB upgrade breaks replication

Details

    Description

      The Debian start script for MariaDB, in debian/additions/debian-start and debian/additions/debian-start.inc.sh, runs mysql_upgrade without specifying --skip-write-binlog. As a result, statements contained in scripts/mysql_system_tables_fix.sql will be replicated and fail on the slave.

      To be more specific, the ALTER TABLE statements to general_log and slow_log will be replicated, and although mysql_system_tables_fix.sql does disable each of them before running the ALTER TABLEs, these SET statements will not be replicated. When the ALTER TABLE statements are replicated, if the slave system has either log enabled, then replication will break.

      I believe debian/additions/debian-start should be modified so that

      MYUPGRADE="/usr/bin/mysql_upgrade --defaults-extra-file=/etc/mysql/debian.cnf"

      becomes

      MYUPGRADE="/usr/bin/mysql_upgrade --defaults-extra-file=/etc/mysql/debian.cnf --skip-write-binlog"

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-5786 mysql_upgrade on galera replicates "alter table" on system tables

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-9996 Do not replicate debian-sys-maint user setup in Debian postinst

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed
          links to

          Web Link Percona Launchpad issue

          Activity

            Ascending order - Click to sort in descending order
            hexetic Tim Gokcen created issue -
            hexetic Tim Gokcen added a comment -

            Note that the original MySQL bug for this seems to be:
            http://bugs.mysql.com/bug.php?id=43579

            Li-Bing.Song@sun.com first changed mysql_upgrade so that it always disabled the binary log, then revised his patch so that it is instead necessary to specify --skip-write-binlog.

            hexetic Tim Gokcen added a comment - Note that the original MySQL bug for this seems to be: http://bugs.mysql.com/bug.php?id=43579 Li-Bing.Song@sun.com first changed mysql_upgrade so that it always disabled the binary log, then revised his patch so that it is instead necessary to specify --skip-write-binlog.
            elenst Elena Stepanova added a comment -

            Probably it concerns RPMs as well.

            elenst Elena Stepanova added a comment - Probably it concerns RPMs as well.
            elenst Elena Stepanova made changes -
            Field Original Value New Value
            Fix Version/s 10.0.6 [ 13202 ]
            Fix Version/s 5.5.34 [ 13700 ]
            Assignee Sergei Golubchik [ serg ]
            Labels packaging
            hexetic Tim Gokcen added a comment -

            Link to related Percona issue 1065841

            hexetic Tim Gokcen added a comment - Link to related Percona issue 1065841
            hexetic Tim Gokcen made changes -
            serg Sergei Golubchik made changes -
            Labels packaging packaging upstream
            serg Sergei Golubchik added a comment -

            Perhaps we'd better change mysql_upgrade to do --skip-write-binlog by default, and one can specify --write-binlog explicitly, if desired?

            serg Sergei Golubchik added a comment - Perhaps we'd better change mysql_upgrade to do --skip-write-binlog by default, and one can specify --write-binlog explicitly, if desired?
            elenst Elena Stepanova added a comment -

            I think it makes sense. It's hard to imagine that somebody, while upgrading a slave, relies on mysql_upgrade actions coming from master through replication, and without that there should be no other reason to replicate mysql_upgrade activity, while the danger of doing so is obvious.

            It would be interesting to know why Li-Bing.Song@sun.com changed the decision, but apparently the discussion hides somewhere in private.

            elenst Elena Stepanova added a comment - I think it makes sense. It's hard to imagine that somebody, while upgrading a slave, relies on mysql_upgrade actions coming from master through replication, and without that there should be no other reason to replicate mysql_upgrade activity, while the danger of doing so is obvious. It would be interesting to know why Li-Bing.Song@sun.com changed the decision, but apparently the discussion hides somewhere in private.
            serg Sergei Golubchik made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            serg Sergei Golubchik made changes -
            Resolution Fixed [ 1 ]
            Status In Progress [ 3 ] Closed [ 6 ]
            danblack Daniel Black made changes -
            serg Sergei Golubchik made changes -
            Workflow defaullt [ 29242 ] MariaDB v2 [ 44617 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Workflow MariaDB v2 [ 44617 ] MariaDB v3 [ 63973 ]
            hexetic Tim Gokcen made changes -
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 63973 ] MariaDB v4 [ 147109 ]

            People

              serg Sergei Golubchik
              hexetic Tim Gokcen
              Votes:
              0 Vote for this issue
              Watchers:
              3 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.