[MDEV-16543] Replicating to spider is fragile without retries Created: 2018-06-21  Updated: 2020-08-25  Resolved: 2019-04-12

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - Spider
Affects Version/s: 10.3
Fix Version/s: 10.4.5

Type: Bug Priority: Critical
Reporter: Mattias Jonsson Assignee: Kentoku Shiba (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux



 Description   

I encountered a failure in the replication to a spider table that is not mentioned in the recommendations at https://mariadb.com/kb/en/library/spider-storage-engine-overview/#some-server-variables-to-set-when-using-spider.

From 'show slave status\G':

                Last_SQL_Errno: 1429
                Last_SQL_Error: Could not execute Update_rows_v1 event on table db.t3; Unable to connect to foreign data source: spider-datanode3, Error_code: 1429; handler error No Error!; the event's master log binlog.000164, end_log_pos 52742152

It did work again after:

start slave sql_thread;

Can these issues be retried within the spider engine instead of failing in the engine and retried in the replication? (or are they failing after multiple attempts in the engine and the replication just continues to retry until it succeeds?)

Also I would expect the default settings to handle this, rather than having to add configuration mentioned in the link above.



 Comments   
Comment by Kentoku Shiba (Inactive) [ 2019-03-05 ]

I assume that it is naturally design that retrying transaction is done by SQL threads of the replication. This is like deadlock and lock wait timeout.
So I added default values to slave_transaction_retry_errors.
40ae2e8

Comment by Kentoku Shiba (Inactive) [ 2019-03-05 ]

Would you please review this changes?

Comment by Kentoku Shiba (Inactive) [ 2019-04-12 ]

merged into 10.4 tree

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