Details
-
Task
-
Status: Stalled (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
-
None
Description
MDEV-16809 Allow full redo logging for ALTER TABLE
|
MDEV-16791 mariabackup : allow consistent backup, in presence of concurrent DDL,
|
also without --lock-ddl-per-table
|
point to the need to have sufficient corresponding test.
|
MTR based tests could be only used for some basic coverage.
|
Whereas exemplary tests are easy written and recommended to have this way cannot be
|
used as main method for providing sufficient functional coverage.
|
a) Developing sufficient MTR tests for mariabackup with concurrent DDL is quite costly because the amount of relevant DDL is huge.
|
b) Even if a) would be cheap than running these tests frequent like as members of the
|
regression tests would require too much elapsed runtime and resources (assume CPU)
|
Given the fact that we already have some crowd of RQG tests checking roughly all kinds of concurrent DDL it seems to be recommended to do the following with RQG:
|
- the server is under serious load by arbitrary DDL (existing YY grammars)
|
- run parallel in a loop
|
1. Hot backup of data of running server 1
|
2. Prepare the data backed up for restore + restore to other place than server 1
|
3. Start some additional server 2 on that data
|
4. Run check table in server 2
|
5. If no trouble during 4. shutdown of server 2 + destroy his data + run next loop round.
|
If trouble terminate the test.
|
It is not 100% clear if the loop should be implemented as
|
- periodic reporter (management of the server 2 might be complicated)
|
- feature of the RQG runner
|
I think it should be a reporter. There is an old reporter CloneSlaveXtrabackup, possibly it has some code or at least ideas for re-using; but of course the reporter for MariaBackup must be implemented based on the "native" server startup, not MTR-v1 as many old RQG reporters.
Starting additional server inside a reporter is in fact fairly easy, basically you already have the server "structure", you just clone it, change the port/socket and maybe a few other instance-specific values and launch startServer as usual.