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

Duplicate rows for unique index after upgrading from 10.6.11 to 10.6.14

Details

    Description

      After upgrading Mariadb from 10.6.11 to 10.6.14, we started to see multiple rows containing unique indices. When trying to insert rows with duplicate indices, we sometimes see "ERROR 1062 (23000): Duplicate entry" while sometimes it goes through. The table show duplicate rows with select statements. Recreating the index does not solve the problem.

      Attachments

        Issue Links

          Activity

            elenst Elena Stepanova added a comment - - edited

            Does CHECK TABLE .. EXTENDED show anything other than OK when duplicates occur? And are there any errors or warnings which seem to be relevant or at least unexpected in the server's error (not slave's log, but the one which has duplicates)?

            elenst Elena Stepanova added a comment - - edited Does CHECK TABLE .. EXTENDED show anything other than OK when duplicates occur? And are there any errors or warnings which seem to be relevant or at least unexpected in the server's error (not slave's log, but the one which has duplicates)?
            oadak Olgun Adak added a comment - - edited

            I did not check that statement when the duplicates occurred and we have already downgraded.
            Regarding the logs: I do not recall anything in master's error log when duplicates occurred, but we unfortunately rolled back the filesystem that contains the error log, so I am not able to double check that.

            One thing that looked off after the upgrade was following statement at the top of the binlogs created with 10.6.14 and opened with 10.6.14's mariadb-binlog binary. This warning was appearing even after I restart the engine to move to new binary.

            1. Warning: this binlog is either in use or was not closed properly....

            By the way, someone else seems to have experienced the same issue when moving from 10.3 to 10.6. She does not state the minor version, and she thinks she is solving it by fiddling with innodb parameters and does not file a bug report.

            https://dba.stackexchange.com/questions/327421/mariadb-10-3-mariadb-10-6innodb-duplicate-entry-for-key-unique-ind

            If you are completely stuck, we can try to clone our production database and repeat the upgrade to 10.6.14, however this will be a lengthy process and I also do not know exactly what to look for if I can get a problematic system up.

            oadak Olgun Adak added a comment - - edited I did not check that statement when the duplicates occurred and we have already downgraded. Regarding the logs: I do not recall anything in master's error log when duplicates occurred, but we unfortunately rolled back the filesystem that contains the error log, so I am not able to double check that. One thing that looked off after the upgrade was following statement at the top of the binlogs created with 10.6.14 and opened with 10.6.14's mariadb-binlog binary. This warning was appearing even after I restart the engine to move to new binary. Warning: this binlog is either in use or was not closed properly.... By the way, someone else seems to have experienced the same issue when moving from 10.3 to 10.6. She does not state the minor version, and she thinks she is solving it by fiddling with innodb parameters and does not file a bug report. https://dba.stackexchange.com/questions/327421/mariadb-10-3-mariadb-10-6innodb-duplicate-entry-for-key-unique-ind If you are completely stuck, we can try to clone our production database and repeat the upgrade to 10.6.14, however this will be a lengthy process and I also do not know exactly what to look for if I can get a problematic system up.
            elenst Elena Stepanova added a comment - - edited

            I expect it will be tracked further in MDEV-31120, but I'll leave it to marko to decide.

            You probably don't need a workaround if you rolled back anyway, but if you do, please try innodb_change_buffering=none, at least for now I suspect non-none-values to be causing the problem.

            elenst Elena Stepanova added a comment - - edited I expect it will be tracked further in MDEV-31120 , but I'll leave it to marko to decide. You probably don't need a workaround if you rolled back anyway, but if you do, please try innodb_change_buffering=none , at least for now I suspect non-none-values to be causing the problem.
            oadak Olgun Adak added a comment -

            Thank you. We have already rolled back, and will upgrade to a release with a fix for this issue.

            oadak Olgun Adak added a comment - Thank you. We have already rolled back, and will upgrade to a release with a fix for this issue.

            I think that this must duplicate MDEV-31120, which is a regression that was introduced in MariaDB Server 10.6.12.

            marko Marko Mäkelä added a comment - I think that this must duplicate MDEV-31120 , which is a regression that was introduced in MariaDB Server 10.6.12.

            People

              marko Marko Mäkelä
              oadak Olgun Adak
              Votes:
              1 Vote for this issue
              Watchers:
              7 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.