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

GALERA log-slave-updates REGRESSION FAILURE - after upgrading from 10.1.17 to 10.1.18

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.1.18
    • 10.1.19
    • Galera
    • CentOS 6.x or CentOS 7.x

    Description

      The log-slaves-updates=1 setting suddenly stopped working in 10.1.18.

      Attachments

        Issue Links

          Activity

            bs Rob Brown added a comment -

            We are using a Galera cluster setup, so it might only be an issue with Galera. I'm not sure.

            bs Rob Brown added a comment - We are using a Galera cluster setup, so it might only be an issue with Galera. I'm not sure.
            bs Rob Brown added a comment -

            We need a read-only slave from the galera cluster, so we need at least one node with "log-slave-updates" enabled so we can replay all the queries and keep the slave consistent with the cluster, but the only SQL surviving the replication are those executed directly to the master being used to slave from.

            The master (galera node) server does remain in sync with all the other galera nodes. It just fails to log any SQL to its binlog except for those executed DIRECTLY to this server.

            bs Rob Brown added a comment - We need a read-only slave from the galera cluster, so we need at least one node with "log-slave-updates" enabled so we can replay all the queries and keep the slave consistent with the cluster, but the only SQL surviving the replication are those executed directly to the master being used to slave from. The master (galera node) server does remain in sync with all the other galera nodes. It just fails to log any SQL to its binlog except for those executed DIRECTLY to this server.
            bs Rob Brown added a comment -

            Downgrading from to MariaDB-server-10.1.18 to MariaDB-server-10.1.17 always fixes the problem and all the SQL entries suddenly start logging correctly again.

            bs Rob Brown added a comment - Downgrading from to MariaDB-server-10.1.18 to MariaDB-server-10.1.17 always fixes the problem and all the SQL entries suddenly start logging correctly again.
            bs Rob Brown added a comment -

            After doing some more testing, I just confirmed that the "log-slaves-updates=1" feature actually functions perfectly if "wsrep_on=OFF" on MariaDB version 1.1.18.

            So this bug is ONLY manifested if "wsrep_on=ON" which causes none of the slaved queries to go into its binlog.

            Or downgrading MariaDB from version 1.1.18 to version 1.1.17 (even if "wsrep_on=ON") allows the slaved (clustered) SQLs to log into binlog again.

            bs Rob Brown added a comment - After doing some more testing, I just confirmed that the "log-slaves-updates=1" feature actually functions perfectly if "wsrep_on=OFF" on MariaDB version 1.1.18. So this bug is ONLY manifested if "wsrep_on=ON" which causes none of the slaved queries to go into its binlog. Or downgrading MariaDB from version 1.1.18 to version 1.1.17 (even if "wsrep_on=ON") allows the slaved (clustered) SQLs to log into binlog again.

            I think that this issue is still present in MariaDB 10.1.21. If I set wsrep_on=OFF the asyncronous replication into galera cluster works perfectly, but as soon as I re-enable it, I get the error:

            2017-01-23 12:55:24 140711297583872 [Note] Slave I/O thread: connected to master 'repluser@myserver.com:3306',replication starts at GTID position '0-1-6129282744'
            2017-01-23 12:55:24 140711296977664 [Warning] WSREP: SQL statement was ineffective, THD: 12, buf: 8114
            schema: mydatabase
            QUERY: COMMIT
            => Skipping replication
            2017-01-23 12:55:24 140711296977664 [ERROR] Slave SQL: Error 'Got error 35 "Resource deadlock avoided" during COMMIT' on query. Default database: 'mydatabase'. Query: 'COMMIT', Gtid 0-1-6129282869, Internal MariaDB error code: 1180
            2017-01-23 12:55:24 140711296977664 [ERROR] Slave SQL: Node has dropped from cluster, Gtid 0-1-6129282869, Internal MariaDB error code: 1047
            2017-01-23 12:55:24 140711296977664 [Note] Slave SQL thread exiting, replication stopped in log 'myserver-bin.002750' at position 23529189; GTID position '0-1-6129282744'

            rgrober Roberto Rodríguez added a comment - I think that this issue is still present in MariaDB 10.1.21. If I set wsrep_on=OFF the asyncronous replication into galera cluster works perfectly, but as soon as I re-enable it, I get the error: 2017-01-23 12:55:24 140711297583872 [Note] Slave I/O thread: connected to master 'repluser@myserver.com:3306',replication starts at GTID position '0-1-6129282744' 2017-01-23 12:55:24 140711296977664 [Warning] WSREP: SQL statement was ineffective, THD: 12, buf: 8114 schema: mydatabase QUERY: COMMIT => Skipping replication 2017-01-23 12:55:24 140711296977664 [ERROR] Slave SQL: Error 'Got error 35 "Resource deadlock avoided" during COMMIT' on query. Default database: 'mydatabase'. Query: 'COMMIT', Gtid 0-1-6129282869, Internal MariaDB error code: 1180 2017-01-23 12:55:24 140711296977664 [ERROR] Slave SQL: Node has dropped from cluster, Gtid 0-1-6129282869, Internal MariaDB error code: 1047 2017-01-23 12:55:24 140711296977664 [Note] Slave SQL thread exiting, replication stopped in log 'myserver-bin.002750' at position 23529189; GTID position '0-1-6129282744'

            People

              nirbhay_c Nirbhay Choubey (Inactive)
              bs Rob Brown
              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.