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? 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. Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org