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

Upgrade from 5.5.27 to 5.5.28 breaking master binlogs

    Details

    • Type: Bug
    • Status: Open
    • Priority: Trivial
    • Resolution: Unresolved
    • Affects Version/s: 5.5.28
    • Fix Version/s: 5.5
    • Component/s: None
    • Environment:
      Ubuntu 12.10 AMD64 Precise
      MariaDB from PPA (precise)

      Description

      We're running a multi-master setup between 2 machines where they are both a master and a slave of the other master.

      When we upgraded one of the servers from 5.5.27 to 5.5.28 the binlogs were all removed which broke the replication. The file and position had to be reset its slave.

      We thought this was an unlucky anomaly, but when we upgraded the other server the same thing happened again.

      I couldn't find anything in the Changelog for this version so this is probably a bug then?

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            elenst Elena Stepanova added a comment -

            Hi Frank,

            Please provide your cnf files from the server where the problem was observed, and describe step-by-step your upgrade process.

            Thank you.

            Show
            elenst Elena Stepanova added a comment - Hi Frank, Please provide your cnf files from the server where the problem was observed, and describe step-by-step your upgrade process. Thank you.
            Hide
            frank Frank added a comment -

            Hi Elena,

            I believe our my.cnf is pretty much stock, the files have been attached.
            The upgrade was done via apt: "apt-get upgrade".

            The packages originate from your Ubuntu Repository.

            Show
            frank Frank added a comment - Hi Elena, I believe our my.cnf is pretty much stock, the files have been attached. The upgrade was done via apt: "apt-get upgrade". The packages originate from your Ubuntu Repository.
            Hide
            elenst Elena Stepanova added a comment -

            Hi Frank,

            Thanks.

            Most likely your binary logs have not been removed, but still exist in /var/log/mysql/mariadb-bin.* (unless you have some kind of a cleanup process).
            However, after upgrade your server started placing binary logs in another location, /var/lib/mysql, and expects to find the old ones there too.

            In the main cnf file (the standard configuration) you have:

            log_bin = /var/log/mysql/mariadb-bin

            But in the extra.cnf file you also have

            log_bin

            (without a value).

            Before 5.5.28, the second log_bin was ignored, and your binary logs were located in /var/log/mysql/mariadb-bin.*

            However, in 5.5.28 log_bin without a value is taken into account and resets the previously configured name and location, so new binary logs are written to the default folder (datadir, /var/lib/mysql) with a default basename.

            I suppose it's a side-effect of one of small changes, probably from this revision http://bazaar.launchpad.net/~maria-captains/maria/5.5/revision/3533.1.2, a part about log-bin.

            Technically it is not wrong (the behavior is consistent with the description of the option). Unfortunately, there is also an old issue which exists both in MySQL and MariaDB: after a location of the binlog files changes, even although the index file contains full paths to the logs, no operations on the old logs is possible, the server throws "Could not find target log" error.

            So, the combination of this old problem, your configuration and the recent change causes the compatibility issue that affects your installation.

            As a workaround, if you haven't fixed the current situation yet, you can move all logs into the same folder (whichever your prefer, as long as you place the correct location in the cnf file and modify the index file accordingly).

            For further upgrades, you can just remove log_bin from the extra.cnf.

            Show
            elenst Elena Stepanova added a comment - Hi Frank, Thanks. Most likely your binary logs have not been removed, but still exist in /var/log/mysql/mariadb-bin.* (unless you have some kind of a cleanup process). However, after upgrade your server started placing binary logs in another location, /var/lib/mysql, and expects to find the old ones there too. In the main cnf file (the standard configuration) you have: log_bin = /var/log/mysql/mariadb-bin But in the extra.cnf file you also have log_bin (without a value). Before 5.5.28, the second log_bin was ignored, and your binary logs were located in /var/log/mysql/mariadb-bin.* However, in 5.5.28 log_bin without a value is taken into account and resets the previously configured name and location, so new binary logs are written to the default folder (datadir, /var/lib/mysql) with a default basename. I suppose it's a side-effect of one of small changes, probably from this revision http://bazaar.launchpad.net/~maria-captains/maria/5.5/revision/3533.1.2 , a part about log-bin. Technically it is not wrong (the behavior is consistent with the description of the option). Unfortunately, there is also an old issue which exists both in MySQL and MariaDB: after a location of the binlog files changes, even although the index file contains full paths to the logs, no operations on the old logs is possible, the server throws "Could not find target log" error. So, the combination of this old problem, your configuration and the recent change causes the compatibility issue that affects your installation. As a workaround, if you haven't fixed the current situation yet, you can move all logs into the same folder (whichever your prefer, as long as you place the correct location in the cnf file and modify the index file accordingly). For further upgrades, you can just remove log_bin from the extra.cnf.
            Hide
            elenst Elena Stepanova added a comment -

            Hi Kristian,

            Could you please take a look at the above comment to see whether the issue can be fixed somehow for future.

            Show
            elenst Elena Stepanova added a comment - Hi Kristian, Could you please take a look at the above comment to see whether the issue can be fixed somehow for future.

              People

              • Assignee:
                Unassigned
                Reporter:
                frank Frank
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated: