[MDEV-10944] GALERA log-slave-updates REGRESSION FAILURE - after upgrading from 10.1.17 to 10.1.18 Created: 2016-10-03  Updated: 2017-01-23  Resolved: 2016-10-03

Status: Closed
Project: MariaDB Server
Component/s: Galera
Affects Version/s: 10.1.18
Fix Version/s: 10.1.19

Type: Bug Priority: Major
Reporter: Rob Brown Assignee: Nirbhay Choubey (Inactive)
Resolution: Fixed Votes: 0
Labels: regression
Environment:

CentOS 6.x or CentOS 7.x


Issue Links:
Duplicate
duplicates MDEV-10960 Replication broken since migrating to... Closed
duplicates MDEV-11128 Asynchronous replication slave to Mar... Closed

 Description   

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



 Comments   
Comment by Rob Brown [ 2016-10-03 ]

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

Comment by Rob Brown [ 2016-10-03 ]

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.

Comment by Rob Brown [ 2016-10-03 ]

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.

Comment by Rob Brown [ 2016-10-03 ]

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.

Comment by Roberto Rodríguez [ 2017-01-23 ]

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'

Generated at Thu Feb 08 07:46:07 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.