2. Run "pseudo replication" (== any SQL gets sent to two servers) based on conf/mariadb/concurrency.yy (*)
- only one session runs the DDL/DML mix and the SQL should avoid statements which are unsafe in statement based replication
because otherwise "pseudo replication" is known to break
- probably costly modification in RQG code: When sending a DDL creating a key to the second server convert ASC to DESC and DESC to ASC
or
probably less costly: First server is 10.8 with MDEV-26938 , second server is 10.8 without MDEV-26938
- filter out any SQL containing LIMIT and do not execute that
- at test end compare the content of the tables of both servers
Variant: Compare the result sets of SELECTs executed on the first and the second server
(*) Alternative: Develop some new grammar or a simplified derivate of conf/mariadb/concurrency.yy
Matthias Leich
added a comment -
Some raw ideas for RQG based testing:
It looks as if the RQG grammar conf/mariadb/concurrency.yy is some good candidate for RQG testing.
The DDL fiddles with ASC and DESC keys. Probably even in case of multi column keys.
1. Plain crash testing with concurrent sessions running some DDL/DML mix based on
--grammar=conf/mariadb/concurrency.yy --gendata=conf/mariadb/concurrency.zz --gendata_sql=conf/mariadb/concurrency.sql
2. Run "pseudo replication" (== any SQL gets sent to two servers) based on conf/mariadb/concurrency.yy (*)
- only one session runs the DDL/DML mix and the SQL should avoid statements which are unsafe in statement based replication
because otherwise "pseudo replication" is known to break
- probably costly modification in RQG code: When sending a DDL creating a key to the second server convert ASC to DESC and DESC to ASC
or
probably less costly: First server is 10.8 with MDEV-26938 , second server is 10.8 without MDEV-26938
- filter out any SQL containing LIMIT and do not execute that
- at test end compare the content of the tables of both servers
Variant: Compare the result sets of SELECTs executed on the first and the second server
(*) Alternative: Develop some new grammar or a simplified derivate of conf/mariadb/concurrency.yy
Results of ~ 15000 RQG tests using conf/mariadb/concurrency.yy and different setups (see 1. in the comment above):
In general low fraction of failing tests.
The failures observed occur on actual 10.6 too.
concurrency.yy has the advantage of using DESC indexes etc. at all.
But that does not guarantee to give some exceptional coverage of that feature.
The correctness of result sets could not be checked with that setup.
Test campaign with
- a derivate of the grammar table_stress_innodb.yy
ASC or DESC added to columns being part of some KEY
- some test setup derived from table_stress.cc
pluto:/data/rqg/results/1638191819
There are several new error patterns. Mostly in connection with Mariabackup.
I am now running the same campaign against actual 10.8.
Matthias Leich
added a comment - - edited
Results of ~ 15000 RQG tests using conf/mariadb/concurrency.yy and different setups (see 1. in the comment above):
In general low fraction of failing tests.
The failures observed occur on actual 10.6 too.
concurrency.yy has the advantage of using DESC indexes etc. at all.
But that does not guarantee to give some exceptional coverage of that feature.
The correctness of result sets could not be checked with that setup.
Test campaign with
- a derivate of the grammar table_stress_innodb.yy
ASC or DESC added to columns being part of some KEY
- some test setup derived from table_stress.cc
pluto:/data/rqg/results/1638191819
There are several new error patterns. Mostly in connection with Mariabackup.
I am now running the same campaign against actual 10.8.
The final preview branch in testing is preview-10.8-MDEV-13756-desc-indexes, so further testing will be done under MDEV-13756, while this one will remain "In testing" until MDEV-13756 with all the included parts is either accepted or rejected.
Elena Stepanova
added a comment - - edited The final preview branch in testing is preview-10.8- MDEV-13756 -desc-indexes, so further testing will be done under MDEV-13756 , while this one will remain "In testing" until MDEV-13756 with all the included parts is either accepted or rejected.
Task
Critical
MDEV-29992 Index corruption with multi-part key and nopad collation
Some raw ideas for RQG based testing:It looks as if the RQG grammar conf/mariadb/concurrency.yy is some good candidate for RQG testing.The DDL fiddles with ASC and DESC keys. Probably even in case of multi column keys.1. Plain crash testing with concurrent sessions running some DDL/DML mix based on--grammar=conf/mariadb/concurrency.yy --gendata=conf/mariadb/concurrency.zz --gendata_sql=conf/mariadb/concurrency.sql2. Run "pseudo replication" (== any SQL gets sent to two servers) based on conf/mariadb/concurrency.yy (*)- only one session runs the DDL/DML mix and the SQL should avoid statements which are unsafe in statement based replicationbecause otherwise "pseudo replication" is known to break- probably costly modification in RQG code: When sending a DDL creating a key to the second server convert ASC to DESC and DESC to ASCorprobably less costly: First server is 10.8 with MDEV-26938 , second server is 10.8 without MDEV-26938- filter out any SQL containing LIMIT and do not execute that- at test end compare the content of the tables of both serversVariant: Compare the result sets of SELECTs executed on the first and the second server(*) Alternative: Develop some new grammar or a simplified derivate of conf/mariadb/concurrency.yy