Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.1.26
    • 10.1.27
    • Plugins
    • None
    • CentOS 7, MariaDB 10.1.26, encryption enabled (aws-kms), master-slave replication with one master and one slave

    Description

      Set up a fresh environment, configured encryption and replication, and set up pt-table-checksum to check the database that is replicated. The database is still empty, no records in there yet. Whenever pt-table-checksum runs, it crashes the server.

      I have an older environment running 10.1.21. Configuration-wise it is an exact replica of the fresh environment (except for the older MariaDB version). pt-table-checksum works fine there.

      Attachments

        1. error.log
          6 kB
        2. schema.sql
          4 kB
        3. variables.log
          18 kB

        Issue Links

          Activity

            Downgraded both master and slave to 10.1.21 and the crashes are indeed gone. So it looks like a regression introduced in a newer version.

            pprkut Heinz Wiesinger added a comment - Downgraded both master and slave to 10.1.21 and the crashes are indeed gone. So it looks like a regression introduced in a newer version.

            It looks like the database is not completely empty, there are at least tables. Could you please paste the output of SHOW CREATE TABLE `heartbeat`.`patient_medication` and attach your cnf file(s) or SHOW VARIABLES?

            Are any special options for pt-table-checksum required?

            elenst Elena Stepanova added a comment - It looks like the database is not completely empty, there are at least tables. Could you please paste the output of SHOW CREATE TABLE `heartbeat`.`patient_medication` and attach your cnf file(s) or SHOW VARIABLES ? Are any special options for pt-table-checksum required?

            Right, I mentioned it on IRC, but forgot to mention it properly here. There is a database with a couple tables, but the tables themselves are empty. I attached the table schema of the tables involved as well as the output of SHOW VARIABLES.

            The pt-table-checksum command we use is

            pt-table-checksum -u percona -p password --no-check-plan --databases heartbeat --quiet

            pprkut Heinz Wiesinger added a comment - Right, I mentioned it on IRC, but forgot to mention it properly here. There is a database with a couple tables, but the tables themselves are empty. I attached the table schema of the tables involved as well as the output of SHOW VARIABLES . The pt-table-checksum command we use is pt-table-checksum -u percona -p password --no-check-plan --databases heartbeat --quiet
            elenst Elena Stepanova added a comment - - edited

            It appears to be one of numerous vague consequences of the problem with loading both AWS and server audit.

            Reproducible by starting server
            --encrypt-tmp-files --plugin-load-add=server_audit --plugin-load-add=aws_key_management <valid aws options>, loading the attached dump and then executing
            percona-toolkit-3.0.2/bin/pt-table-checksum -uroot --no-check-plan --quiet --port=3306 --host=127.0.0.1 --databases test

            The scenario can obviously be simplified, but there is no much point doing it now, because the mere server startup with these options already causes all kinds of troubles.

            The problem was already fixed in the scope of MDEV-13060, but only in 10.2. I have created a request for a backport to 10.1 in MDEV-13650. This bug is blocked until the backport is done, after that we will need to re-check it.

            elenst Elena Stepanova added a comment - - edited It appears to be one of numerous vague consequences of the problem with loading both AWS and server audit. Reproducible by starting server --encrypt-tmp-files --plugin-load-add=server_audit --plugin-load-add=aws_key_management <valid aws options> , loading the attached dump and then executing percona-toolkit-3.0.2/bin/pt-table-checksum -uroot --no-check-plan --quiet --port=3306 --host=127.0.0.1 --databases test The scenario can obviously be simplified, but there is no much point doing it now, because the mere server startup with these options already causes all kinds of troubles. The problem was already fixed in the scope of MDEV-13060 , but only in 10.2. I have created a request for a backport to 10.1 in MDEV-13650 . This bug is blocked until the backport is done, after that we will need to re-check it.

            I'm now running 10.1.28 on the servers for some time and didn't experience any crashes. Looks like the backport fixed it

            pprkut Heinz Wiesinger added a comment - I'm now running 10.1.28 on the servers for some time and didn't experience any crashes. Looks like the backport fixed it

            Thanks for checking!

            elenst Elena Stepanova added a comment - Thanks for checking!

            According to the above, closing as fixed in the scope of MDEV-13650.

            elenst Elena Stepanova added a comment - According to the above, closing as fixed in the scope of MDEV-13650 .

            People

              Unassigned Unassigned
              pprkut Heinz Wiesinger
              Votes:
              1 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.