Details
-
New Feature
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
Description
The master-retry-count setting can't be changed, or at least verified, at runtime as there is no SQL variable for this setting.
Also the setting is only documented as a command line option, even though it is also accepted as a valid option in configuration files
https://mariadb.com/kb/en/mysqld-options/#-master-retry-count
Attachments
Issue Links
- causes
-
MDEV-36141 Master & Relay Log Info: expand init_intvar_from_file from atoi to atoll
-
- Open
-
- is part of
-
-
- Closed
-
- relates to
-
MDEV-6188 master_retry_count (ignored if disconnect happens on SET master_heartbeat_period)
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- split to
-
-
- Closed
-
Activity
hholzgra, does performance_schema.replication_connection_configuration present an acceptable solution from your point of view?
I ran across this issue in support ticket CS0719438.
You can put master_retry_count=100000 in a startup options file, but you cannot see it from global variables:
MariaDB [(none)]> show global variables like 'master_retry_count';
|
Empty set (0.000 sec)
|
While Juan Vera corrected the documentation and workaround available, still have MASTER_RETRY_COUNT exposed as part of the CHANGE MASTER TO command would be more efficient (compare to workaround) way to prevent tickets from customers, facing forward.
Does CHANGE MASTER TO have a syntax to list current configs without changing anything?
And how should this command-line option apply in multi-source CHANGE MASTER ['connection_name'] TO?
In the meantime, this is valid for a global SQL variable independently of whether it makes sense for CHANGE MASTER TO.
Remember performance_schema.replication_connection_configuration?
In storage/perfschema/table_replication_connection_configuration.cc:
m_row.connection_retry_count= master_retry_count; //(ulong) mi->retry_count; |
Update: GitHub blame shows that this comment’s been there since time immemorial.
Hi ParadoxV5, sorry for the confusion, susil.behera only reviewed the MTR cases you wrote, he still needs to do his own QA testing once the preview branches have been released. So I'm re-opening this and setting it to be in-testing.
As the patch was already pushed to the main branch, we will just keep it there, and then if susil.behera has any findings that we can't address before the release (for some reason), we will just revert it.
I'm marking testing done as more detailed testing is being covered as part of MDEV-35304. Basic variable presence in master-slave, multi-source setups are working fine.
On 10.6 there is performance_schema.replication_connection_configuration table, that shows CONNECTION_RETRY_COUNT:
MariaDB [performance_schema]> select * from performance_schema.replication_connection_configuration\G*************************** 1. row ***************************CHANNEL_NAME:HOST: localhostPORT: 3313USER: rootUSING_GTID: NOSSL_ALLOWED: NOSSL_CA_FILE:SSL_CA_PATH:SSL_CERTIFICATE:SSL_CIPHER:SSL_KEY:SSL_VERIFY_SERVER_CERTIFICATE: NOSSL_CRL_FILE:SSL_CRL_PATH:CONNECTION_RETRY_INTERVAL: 60CONNECTION_RETRY_COUNT: 100000HEARTBEAT_INTERVAL: 30.000IGNORE_SERVER_IDS:REPL_DO_DOMAIN_IDS:REPL_IGNORE_DOMAIN_IDS:1 row in set (0.003 sec)and the default was changed to 100000 (86400 before)
but it is not documented yet.