Bug #88947 | Documentation for slave_transaction_retries not complete | ||
---|---|---|---|
Submitted: | 16 Dec 2017 10:49 | Modified: | 18 Apr 2018 8:57 |
Reporter: | Daniël van Eeden (OCA) | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Documentation | Severity: | S3 (Non-critical) |
Version: | 5.7 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[16 Dec 2017 10:49]
Daniël van Eeden
[19 Dec 2017 7:40]
MySQL Verification Team
Hello Daniël, Thank you for the report! Thanks, Umesh
[18 Apr 2018 8:57]
Margaret Fisher
Posted by developer: Thanks for pointing this out. The answers are that 0 does disable retries, and the number of retries is shown in the replication_applier_status Performance Schema table. I've updated the description in 5.7 and 8.0. The 8.0 version now reads: Sets the maximum number of times for replication slave SQL threads on a single-threaded or multi-threaded slave to automatically retry failed transactions before stopping. Setting this variable takes effect for all replication channels immediately, including running channels. The default value is 10. Setting the variable to 0 disables automatic retrying of transactions. If a replication slave SQL thread fails to execute a transaction because of an InnoDB deadlock or because the transaction's execution time exceeded InnoDB's innodb_lock_wait_timeout, it automatically retries slave_transaction_retries times before stopping with an error. The Performance Schema table replication_applier_status shows the number of retries that took place on each replication channel, in the COUNT_TRANSACTIONS_RETRIES column. - I also added a reference in the description of the PS table to the system variable.