maria-developers team mailing list archive

[sujatha <sujatha.sivakumar@xxxxxxxxxxx>]

Hello Sergei,

On 09/04/21 5:03 pm, Sergei Golubchik wrote:
> Hi, Sujatha!
>
> On Apr 09, sujatha wrote:
> > > It looks that CONNECTION_RETRY_COUNT is 86400.
> > > And 86400 is clearly a timeout, not a retry count.
> > Regarding the timeout, actually the above table just displays the user
> > specified connection configuration.
> >
> > In case, user has not provided any value for 'CONNECTION_RETRY_COUNT' it
> > will hold the default value(86400).
> Indeed,
>
>    {"master-retry-count", 0,
>     "The number of tries the slave will make to connect to the master before giving up.",
>     &master_retry_count, &master_retry_count, 0, GET_ULONG,
>     REQUIRED_ARG, 3600*24, 0, 0, 0, 0, 0},
>
> this doesn't make any sense, why would retry *count* be set to the
> number of seconds in a day? It's confusing. Is master retrying every
> second?

Actually there are two variables. When slave fails to establish a 
connection with master

it waits for '60' seconds. It attempts once again. This interval can be 
configured by

following following variable.

*|MASTER_CONNECT_RETRY|*

    The |MASTER_CONNECT_RETRY|option for |CHANGE MASTER|defines how 
many seconds that the replica will wait between connection retries. The 
default is |60|.
    The number of connection attempts is limited by the 
master_retry_count 
<https://mariadb.com/kb/en/mysqld-options/#-master-retry-count>option.
||


The total number of retries by slave is controlled by following variable.

*|--master-retry-count|*

 * Commandline:|--master-retry-count=#|
 * Description:Number of times a slave will attempt to connect to a
   master before giving up. The retry interval is determined by the
   MASTER_CONNECT_RETRY option for the CHANGE MASTER statement. A value
   of 0 means the slave will not stop attempting to reconnect.
   Reconnects are triggered when a slave has timed out. See
   slave_net_timeout
   <https://mariadb.com/kb/en/replication-and-binary-log-server-system-variables/#slave_net_timeout>.

 * Default Value:|86400|

May be I can configure some values instead of leaving them as defaults, 
and record them

in my test.

For example:

STOP SLAVE; CHANGE MASTER TO MASTER_CONNECT_RETRY=20; START SLAVE; 
[mariadb] ... master_retry_count=6000

> If not - would you mind changing it to 80000? or 100000? Or something
> else, whatever you like.
>
> > > > diff --git a/mysql-test/suite/rpl/include/rpl_deadlock.test b/mysql-test/suite/rpl/include/rpl_deadlock.test
> > > > index e9191d5fcd8..bccbe044a36 100644
> > > > --- a/mysql-test/suite/rpl/include/rpl_deadlock.test
> > > > +++ b/mysql-test/suite/rpl/include/rpl_deadlock.test
> > > > @@ -59,6 +59,16 @@ let $status_var_comparsion= >;
> > > >    connection slave;
> > > >    SELECT COUNT(*) FROM t2;
> > > >    COMMIT;
> > > > +
> > > > +--echo
> > > > +--echo # Test that the performance schema coulumn shows > 0 values.
> > > > +--echo
> > > > +
> > > > +--let $assert_text= current number of retries should be more than the value saved before deadlock.
> > > > +--let $assert_cond= [SELECT COUNT_TRANSACTIONS_RETRIES FROM performance_schema.replication_applier_status, COUNT_TRANSACTIONS_RETRIES, 1] > "$slave_retried_transactions"
> > > > +--source include/assert.inc
> > > what's wrong with simple
> > >
> > >     SELECT COUNT_TRANSACTIONS_RETRIES > $slave_retried_transactions FROM performance_schema.replication_applier_status
> > >
> > > ?
> > 'asserts' are preferred by upstream team and they find asserts to be
> > more readable rather than comparing SELECT OUTPUTS from result files.
> I know. I always disliked assert.inc as mysqltest is perfectly capable
> of comparing the expected result with an actual one and failing the test
> on any difference. In fact, it's what mysqltest was written for in the
> first place. assert.inc makes the result look prettier at the expence of
> making the debugging much more difficult. Which, in my opinion, is a
> wrong tradeoff, because nobody cares how pretty the result file is as
> long as the test passes. But when the test fails, it's debugging that
> matters.
>
> But as we don't have a coding style that says "don't use assert.inc",
> it's ultimately up to you.


ACK.

> Regards,
> Sergei
> VP of MariaDB Server Engineering
> and security@xxxxxxxxxxx

Thank you.

S.Sujatha