Implement the tests designed for the rollback to stable operation (see Technical Design document here):
- Create a table and insert some keys and set the stable timestamp with the latest commit timestamp. Perform checkpoint followed by a rollback to stable. The rollback to stable operation shouldn’t abort any updates. It can be verified using the stats.
- Create a table and set the stable timestamp to 1. Insert keys into the table later perform the checkpoint so that data gets populated. Now perform a rollback to stable operation as that should remove all the keys from the table.
- Create a table and insert some keys, later perform multiple updates on those keys and set the stable timestamp. Again perform multiple updates on those keys followed by a checkpoint to let both data and history store get populated. Perform a server crash and recovery to let the rollback to stable operation to let the history store record be replaced in the data page and remove the newer updates.
- Repeat the above tests with WT as in-memory storage engine
- Repeat the above tests when the transaction is prepared
- Test create/drop of a collection/index and ensure that these operations are never rollbacked when rollback to stable operation is done as the DDL operations are not timestamped.
Already complete:
- test_rollback_to_stable01.py Create a table (with small cache size to let the pages to be evicted) and insert some keys. Set the stable timestamp with the latest commit timestamp and then remove all the keys. Perform checkpoint followed by a rollback to stable operation. The rollback to stable should clean up all the remove operations. Followed by select operation should select all the keys.
- test_rollback_to_stable02.py Create a table (with small cache size to let the pages to be evicted) and insert some keys and followed by some updates. Perform a checkpoint to make sure that the history store gets populated. Set the stable timestamp as all the newer updates as invalid. The rollback to stable operation should remove all the newer updates and replace the data page contents with history store updates.
- test_rollback_to_stable03.py Create a table and set the stable timestamp to 1. Insert keys into the table, followed by updates and later perform the checkpoint so that data and history store gets populated. Now perform a rollback to stable operation as that should remove all the keys from both data and history store.
- test_timestamp04.py Create two tables one with the timestamp and others with no timestamp support. Perform inserts and updates on both tables followed by a checkpoint to ensure that both data and history store gets populated. Set the stable timestamp to the last commit timestamp of insert operation and perform a rollback to stable operation. The table without timestamp support should have all the newer updates but the table with timestamp support should have only the inserted data values.
- is duplicated by
-
WT-5428 Recovery test for rollback to stable operation
-
- Closed
-