Bug #115480 | Test innodb.log_first_rec_group failing | ||
---|---|---|---|
Submitted: | 2 Jul 4:26 | Modified: | 8 Jul 7:10 |
Reporter: | Laurynas Biveinis (OCA) | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | MySQL Server: InnoDB storage engine | Severity: | S3 (Non-critical) |
Version: | 8.0.38 | OS: | MacOS (14.5) |
Assigned to: | MySQL Verification Team | CPU Architecture: | ARM |
[2 Jul 4:26]
Laurynas Biveinis
[2 Jul 8:08]
MySQL Verification Team
Hello Laurynas, Thank you for the report and feedback! regards, Umesh
[5 Jul 13:23]
Marcin Babij
Hello Laurynas, Thank you for your report. The amount of 850 bytes in redo generated during the test is surprisingly high. Is there anything unusual in your testing environment and the MTR script command line that you've not shared? We can see a failure when non-standard amount of undo tablespaces is created before the test, for example with --init-file. But standard runs on standard environment on multiple systems work fine. Does it fail always when executed multiple times (e.g. with `--repeat=1000`), and if not, how frequently it fails? At the start of the test around line 16 there is: let $debug_test = 0; Could you try to set it to `1`, repeat it to fail and share the results (they may be available in full in some MTR log file after the failure, as the MTR shares only some last lines of the output in console message). Thanks!
[8 Jul 7:10]
Laurynas Biveinis
The most unusual thing about my environment is macOS (on ARM). The test does not fail under Linux virtualized under macOS on that same ARM. I haven't tried x86_64 either OS yet. --repeat is not necessary, the test fails reliably on the first invocation. The MTR invocation is the simplest possible: ./mtr innodb.log_first_rec_group debug_test=1 output: # # Scenario 1. Test recovery when recovery starts and ends in the same block as checkpoint_lsn. # Pass: 0 # Initialization - create table, resets autoincrement value. # 0. Move to the next log block. include/assert.inc [We failed to create log records that would end at boundary between blocks] State: created trx ending at blocks boundary Start LSN: 20588017 End LSN: 20588556 # 1. Execute tiny mini-transaction in the current block [only pass 0] State: after writing first mtr to the block LSN: 20588663 # 2. Create checkpoint at the current lsn and block further checkpoints State: after checkpoint write LSN: 20588715 Checkpoint LSN: 20588715 # 3. Execute transaction to force non-trivial crash recovery: 103. State: after writing 103 LSN: 20588792 include/assert.inc [All must happen within the single log block (this was required for the bug)] # 5. Crash when trying to insert B. # 6. Recover 103, write new redo record X during recovery and crash just before flushing page with 103 # 7. Start recovery and ensure all is recovered - we must recover 103. # If first_rec_group was pointing to X we would skip 103. # The auto increment value should also be stored properly (with # value of 5 in first pass, 4 in second). SELECT * FROM t; a b 100 1 101 2 102 3 103 4 SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 't'; AUTO_INCREMENT 5 State: after recovery LSN: 20588792 Pass: 1 # Initialization - create table, resets autoincrement value. # 0. Move to the next log block. include/assert.inc [We failed to create log records that would end at boundary between blocks] State: created trx ending at blocks boundary Start LSN: 20655363 End LSN: 20655628 # 1. Execute tiny mini-transaction in the current block [only pass 0] # 2. Create checkpoint at the current lsn and block further checkpoints State: after checkpoint write LSN: 20655680 Checkpoint LSN: 20655680 # 3. Execute transaction to force non-trivial crash recovery: 103. State: after writing 103 LSN: 20656479 include/assert.inc [All must happen within the single log block (this was required for the bug)] ######## Test assertion failed: All must happen within the single log block (this was required for the bug) ######## ...