2024-03-21 09:30:47 -04:00
|
|
|
# SPDX-FileCopyrightText: 2024 Redict Contributors
|
|
|
|
# SPDX-FileCopyrightText: 2024 Salvatore Sanfilippo <antirez at gmail dot com>
|
|
|
|
#
|
|
|
|
# SPDX-License-Identifier: BSD-3-Clause
|
2024-03-21 15:11:44 -04:00
|
|
|
# SPDX-License-Identifier: LGPL-3.0-only
|
2024-03-21 09:30:47 -04:00
|
|
|
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
source tests/support/aofmanifest.tcl
|
|
|
|
set defaults { appendonly {yes} appendfilename {appendonly.aof} appenddirname {appendonlydir} auto-aof-rewrite-percentage {0}}
|
2010-05-19 08:33:39 -04:00
|
|
|
set server_path [tmpdir server.aof]
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
set aof_dirname "appendonlydir"
|
|
|
|
set aof_basename "appendonly.aof"
|
|
|
|
set aof_dirpath "$server_path/$aof_dirname"
|
Adapt redis-check-aof tool for Multi Part Aof (#10061)
Modifications of this PR:
1. Support the verification of `Multi Part AOF`, while still maintaining support for the
old-style `AOF/RDB-preamble`. `redis-check-aof` will automatically choose which
mode to use according to the incoming file format.
`Usage: redis-check-aof [--fix|--truncate-to-timestamp $timestamp] <AOF/manifest>`
2. Refactor part of the code to make it easier to understand
3. Currently only supports truncate (`--fix` or `--truncate-to-timestamp`) the last AOF
file (may be `BASE` or `INCR`)
The reasons for 3 above:
- for `--fix`: Only the last AOF may be truncated, this is guaranteed by redis
- for `--truncate-to-timestamp`: Normally, we only have `BASE` + `INCR` files
at most, and `BASE` cannot be truncated(It only contains a timestamp annotation
at the beginning of the file), so only `INCR` can be truncated. If we have a
`BASE+INCR1+INCR2` file (meaning we have an interrupted AOFRW), Only `INCR2`
files can be truncated at this time. If we still insist on truncate `INCR1`, we need to
manually delete `INCR2` and update the manifest file, then re-run `redis-check-aof`
- If we want to support truncate any file, we need to add very complicated code to support
the atomic modification of multiple file deletion and update manifest, I think this is unnecessary
2022-02-17 01:13:28 -05:00
|
|
|
set aof_base_file "$server_path/$aof_dirname/${aof_basename}.1$::base_aof_sufix$::aof_format_suffix"
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
set aof_file "$server_path/$aof_dirname/${aof_basename}.1$::incr_aof_sufix$::aof_format_suffix"
|
|
|
|
set aof_manifest_file "$server_path/$aof_dirname/$aof_basename$::manifest_suffix"
|
2010-05-19 08:33:39 -04:00
|
|
|
|
2021-06-09 08:13:24 -04:00
|
|
|
tags {"aof external:skip"} {
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
# Server can start when aof-load-truncated is set to yes and AOF
|
|
|
|
# is truncated, with an incomplete MULTI block.
|
|
|
|
create_aof $aof_dirpath $aof_file {
|
2014-09-08 04:22:23 -04:00
|
|
|
append_to_aof [formatCommand set foo hello]
|
|
|
|
append_to_aof [formatCommand multi]
|
|
|
|
append_to_aof [formatCommand set bar world]
|
|
|
|
}
|
|
|
|
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
create_aof_manifest $aof_dirpath $aof_manifest_file {
|
|
|
|
append_to_manifest "file appendonly.aof.1.incr.aof seq 1 type i\n"
|
|
|
|
}
|
|
|
|
|
2014-09-08 04:22:23 -04:00
|
|
|
start_server_aof [list dir $server_path aof-load-truncated yes] {
|
|
|
|
test "Unfinished MULTI: Server should start if load-truncated is yes" {
|
2023-10-02 01:20:53 -04:00
|
|
|
assert_equal 1 [is_alive [srv pid]]
|
2014-09-08 04:22:23 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
## Should also start with truncated AOF without incomplete MULTI block.
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
create_aof $aof_dirpath $aof_file {
|
2014-09-16 05:05:12 -04:00
|
|
|
append_to_aof [formatCommand incr foo]
|
|
|
|
append_to_aof [formatCommand incr foo]
|
|
|
|
append_to_aof [formatCommand incr foo]
|
|
|
|
append_to_aof [formatCommand incr foo]
|
|
|
|
append_to_aof [formatCommand incr foo]
|
|
|
|
append_to_aof [string range [formatCommand incr foo] 0 end-1]
|
2014-09-08 04:22:23 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
start_server_aof [list dir $server_path aof-load-truncated yes] {
|
|
|
|
test "Short read: Server should start if load-truncated is yes" {
|
2023-10-02 01:20:53 -04:00
|
|
|
assert_equal 1 [is_alive [srv pid]]
|
2014-09-08 04:22:23 -04:00
|
|
|
}
|
2014-09-16 05:05:12 -04:00
|
|
|
|
|
|
|
test "Truncated AOF loaded: we expect foo to be equal to 5" {
|
2024-03-21 05:56:59 -04:00
|
|
|
set client [redict [srv host] [srv port] 0 $::tls]
|
2020-08-31 04:20:02 -04:00
|
|
|
wait_done_loading $client
|
2014-09-16 05:05:12 -04:00
|
|
|
assert {[$client get foo] eq "5"}
|
|
|
|
}
|
|
|
|
|
|
|
|
test "Append a new command after loading an incomplete AOF" {
|
|
|
|
$client incr foo
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
# Now the AOF file is expected to be correct
|
|
|
|
start_server_aof [list dir $server_path aof-load-truncated yes] {
|
|
|
|
test "Short read + command: Server should start" {
|
2023-10-02 01:20:53 -04:00
|
|
|
assert_equal 1 [is_alive [srv pid]]
|
2014-09-16 05:05:12 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
test "Truncated AOF loaded: we expect foo to be equal to 6 now" {
|
2024-03-21 05:56:59 -04:00
|
|
|
set client [redict [srv host] [srv port] 0 $::tls]
|
2020-08-31 04:20:02 -04:00
|
|
|
wait_done_loading $client
|
2014-09-16 05:05:12 -04:00
|
|
|
assert {[$client get foo] eq "6"}
|
|
|
|
}
|
2014-09-08 04:22:23 -04:00
|
|
|
}
|
|
|
|
|
2014-09-05 04:27:11 -04:00
|
|
|
## Test that the server exits when the AOF contains a format error
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
create_aof $aof_dirpath $aof_file {
|
2014-09-05 04:27:11 -04:00
|
|
|
append_to_aof [formatCommand set foo hello]
|
|
|
|
append_to_aof "!!!"
|
|
|
|
append_to_aof [formatCommand set foo hello]
|
|
|
|
}
|
|
|
|
|
2023-10-02 01:20:53 -04:00
|
|
|
start_server_aof_ex [list dir $server_path aof-load-truncated yes] [list wait_ready false] {
|
2014-09-05 04:27:11 -04:00
|
|
|
test "Bad format: Server should have logged an error" {
|
2023-10-02 01:20:53 -04:00
|
|
|
wait_for_log_messages 0 {"*Bad file format reading the append only file*"} 0 10 1000
|
2014-09-05 04:27:11 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-06-02 17:14:55 -04:00
|
|
|
## Test the server doesn't start when the AOF contains an unfinished MULTI
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
create_aof $aof_dirpath $aof_file {
|
2010-06-02 17:14:55 -04:00
|
|
|
append_to_aof [formatCommand set foo hello]
|
|
|
|
append_to_aof [formatCommand multi]
|
|
|
|
append_to_aof [formatCommand set bar world]
|
|
|
|
}
|
2010-05-19 08:33:39 -04:00
|
|
|
|
2023-10-02 01:20:53 -04:00
|
|
|
start_server_aof_ex [list dir $server_path aof-load-truncated no] [list wait_ready false] {
|
2011-04-22 03:37:28 -04:00
|
|
|
test "Unfinished MULTI: Server should have logged an error" {
|
2023-10-02 01:20:53 -04:00
|
|
|
wait_for_log_messages 0 {"*Unexpected end of file reading the append only file*"} 0 10 1000
|
2011-04-22 03:37:28 -04:00
|
|
|
}
|
2010-06-02 17:14:55 -04:00
|
|
|
}
|
2010-05-19 08:33:39 -04:00
|
|
|
|
2010-06-02 17:14:55 -04:00
|
|
|
## Test that the server exits when the AOF contains a short read
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
create_aof $aof_dirpath $aof_file {
|
2010-06-02 17:14:55 -04:00
|
|
|
append_to_aof [formatCommand set foo hello]
|
|
|
|
append_to_aof [string range [formatCommand set bar world] 0 end-1]
|
|
|
|
}
|
2010-05-19 08:33:39 -04:00
|
|
|
|
2023-10-02 01:20:53 -04:00
|
|
|
start_server_aof_ex [list dir $server_path aof-load-truncated no] [list wait_ready false] {
|
2011-04-22 03:37:28 -04:00
|
|
|
test "Short read: Server should have logged an error" {
|
2023-10-02 01:20:53 -04:00
|
|
|
wait_for_log_messages 0 {"*Unexpected end of file reading the append only file*"} 0 10 1000
|
2011-04-22 03:37:28 -04:00
|
|
|
}
|
2010-06-02 17:14:55 -04:00
|
|
|
}
|
2010-05-19 08:33:39 -04:00
|
|
|
|
2024-03-21 05:56:59 -04:00
|
|
|
## Test that redict-check-aof indeed sees this AOF is not valid
|
2011-04-22 03:37:28 -04:00
|
|
|
test "Short read: Utility should confirm the AOF is not valid" {
|
2010-06-02 17:14:55 -04:00
|
|
|
catch {
|
2024-03-21 05:56:59 -04:00
|
|
|
exec src/redict-check-aof $aof_manifest_file
|
2011-04-22 03:37:28 -04:00
|
|
|
} result
|
|
|
|
assert_match "*not valid*" $result
|
|
|
|
}
|
2010-05-19 08:33:39 -04:00
|
|
|
|
2021-04-20 14:51:24 -04:00
|
|
|
test "Short read: Utility should show the abnormal line num in AOF" {
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
create_aof $aof_dirpath $aof_file {
|
2021-04-20 14:51:24 -04:00
|
|
|
append_to_aof [formatCommand set foo hello]
|
|
|
|
append_to_aof "!!!"
|
|
|
|
}
|
|
|
|
|
|
|
|
catch {
|
2024-03-21 05:56:59 -04:00
|
|
|
exec src/redict-check-aof $aof_manifest_file
|
2021-04-20 14:51:24 -04:00
|
|
|
} result
|
|
|
|
assert_match "*ok_up_to_line=8*" $result
|
|
|
|
}
|
|
|
|
|
2011-04-22 03:37:28 -04:00
|
|
|
test "Short read: Utility should be able to fix the AOF" {
|
2024-03-21 05:56:59 -04:00
|
|
|
set result [exec src/redict-check-aof --fix $aof_manifest_file << "y\n"]
|
2011-04-22 03:37:28 -04:00
|
|
|
assert_match "*Successfully truncated AOF*" $result
|
|
|
|
}
|
2010-05-19 08:33:39 -04:00
|
|
|
|
2010-06-02 17:14:55 -04:00
|
|
|
## Test that the server can be started using the truncated AOF
|
2014-09-08 03:31:00 -04:00
|
|
|
start_server_aof [list dir $server_path aof-load-truncated no] {
|
2011-04-22 03:37:28 -04:00
|
|
|
test "Fixed AOF: Server should have been started" {
|
2023-10-02 01:20:53 -04:00
|
|
|
assert_equal 1 [is_alive [srv pid]]
|
2011-04-22 03:37:28 -04:00
|
|
|
}
|
2010-05-19 08:33:39 -04:00
|
|
|
|
2014-07-31 14:33:50 -04:00
|
|
|
test "Fixed AOF: Keyspace should contain values that were parseable" {
|
2024-03-21 05:56:59 -04:00
|
|
|
set client [redict [srv host] [srv port] 0 $::tls]
|
2020-08-31 04:20:02 -04:00
|
|
|
wait_done_loading $client
|
2011-04-22 03:37:28 -04:00
|
|
|
assert_equal "hello" [$client get foo]
|
|
|
|
assert_equal "" [$client get bar]
|
|
|
|
}
|
2010-06-02 17:14:55 -04:00
|
|
|
}
|
2011-04-22 03:44:06 -04:00
|
|
|
|
2013-06-19 12:31:33 -04:00
|
|
|
## Test that SPOP (that modifies the client's argc/argv) is correctly free'd
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
create_aof $aof_dirpath $aof_file {
|
2011-04-22 03:44:06 -04:00
|
|
|
append_to_aof [formatCommand sadd set foo]
|
|
|
|
append_to_aof [formatCommand sadd set bar]
|
|
|
|
append_to_aof [formatCommand spop set]
|
|
|
|
}
|
|
|
|
|
2014-09-08 03:31:00 -04:00
|
|
|
start_server_aof [list dir $server_path aof-load-truncated no] {
|
2011-04-22 03:44:06 -04:00
|
|
|
test "AOF+SPOP: Server should have been started" {
|
2023-10-02 01:20:53 -04:00
|
|
|
assert_equal 1 [is_alive [srv pid]]
|
2011-04-22 03:44:06 -04:00
|
|
|
}
|
|
|
|
|
2014-03-11 10:38:55 -04:00
|
|
|
test "AOF+SPOP: Set should have 1 member" {
|
2024-03-21 05:56:59 -04:00
|
|
|
set client [redict [srv host] [srv port] 0 $::tls]
|
2020-08-31 04:20:02 -04:00
|
|
|
wait_done_loading $client
|
2014-03-11 10:38:55 -04:00
|
|
|
assert_equal 1 [$client scard set]
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-02-09 17:57:52 -05:00
|
|
|
## Uses the alsoPropagate() API.
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
create_aof $aof_dirpath $aof_file {
|
2014-03-11 10:38:55 -04:00
|
|
|
append_to_aof [formatCommand sadd set foo]
|
|
|
|
append_to_aof [formatCommand sadd set bar]
|
|
|
|
append_to_aof [formatCommand sadd set gah]
|
|
|
|
append_to_aof [formatCommand spop set 2]
|
|
|
|
}
|
|
|
|
|
|
|
|
start_server_aof [list dir $server_path] {
|
|
|
|
test "AOF+SPOP: Server should have been started" {
|
2023-10-02 01:20:53 -04:00
|
|
|
assert_equal 1 [is_alive [srv pid]]
|
2014-03-11 10:38:55 -04:00
|
|
|
}
|
|
|
|
|
2011-04-22 03:44:06 -04:00
|
|
|
test "AOF+SPOP: Set should have 1 member" {
|
2024-03-21 05:56:59 -04:00
|
|
|
set client [redict [srv host] [srv port] 0 $::tls]
|
2020-08-31 04:20:02 -04:00
|
|
|
wait_done_loading $client
|
2011-04-22 03:44:06 -04:00
|
|
|
assert_equal 1 [$client scard set]
|
|
|
|
}
|
|
|
|
}
|
2011-07-03 05:04:55 -04:00
|
|
|
|
2021-05-30 02:20:32 -04:00
|
|
|
## Test that PEXPIREAT is loaded correctly
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
create_aof $aof_dirpath $aof_file {
|
2011-07-03 05:04:55 -04:00
|
|
|
append_to_aof [formatCommand rpush list foo]
|
2021-05-30 02:20:32 -04:00
|
|
|
append_to_aof [formatCommand pexpireat list 1000]
|
2011-07-03 05:04:55 -04:00
|
|
|
append_to_aof [formatCommand rpush list bar]
|
|
|
|
}
|
|
|
|
|
2014-09-08 03:31:00 -04:00
|
|
|
start_server_aof [list dir $server_path aof-load-truncated no] {
|
2011-07-03 05:04:55 -04:00
|
|
|
test "AOF+EXPIRE: Server should have been started" {
|
2023-10-02 01:20:53 -04:00
|
|
|
assert_equal 1 [is_alive [srv pid]]
|
2011-07-03 05:04:55 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
test "AOF+EXPIRE: List should be empty" {
|
2024-03-21 05:56:59 -04:00
|
|
|
set client [redict [srv host] [srv port] 0 $::tls]
|
2020-08-31 04:20:02 -04:00
|
|
|
wait_done_loading $client
|
2011-07-03 05:04:55 -04:00
|
|
|
assert_equal 0 [$client llen list]
|
|
|
|
}
|
|
|
|
}
|
2011-07-08 06:20:30 -04:00
|
|
|
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
start_server {overrides {appendonly {yes}}} {
|
2024-03-21 05:56:59 -04:00
|
|
|
test {Redict should not try to convert DEL into EXPIREAT for EXPIRE -1} {
|
2011-07-08 06:20:30 -04:00
|
|
|
r set x 10
|
|
|
|
r expire x -1
|
|
|
|
}
|
|
|
|
}
|
2019-08-19 05:18:25 -04:00
|
|
|
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
start_server {overrides {appendonly {yes} appendfsync always}} {
|
2019-08-19 05:18:25 -04:00
|
|
|
test {AOF fsync always barrier issue} {
|
2024-03-21 05:56:59 -04:00
|
|
|
set rd [redict_deferring_client]
|
2019-08-19 05:18:25 -04:00
|
|
|
# Set a sleep when aof is flushed, so that we have a chance to look
|
|
|
|
# at the aof size and detect if the response of an incr command
|
|
|
|
# arrives before the data was written (and hopefully fsynced)
|
|
|
|
# We create a big reply, which will hopefully not have room in the
|
|
|
|
# socket buffers, and will install a write handler, then we sleep
|
|
|
|
# a big and issue the incr command, hoping that the last portion of
|
|
|
|
# the output buffer write, and the processing of the incr will happen
|
|
|
|
# in the same event loop cycle.
|
|
|
|
# Since the socket buffers and timing are unpredictable, we fuzz this
|
|
|
|
# test with slightly different sizes and sleeps a few times.
|
|
|
|
for {set i 0} {$i < 10} {incr i} {
|
|
|
|
r debug aof-flush-sleep 0
|
|
|
|
r del x
|
|
|
|
r setrange x [expr {int(rand()*5000000)+10000000}] x
|
|
|
|
r debug aof-flush-sleep 500000
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
set aof [get_last_incr_aof_path r]
|
2019-08-19 05:18:25 -04:00
|
|
|
set size1 [file size $aof]
|
|
|
|
$rd get x
|
|
|
|
after [expr {int(rand()*30)}]
|
|
|
|
$rd incr new_value
|
|
|
|
$rd read
|
|
|
|
$rd read
|
|
|
|
set size2 [file size $aof]
|
|
|
|
assert {$size1 != $size2}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2021-01-27 12:47:26 -05:00
|
|
|
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
start_server {overrides {appendonly {yes}}} {
|
2021-01-27 12:47:26 -05:00
|
|
|
test {GETEX should not append to AOF} {
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
set aof [get_last_incr_aof_path r]
|
2021-01-27 12:47:26 -05:00
|
|
|
r set foo bar
|
|
|
|
set before [file size $aof]
|
|
|
|
r getex foo
|
|
|
|
set after [file size $aof]
|
|
|
|
assert_equal $before $after
|
|
|
|
}
|
|
|
|
}
|
2021-06-14 03:38:08 -04:00
|
|
|
|
|
|
|
## Test that the server exits when the AOF contains a unknown command
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
create_aof $aof_dirpath $aof_file {
|
2021-06-14 03:38:08 -04:00
|
|
|
append_to_aof [formatCommand set foo hello]
|
|
|
|
append_to_aof [formatCommand bla foo hello]
|
|
|
|
append_to_aof [formatCommand set foo hello]
|
|
|
|
}
|
|
|
|
|
2023-10-02 01:20:53 -04:00
|
|
|
start_server_aof_ex [list dir $server_path aof-load-truncated yes] [list wait_ready false] {
|
2021-06-14 03:38:08 -04:00
|
|
|
test "Unknown command: Server should have logged an error" {
|
2023-10-02 01:20:53 -04:00
|
|
|
wait_for_log_messages 0 {"*Unknown command 'bla' reading the append only file*"} 0 10 1000
|
2021-06-14 03:38:08 -04:00
|
|
|
}
|
|
|
|
}
|
2021-09-09 05:02:33 -04:00
|
|
|
|
|
|
|
# Test that LMPOP/BLMPOP work fine with AOF.
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
create_aof $aof_dirpath $aof_file {
|
2021-09-09 05:02:33 -04:00
|
|
|
append_to_aof [formatCommand lpush mylist a b c]
|
|
|
|
append_to_aof [formatCommand rpush mylist2 1 2 3]
|
|
|
|
append_to_aof [formatCommand lpush mylist3 a b c d e]
|
|
|
|
}
|
|
|
|
|
|
|
|
start_server_aof [list dir $server_path aof-load-truncated no] {
|
|
|
|
test "AOF+LMPOP/BLMPOP: pop elements from the list" {
|
2024-03-21 05:56:59 -04:00
|
|
|
set client [redict [srv host] [srv port] 0 $::tls]
|
|
|
|
set client2 [redict [srv host] [srv port] 1 $::tls]
|
2021-09-09 05:02:33 -04:00
|
|
|
wait_done_loading $client
|
|
|
|
|
|
|
|
# Pop all elements from mylist, should be blmpop delete mylist.
|
|
|
|
$client lmpop 1 mylist left count 1
|
|
|
|
$client blmpop 0 1 mylist left count 10
|
|
|
|
|
|
|
|
# Pop all elements from mylist2, should be lmpop delete mylist2.
|
|
|
|
$client blmpop 0 2 mylist mylist2 right count 10
|
|
|
|
$client lmpop 2 mylist mylist2 right count 2
|
|
|
|
|
|
|
|
# Blocking path, be blocked and then released.
|
|
|
|
$client2 blmpop 0 2 mylist mylist2 left count 2
|
|
|
|
after 100
|
|
|
|
$client lpush mylist2 a b c
|
|
|
|
|
|
|
|
# Pop up the last element in mylist2
|
|
|
|
$client blmpop 0 3 mylist mylist2 mylist3 left count 1
|
|
|
|
|
|
|
|
# Leave two elements in mylist3.
|
|
|
|
$client blmpop 0 3 mylist mylist2 mylist3 right count 3
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
start_server_aof [list dir $server_path aof-load-truncated no] {
|
|
|
|
test "AOF+LMPOP/BLMPOP: after pop elements from the list" {
|
2024-03-21 05:56:59 -04:00
|
|
|
set client [redict [srv host] [srv port] 0 $::tls]
|
2021-09-09 05:02:33 -04:00
|
|
|
wait_done_loading $client
|
|
|
|
|
|
|
|
# mylist and mylist2 no longer exist.
|
|
|
|
assert_equal 0 [$client exists mylist mylist2]
|
|
|
|
|
|
|
|
# Length of mylist3 is two.
|
|
|
|
assert_equal 2 [$client llen mylist3]
|
|
|
|
}
|
|
|
|
}
|
2021-09-23 01:34:40 -04:00
|
|
|
|
|
|
|
# Test that ZMPOP/BZMPOP work fine with AOF.
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
create_aof $aof_dirpath $aof_file {
|
2021-09-23 01:34:40 -04:00
|
|
|
append_to_aof [formatCommand zadd myzset 1 one 2 two 3 three]
|
|
|
|
append_to_aof [formatCommand zadd myzset2 4 four 5 five 6 six]
|
|
|
|
append_to_aof [formatCommand zadd myzset3 1 one 2 two 3 three 4 four 5 five]
|
|
|
|
}
|
|
|
|
|
|
|
|
start_server_aof [list dir $server_path aof-load-truncated no] {
|
|
|
|
test "AOF+ZMPOP/BZMPOP: pop elements from the zset" {
|
2024-03-21 05:56:59 -04:00
|
|
|
set client [redict [srv host] [srv port] 0 $::tls]
|
|
|
|
set client2 [redict [srv host] [srv port] 1 $::tls]
|
2021-09-23 01:34:40 -04:00
|
|
|
wait_done_loading $client
|
|
|
|
|
|
|
|
# Pop all elements from myzset, should be bzmpop delete myzset.
|
|
|
|
$client zmpop 1 myzset min count 1
|
|
|
|
$client bzmpop 0 1 myzset min count 10
|
|
|
|
|
|
|
|
# Pop all elements from myzset2, should be zmpop delete myzset2.
|
|
|
|
$client bzmpop 0 2 myzset myzset2 max count 10
|
|
|
|
$client zmpop 2 myzset myzset2 max count 2
|
|
|
|
|
|
|
|
# Blocking path, be blocked and then released.
|
|
|
|
$client2 bzmpop 0 2 myzset myzset2 min count 2
|
|
|
|
after 100
|
|
|
|
$client zadd myzset2 1 one 2 two 3 three
|
|
|
|
|
|
|
|
# Pop up the last element in myzset2
|
|
|
|
$client bzmpop 0 3 myzset myzset2 myzset3 min count 1
|
|
|
|
|
|
|
|
# Leave two elements in myzset3.
|
|
|
|
$client bzmpop 0 3 myzset myzset2 myzset3 max count 3
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
start_server_aof [list dir $server_path aof-load-truncated no] {
|
|
|
|
test "AOF+ZMPOP/BZMPOP: after pop elements from the zset" {
|
2024-03-21 05:56:59 -04:00
|
|
|
set client [redict [srv host] [srv port] 0 $::tls]
|
2021-09-23 01:34:40 -04:00
|
|
|
wait_done_loading $client
|
|
|
|
|
|
|
|
# myzset and myzset2 no longer exist.
|
|
|
|
assert_equal 0 [$client exists myzset myzset2]
|
|
|
|
|
|
|
|
# Length of myzset3 is two.
|
|
|
|
assert_equal 2 [$client zcard myzset3]
|
|
|
|
}
|
|
|
|
}
|
2021-10-25 06:08:34 -04:00
|
|
|
|
|
|
|
test {Generate timestamp annotations in AOF} {
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
start_server {overrides {appendonly {yes}}} {
|
2021-10-25 06:08:34 -04:00
|
|
|
r config set aof-timestamp-enabled yes
|
|
|
|
r config set aof-use-rdb-preamble no
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
set aof [get_last_incr_aof_path r]
|
2021-10-25 06:08:34 -04:00
|
|
|
|
|
|
|
r set foo bar
|
|
|
|
assert_match "#TS:*" [exec head -n 1 $aof]
|
|
|
|
|
|
|
|
r bgrewriteaof
|
|
|
|
waitForBgrewriteaof r
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
|
|
|
|
set aof [get_base_aof_path r]
|
2021-10-25 06:08:34 -04:00
|
|
|
assert_match "#TS:*" [exec head -n 1 $aof]
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-03-21 05:56:59 -04:00
|
|
|
# redict could load AOF which has timestamp annotations inside
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
create_aof $aof_dirpath $aof_file {
|
2021-10-25 06:08:34 -04:00
|
|
|
append_to_aof "#TS:1628217470\r\n"
|
|
|
|
append_to_aof [formatCommand set foo1 bar1]
|
|
|
|
append_to_aof "#TS:1628217471\r\n"
|
|
|
|
append_to_aof [formatCommand set foo2 bar2]
|
|
|
|
append_to_aof "#TS:1628217472\r\n"
|
|
|
|
append_to_aof "#TS:1628217473\r\n"
|
|
|
|
append_to_aof [formatCommand set foo3 bar3]
|
|
|
|
append_to_aof "#TS:1628217474\r\n"
|
|
|
|
}
|
|
|
|
start_server_aof [list dir $server_path] {
|
|
|
|
test {Successfully load AOF which has timestamp annotations inside} {
|
2024-03-21 05:56:59 -04:00
|
|
|
set c [redict [srv host] [srv port] 0 $::tls]
|
2021-10-26 07:08:09 -04:00
|
|
|
wait_done_loading $c
|
2021-10-25 06:08:34 -04:00
|
|
|
assert_equal "bar1" [$c get foo1]
|
|
|
|
assert_equal "bar2" [$c get foo2]
|
|
|
|
assert_equal "bar3" [$c get foo3]
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
test {Truncate AOF to specific timestamp} {
|
|
|
|
# truncate to timestamp 1628217473
|
2024-03-21 05:56:59 -04:00
|
|
|
exec src/redict-check-aof --truncate-to-timestamp 1628217473 $aof_manifest_file
|
2021-10-25 06:08:34 -04:00
|
|
|
start_server_aof [list dir $server_path] {
|
2024-03-21 05:56:59 -04:00
|
|
|
set c [redict [srv host] [srv port] 0 $::tls]
|
2021-10-26 07:08:09 -04:00
|
|
|
wait_done_loading $c
|
2021-10-25 06:08:34 -04:00
|
|
|
assert_equal "bar1" [$c get foo1]
|
|
|
|
assert_equal "bar2" [$c get foo2]
|
|
|
|
assert_equal "bar3" [$c get foo3]
|
|
|
|
}
|
|
|
|
|
|
|
|
# truncate to timestamp 1628217471
|
2024-03-21 05:56:59 -04:00
|
|
|
exec src/redict-check-aof --truncate-to-timestamp 1628217471 $aof_manifest_file
|
2021-10-25 06:08:34 -04:00
|
|
|
start_server_aof [list dir $server_path] {
|
2024-03-21 05:56:59 -04:00
|
|
|
set c [redict [srv host] [srv port] 0 $::tls]
|
2021-10-26 07:08:09 -04:00
|
|
|
wait_done_loading $c
|
2021-10-25 06:08:34 -04:00
|
|
|
assert_equal "bar1" [$c get foo1]
|
|
|
|
assert_equal "bar2" [$c get foo2]
|
|
|
|
assert_equal "" [$c get foo3]
|
|
|
|
}
|
|
|
|
|
|
|
|
# truncate to timestamp 1628217470
|
2024-03-21 05:56:59 -04:00
|
|
|
exec src/redict-check-aof --truncate-to-timestamp 1628217470 $aof_manifest_file
|
2021-10-25 06:08:34 -04:00
|
|
|
start_server_aof [list dir $server_path] {
|
2024-03-21 05:56:59 -04:00
|
|
|
set c [redict [srv host] [srv port] 0 $::tls]
|
2021-10-26 07:08:09 -04:00
|
|
|
wait_done_loading $c
|
2021-10-25 06:08:34 -04:00
|
|
|
assert_equal "bar1" [$c get foo1]
|
|
|
|
assert_equal "" [$c get foo2]
|
|
|
|
}
|
|
|
|
|
|
|
|
# truncate to timestamp 1628217469
|
2024-03-21 05:56:59 -04:00
|
|
|
catch {exec src/redict-check-aof --truncate-to-timestamp 1628217469 $aof_manifest_file} e
|
2021-10-25 06:08:34 -04:00
|
|
|
assert_match {*aborting*} $e
|
|
|
|
}
|
2021-12-21 01:32:42 -05:00
|
|
|
|
|
|
|
test {EVAL timeout with slow verbatim Lua script from AOF} {
|
2023-10-02 01:20:53 -04:00
|
|
|
start_server [list overrides [list dir $server_path appendonly yes lua-time-limit 1 aof-use-rdb-preamble no]] {
|
2021-12-21 01:32:42 -05:00
|
|
|
# generate a long running script that is propagated to the AOF as script
|
|
|
|
# make sure that the script times out during loading
|
2022-01-24 15:31:35 -05:00
|
|
|
create_aof $aof_dirpath $aof_file {
|
|
|
|
append_to_aof [formatCommand select 9]
|
2024-03-26 06:33:40 -04:00
|
|
|
append_to_aof [formatCommand eval {redict.call('set',KEYS[1],'y'); for i=1,1500000 do redict.call('ping') end return 'ok'} 1 x]
|
2022-01-24 15:31:35 -05:00
|
|
|
}
|
2024-03-21 05:56:59 -04:00
|
|
|
set rd [redict_deferring_client]
|
2021-12-21 01:32:42 -05:00
|
|
|
$rd debug loadaof
|
|
|
|
$rd flush
|
2022-01-24 15:31:35 -05:00
|
|
|
wait_for_condition 100 10 {
|
2022-01-24 16:01:08 -05:00
|
|
|
[catch {r ping} e] == 1
|
2022-01-24 15:31:35 -05:00
|
|
|
} else {
|
|
|
|
fail "server didn't start loading"
|
|
|
|
}
|
2022-01-24 16:01:08 -05:00
|
|
|
assert_error {LOADING*} {r ping}
|
2021-12-21 01:32:42 -05:00
|
|
|
$rd read
|
|
|
|
$rd close
|
2022-01-24 15:31:35 -05:00
|
|
|
wait_for_log_messages 0 {"*Slow script detected*"} 0 100 100
|
2021-12-21 01:32:42 -05:00
|
|
|
assert_equal [r get x] y
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
test {EVAL can process writes from AOF in read-only replicas} {
|
Implement Multi Part AOF mechanism to avoid AOFRW overheads. (#9788)
Implement Multi-Part AOF mechanism to avoid overheads during AOFRW.
Introducing a folder with multiple AOF files tracked by a manifest file.
The main issues with the the original AOFRW mechanism are:
* buffering of commands that are processed during rewrite (consuming a lot of RAM)
* freezes of the main process when the AOFRW completes to drain the remaining part of the buffer and fsync it.
* double disk IO for the data that arrives during AOFRW (had to be written to both the old and new AOF files)
The main modifications of this PR:
1. Remove the AOF rewrite buffer and related code.
2. Divide the AOF into multiple files, they are classified as two types, one is the the `BASE` type,
it represents the full amount of data (Maybe AOF or RDB format) after each AOFRW, there is only
one `BASE` file at most. The second is `INCR` type, may have more than one. They represent the
incremental commands since the last AOFRW.
3. Use a AOF manifest file to record and manage these AOF files mentioned above.
4. The original configuration of `appendfilename` will be the base part of the new file name, for example:
`appendonly.aof.1.base.rdb` and `appendonly.aof.2.incr.aof`
5. Add manifest-related TCL tests, and modified some existing tests that depend on the `appendfilename`
6. Remove the `aof_rewrite_buffer_length` field in info.
7. Add `aof-disable-auto-gc` configuration. By default we're automatically deleting HISTORY type AOFs.
It also gives users the opportunity to preserve the history AOFs. just for testing use now.
8. Add AOFRW limiting measure. When the AOFRW failures reaches the threshold (3 times now),
we will delay the execution of the next AOFRW by 1 minute. If the next AOFRW also fails, it will be
delayed by 2 minutes. The next is 4, 8, 16, the maximum delay is 60 minutes (1 hour). During the limit
period, we can still use the 'bgrewriteaof' command to execute AOFRW immediately.
9. Support upgrade (load) data from old version redis.
10. Add `appenddirname` configuration, as the directory name of the append only files. All AOF files and
manifest file will be placed in this directory.
11. Only the last AOF file (BASE or INCR) can be truncated. Otherwise redis will exit even if
`aof-load-truncated` is enabled.
Co-authored-by: Oran Agra <oran@redislabs.com>
2022-01-03 12:14:13 -05:00
|
|
|
create_aof_manifest $aof_dirpath $aof_manifest_file {
|
|
|
|
append_to_manifest "file appendonly.aof.1.incr.aof seq 1 type i\n"
|
|
|
|
}
|
|
|
|
create_aof $aof_dirpath $aof_file {
|
2021-12-21 01:32:42 -05:00
|
|
|
append_to_aof [formatCommand select 9]
|
2024-03-26 06:33:40 -04:00
|
|
|
append_to_aof [formatCommand eval {redict.call("set",KEYS[1],"100")} 1 foo]
|
|
|
|
append_to_aof [formatCommand eval {redict.call("incr",KEYS[1])} 1 foo]
|
|
|
|
append_to_aof [formatCommand eval {redict.call("incr",KEYS[1])} 1 foo]
|
2021-12-21 01:32:42 -05:00
|
|
|
}
|
|
|
|
start_server [list overrides [list dir $server_path appendonly yes replica-read-only yes replicaof "127.0.0.1 0"]] {
|
|
|
|
assert_equal [r get foo] 102
|
|
|
|
}
|
|
|
|
}
|
Adapt redis-check-aof tool for Multi Part Aof (#10061)
Modifications of this PR:
1. Support the verification of `Multi Part AOF`, while still maintaining support for the
old-style `AOF/RDB-preamble`. `redis-check-aof` will automatically choose which
mode to use according to the incoming file format.
`Usage: redis-check-aof [--fix|--truncate-to-timestamp $timestamp] <AOF/manifest>`
2. Refactor part of the code to make it easier to understand
3. Currently only supports truncate (`--fix` or `--truncate-to-timestamp`) the last AOF
file (may be `BASE` or `INCR`)
The reasons for 3 above:
- for `--fix`: Only the last AOF may be truncated, this is guaranteed by redis
- for `--truncate-to-timestamp`: Normally, we only have `BASE` + `INCR` files
at most, and `BASE` cannot be truncated(It only contains a timestamp annotation
at the beginning of the file), so only `INCR` can be truncated. If we have a
`BASE+INCR1+INCR2` file (meaning we have an interrupted AOFRW), Only `INCR2`
files can be truncated at this time. If we still insist on truncate `INCR1`, we need to
manually delete `INCR2` and update the manifest file, then re-run `redis-check-aof`
- If we want to support truncate any file, we need to add very complicated code to support
the atomic modification of multiple file deletion and update manifest, I think this is unnecessary
2022-02-17 01:13:28 -05:00
|
|
|
|
2024-03-21 05:56:59 -04:00
|
|
|
test {Test redict-check-aof for old style resp AOF} {
|
Adapt redis-check-aof tool for Multi Part Aof (#10061)
Modifications of this PR:
1. Support the verification of `Multi Part AOF`, while still maintaining support for the
old-style `AOF/RDB-preamble`. `redis-check-aof` will automatically choose which
mode to use according to the incoming file format.
`Usage: redis-check-aof [--fix|--truncate-to-timestamp $timestamp] <AOF/manifest>`
2. Refactor part of the code to make it easier to understand
3. Currently only supports truncate (`--fix` or `--truncate-to-timestamp`) the last AOF
file (may be `BASE` or `INCR`)
The reasons for 3 above:
- for `--fix`: Only the last AOF may be truncated, this is guaranteed by redis
- for `--truncate-to-timestamp`: Normally, we only have `BASE` + `INCR` files
at most, and `BASE` cannot be truncated(It only contains a timestamp annotation
at the beginning of the file), so only `INCR` can be truncated. If we have a
`BASE+INCR1+INCR2` file (meaning we have an interrupted AOFRW), Only `INCR2`
files can be truncated at this time. If we still insist on truncate `INCR1`, we need to
manually delete `INCR2` and update the manifest file, then re-run `redis-check-aof`
- If we want to support truncate any file, we need to add very complicated code to support
the atomic modification of multiple file deletion and update manifest, I think this is unnecessary
2022-02-17 01:13:28 -05:00
|
|
|
create_aof $aof_dirpath $aof_file {
|
|
|
|
append_to_aof [formatCommand set foo hello]
|
|
|
|
append_to_aof [formatCommand set bar world]
|
|
|
|
}
|
|
|
|
|
|
|
|
catch {
|
2024-03-21 05:56:59 -04:00
|
|
|
exec src/redict-check-aof $aof_file
|
Adapt redis-check-aof tool for Multi Part Aof (#10061)
Modifications of this PR:
1. Support the verification of `Multi Part AOF`, while still maintaining support for the
old-style `AOF/RDB-preamble`. `redis-check-aof` will automatically choose which
mode to use according to the incoming file format.
`Usage: redis-check-aof [--fix|--truncate-to-timestamp $timestamp] <AOF/manifest>`
2. Refactor part of the code to make it easier to understand
3. Currently only supports truncate (`--fix` or `--truncate-to-timestamp`) the last AOF
file (may be `BASE` or `INCR`)
The reasons for 3 above:
- for `--fix`: Only the last AOF may be truncated, this is guaranteed by redis
- for `--truncate-to-timestamp`: Normally, we only have `BASE` + `INCR` files
at most, and `BASE` cannot be truncated(It only contains a timestamp annotation
at the beginning of the file), so only `INCR` can be truncated. If we have a
`BASE+INCR1+INCR2` file (meaning we have an interrupted AOFRW), Only `INCR2`
files can be truncated at this time. If we still insist on truncate `INCR1`, we need to
manually delete `INCR2` and update the manifest file, then re-run `redis-check-aof`
- If we want to support truncate any file, we need to add very complicated code to support
the atomic modification of multiple file deletion and update manifest, I think this is unnecessary
2022-02-17 01:13:28 -05:00
|
|
|
} result
|
|
|
|
assert_match "*Start checking Old-Style AOF*is valid*" $result
|
|
|
|
}
|
|
|
|
|
2024-03-21 05:56:59 -04:00
|
|
|
test {Test redict-check-aof for old style resp AOF - has data in the same format as manifest} {
|
2024-03-12 02:47:43 -04:00
|
|
|
create_aof $aof_dirpath $aof_file {
|
|
|
|
append_to_aof [formatCommand set file file]
|
|
|
|
append_to_aof [formatCommand set "file appendonly.aof.2.base.rdb seq 2 type b" "file appendonly.aof.2.base.rdb seq 2 type b"]
|
|
|
|
}
|
|
|
|
|
|
|
|
catch {
|
2024-03-21 05:56:59 -04:00
|
|
|
exec src/redict-check-aof $aof_file
|
2024-03-12 02:47:43 -04:00
|
|
|
} result
|
|
|
|
assert_match "*Start checking Old-Style AOF*is valid*" $result
|
|
|
|
}
|
|
|
|
|
2024-03-21 05:56:59 -04:00
|
|
|
test {Test redict-check-aof for old style rdb-preamble AOF} {
|
Adapt redis-check-aof tool for Multi Part Aof (#10061)
Modifications of this PR:
1. Support the verification of `Multi Part AOF`, while still maintaining support for the
old-style `AOF/RDB-preamble`. `redis-check-aof` will automatically choose which
mode to use according to the incoming file format.
`Usage: redis-check-aof [--fix|--truncate-to-timestamp $timestamp] <AOF/manifest>`
2. Refactor part of the code to make it easier to understand
3. Currently only supports truncate (`--fix` or `--truncate-to-timestamp`) the last AOF
file (may be `BASE` or `INCR`)
The reasons for 3 above:
- for `--fix`: Only the last AOF may be truncated, this is guaranteed by redis
- for `--truncate-to-timestamp`: Normally, we only have `BASE` + `INCR` files
at most, and `BASE` cannot be truncated(It only contains a timestamp annotation
at the beginning of the file), so only `INCR` can be truncated. If we have a
`BASE+INCR1+INCR2` file (meaning we have an interrupted AOFRW), Only `INCR2`
files can be truncated at this time. If we still insist on truncate `INCR1`, we need to
manually delete `INCR2` and update the manifest file, then re-run `redis-check-aof`
- If we want to support truncate any file, we need to add very complicated code to support
the atomic modification of multiple file deletion and update manifest, I think this is unnecessary
2022-02-17 01:13:28 -05:00
|
|
|
catch {
|
2024-03-21 05:56:59 -04:00
|
|
|
exec src/redict-check-aof tests/assets/rdb-preamble.aof
|
Adapt redis-check-aof tool for Multi Part Aof (#10061)
Modifications of this PR:
1. Support the verification of `Multi Part AOF`, while still maintaining support for the
old-style `AOF/RDB-preamble`. `redis-check-aof` will automatically choose which
mode to use according to the incoming file format.
`Usage: redis-check-aof [--fix|--truncate-to-timestamp $timestamp] <AOF/manifest>`
2. Refactor part of the code to make it easier to understand
3. Currently only supports truncate (`--fix` or `--truncate-to-timestamp`) the last AOF
file (may be `BASE` or `INCR`)
The reasons for 3 above:
- for `--fix`: Only the last AOF may be truncated, this is guaranteed by redis
- for `--truncate-to-timestamp`: Normally, we only have `BASE` + `INCR` files
at most, and `BASE` cannot be truncated(It only contains a timestamp annotation
at the beginning of the file), so only `INCR` can be truncated. If we have a
`BASE+INCR1+INCR2` file (meaning we have an interrupted AOFRW), Only `INCR2`
files can be truncated at this time. If we still insist on truncate `INCR1`, we need to
manually delete `INCR2` and update the manifest file, then re-run `redis-check-aof`
- If we want to support truncate any file, we need to add very complicated code to support
the atomic modification of multiple file deletion and update manifest, I think this is unnecessary
2022-02-17 01:13:28 -05:00
|
|
|
} result
|
|
|
|
assert_match "*Start checking Old-Style AOF*RDB preamble is OK, proceeding with AOF tail*is valid*" $result
|
|
|
|
}
|
|
|
|
|
2024-03-21 05:56:59 -04:00
|
|
|
test {Test redict-check-aof for Multi Part AOF with resp AOF base} {
|
Adapt redis-check-aof tool for Multi Part Aof (#10061)
Modifications of this PR:
1. Support the verification of `Multi Part AOF`, while still maintaining support for the
old-style `AOF/RDB-preamble`. `redis-check-aof` will automatically choose which
mode to use according to the incoming file format.
`Usage: redis-check-aof [--fix|--truncate-to-timestamp $timestamp] <AOF/manifest>`
2. Refactor part of the code to make it easier to understand
3. Currently only supports truncate (`--fix` or `--truncate-to-timestamp`) the last AOF
file (may be `BASE` or `INCR`)
The reasons for 3 above:
- for `--fix`: Only the last AOF may be truncated, this is guaranteed by redis
- for `--truncate-to-timestamp`: Normally, we only have `BASE` + `INCR` files
at most, and `BASE` cannot be truncated(It only contains a timestamp annotation
at the beginning of the file), so only `INCR` can be truncated. If we have a
`BASE+INCR1+INCR2` file (meaning we have an interrupted AOFRW), Only `INCR2`
files can be truncated at this time. If we still insist on truncate `INCR1`, we need to
manually delete `INCR2` and update the manifest file, then re-run `redis-check-aof`
- If we want to support truncate any file, we need to add very complicated code to support
the atomic modification of multiple file deletion and update manifest, I think this is unnecessary
2022-02-17 01:13:28 -05:00
|
|
|
create_aof $aof_dirpath $aof_base_file {
|
|
|
|
append_to_aof [formatCommand set foo hello]
|
|
|
|
append_to_aof [formatCommand set bar world]
|
|
|
|
}
|
|
|
|
|
|
|
|
create_aof $aof_dirpath $aof_file {
|
|
|
|
append_to_aof [formatCommand set foo hello]
|
|
|
|
append_to_aof [formatCommand set bar world]
|
|
|
|
}
|
|
|
|
|
|
|
|
create_aof_manifest $aof_dirpath $aof_manifest_file {
|
|
|
|
append_to_manifest "file appendonly.aof.1.base.aof seq 1 type b\n"
|
|
|
|
append_to_manifest "file appendonly.aof.1.incr.aof seq 1 type i\n"
|
|
|
|
}
|
|
|
|
|
|
|
|
catch {
|
2024-03-21 05:56:59 -04:00
|
|
|
exec src/redict-check-aof $aof_manifest_file
|
2023-10-02 01:20:53 -04:00
|
|
|
} result
|
Adapt redis-check-aof tool for Multi Part Aof (#10061)
Modifications of this PR:
1. Support the verification of `Multi Part AOF`, while still maintaining support for the
old-style `AOF/RDB-preamble`. `redis-check-aof` will automatically choose which
mode to use according to the incoming file format.
`Usage: redis-check-aof [--fix|--truncate-to-timestamp $timestamp] <AOF/manifest>`
2. Refactor part of the code to make it easier to understand
3. Currently only supports truncate (`--fix` or `--truncate-to-timestamp`) the last AOF
file (may be `BASE` or `INCR`)
The reasons for 3 above:
- for `--fix`: Only the last AOF may be truncated, this is guaranteed by redis
- for `--truncate-to-timestamp`: Normally, we only have `BASE` + `INCR` files
at most, and `BASE` cannot be truncated(It only contains a timestamp annotation
at the beginning of the file), so only `INCR` can be truncated. If we have a
`BASE+INCR1+INCR2` file (meaning we have an interrupted AOFRW), Only `INCR2`
files can be truncated at this time. If we still insist on truncate `INCR1`, we need to
manually delete `INCR2` and update the manifest file, then re-run `redis-check-aof`
- If we want to support truncate any file, we need to add very complicated code to support
the atomic modification of multiple file deletion and update manifest, I think this is unnecessary
2022-02-17 01:13:28 -05:00
|
|
|
assert_match "*Start checking Multi Part AOF*Start to check BASE AOF (RESP format)*BASE AOF*is valid*Start to check INCR files*INCR AOF*is valid*All AOF files and manifest are valid*" $result
|
|
|
|
}
|
|
|
|
|
2024-03-21 05:56:59 -04:00
|
|
|
test {Test redict-check-aof for Multi Part AOF with rdb-preamble AOF base} {
|
Adapt redis-check-aof tool for Multi Part Aof (#10061)
Modifications of this PR:
1. Support the verification of `Multi Part AOF`, while still maintaining support for the
old-style `AOF/RDB-preamble`. `redis-check-aof` will automatically choose which
mode to use according to the incoming file format.
`Usage: redis-check-aof [--fix|--truncate-to-timestamp $timestamp] <AOF/manifest>`
2. Refactor part of the code to make it easier to understand
3. Currently only supports truncate (`--fix` or `--truncate-to-timestamp`) the last AOF
file (may be `BASE` or `INCR`)
The reasons for 3 above:
- for `--fix`: Only the last AOF may be truncated, this is guaranteed by redis
- for `--truncate-to-timestamp`: Normally, we only have `BASE` + `INCR` files
at most, and `BASE` cannot be truncated(It only contains a timestamp annotation
at the beginning of the file), so only `INCR` can be truncated. If we have a
`BASE+INCR1+INCR2` file (meaning we have an interrupted AOFRW), Only `INCR2`
files can be truncated at this time. If we still insist on truncate `INCR1`, we need to
manually delete `INCR2` and update the manifest file, then re-run `redis-check-aof`
- If we want to support truncate any file, we need to add very complicated code to support
the atomic modification of multiple file deletion and update manifest, I think this is unnecessary
2022-02-17 01:13:28 -05:00
|
|
|
exec cp tests/assets/rdb-preamble.aof $aof_base_file
|
|
|
|
|
|
|
|
create_aof $aof_dirpath $aof_file {
|
|
|
|
append_to_aof [formatCommand set foo hello]
|
|
|
|
append_to_aof [formatCommand set bar world]
|
|
|
|
}
|
|
|
|
|
|
|
|
create_aof_manifest $aof_dirpath $aof_manifest_file {
|
|
|
|
append_to_manifest "file appendonly.aof.1.base.aof seq 1 type b\n"
|
|
|
|
append_to_manifest "file appendonly.aof.1.incr.aof seq 1 type i\n"
|
|
|
|
}
|
|
|
|
|
|
|
|
catch {
|
2024-03-21 05:56:59 -04:00
|
|
|
exec src/redict-check-aof $aof_manifest_file
|
Adapt redis-check-aof tool for Multi Part Aof (#10061)
Modifications of this PR:
1. Support the verification of `Multi Part AOF`, while still maintaining support for the
old-style `AOF/RDB-preamble`. `redis-check-aof` will automatically choose which
mode to use according to the incoming file format.
`Usage: redis-check-aof [--fix|--truncate-to-timestamp $timestamp] <AOF/manifest>`
2. Refactor part of the code to make it easier to understand
3. Currently only supports truncate (`--fix` or `--truncate-to-timestamp`) the last AOF
file (may be `BASE` or `INCR`)
The reasons for 3 above:
- for `--fix`: Only the last AOF may be truncated, this is guaranteed by redis
- for `--truncate-to-timestamp`: Normally, we only have `BASE` + `INCR` files
at most, and `BASE` cannot be truncated(It only contains a timestamp annotation
at the beginning of the file), so only `INCR` can be truncated. If we have a
`BASE+INCR1+INCR2` file (meaning we have an interrupted AOFRW), Only `INCR2`
files can be truncated at this time. If we still insist on truncate `INCR1`, we need to
manually delete `INCR2` and update the manifest file, then re-run `redis-check-aof`
- If we want to support truncate any file, we need to add very complicated code to support
the atomic modification of multiple file deletion and update manifest, I think this is unnecessary
2022-02-17 01:13:28 -05:00
|
|
|
} result
|
|
|
|
assert_match "*Start checking Multi Part AOF*Start to check BASE AOF (RDB format)*DB preamble is OK, proceeding with AOF tail*BASE AOF*is valid*Start to check INCR files*INCR AOF*is valid*All AOF files and manifest are valid*" $result
|
|
|
|
}
|
|
|
|
|
2024-03-21 05:56:59 -04:00
|
|
|
test {Test redict-check-aof for Multi Part AOF contains a format error} {
|
2024-03-12 02:47:43 -04:00
|
|
|
create_aof_manifest $aof_dirpath $aof_manifest_file {
|
|
|
|
append_to_manifest "file appendonly.aof.1.base.aof seq 1 type b\n"
|
|
|
|
append_to_manifest "file appendonly.aof.1.incr.aof seq 1 type i\n"
|
|
|
|
append_to_manifest "!!!\n"
|
|
|
|
}
|
|
|
|
|
|
|
|
catch {
|
2024-03-21 05:56:59 -04:00
|
|
|
exec src/redict-check-aof $aof_manifest_file
|
2024-03-12 02:47:43 -04:00
|
|
|
} result
|
|
|
|
assert_match "*Invalid AOF manifest file format*" $result
|
|
|
|
}
|
|
|
|
|
2024-03-21 05:56:59 -04:00
|
|
|
test {Test redict-check-aof only truncates the last file for Multi Part AOF in fix mode} {
|
Adapt redis-check-aof tool for Multi Part Aof (#10061)
Modifications of this PR:
1. Support the verification of `Multi Part AOF`, while still maintaining support for the
old-style `AOF/RDB-preamble`. `redis-check-aof` will automatically choose which
mode to use according to the incoming file format.
`Usage: redis-check-aof [--fix|--truncate-to-timestamp $timestamp] <AOF/manifest>`
2. Refactor part of the code to make it easier to understand
3. Currently only supports truncate (`--fix` or `--truncate-to-timestamp`) the last AOF
file (may be `BASE` or `INCR`)
The reasons for 3 above:
- for `--fix`: Only the last AOF may be truncated, this is guaranteed by redis
- for `--truncate-to-timestamp`: Normally, we only have `BASE` + `INCR` files
at most, and `BASE` cannot be truncated(It only contains a timestamp annotation
at the beginning of the file), so only `INCR` can be truncated. If we have a
`BASE+INCR1+INCR2` file (meaning we have an interrupted AOFRW), Only `INCR2`
files can be truncated at this time. If we still insist on truncate `INCR1`, we need to
manually delete `INCR2` and update the manifest file, then re-run `redis-check-aof`
- If we want to support truncate any file, we need to add very complicated code to support
the atomic modification of multiple file deletion and update manifest, I think this is unnecessary
2022-02-17 01:13:28 -05:00
|
|
|
create_aof $aof_dirpath $aof_base_file {
|
|
|
|
append_to_aof [formatCommand set foo hello]
|
|
|
|
append_to_aof [formatCommand multi]
|
|
|
|
append_to_aof [formatCommand set bar world]
|
|
|
|
}
|
|
|
|
|
|
|
|
create_aof $aof_dirpath $aof_file {
|
|
|
|
append_to_aof [formatCommand set foo hello]
|
|
|
|
append_to_aof [formatCommand set bar world]
|
|
|
|
}
|
|
|
|
|
|
|
|
create_aof_manifest $aof_dirpath $aof_manifest_file {
|
|
|
|
append_to_manifest "file appendonly.aof.1.base.aof seq 1 type b\n"
|
|
|
|
append_to_manifest "file appendonly.aof.1.incr.aof seq 1 type i\n"
|
|
|
|
}
|
|
|
|
|
|
|
|
catch {
|
2024-03-21 05:56:59 -04:00
|
|
|
exec src/redict-check-aof $aof_manifest_file
|
Adapt redis-check-aof tool for Multi Part Aof (#10061)
Modifications of this PR:
1. Support the verification of `Multi Part AOF`, while still maintaining support for the
old-style `AOF/RDB-preamble`. `redis-check-aof` will automatically choose which
mode to use according to the incoming file format.
`Usage: redis-check-aof [--fix|--truncate-to-timestamp $timestamp] <AOF/manifest>`
2. Refactor part of the code to make it easier to understand
3. Currently only supports truncate (`--fix` or `--truncate-to-timestamp`) the last AOF
file (may be `BASE` or `INCR`)
The reasons for 3 above:
- for `--fix`: Only the last AOF may be truncated, this is guaranteed by redis
- for `--truncate-to-timestamp`: Normally, we only have `BASE` + `INCR` files
at most, and `BASE` cannot be truncated(It only contains a timestamp annotation
at the beginning of the file), so only `INCR` can be truncated. If we have a
`BASE+INCR1+INCR2` file (meaning we have an interrupted AOFRW), Only `INCR2`
files can be truncated at this time. If we still insist on truncate `INCR1`, we need to
manually delete `INCR2` and update the manifest file, then re-run `redis-check-aof`
- If we want to support truncate any file, we need to add very complicated code to support
the atomic modification of multiple file deletion and update manifest, I think this is unnecessary
2022-02-17 01:13:28 -05:00
|
|
|
} result
|
|
|
|
assert_match "*not valid*" $result
|
|
|
|
|
|
|
|
catch {
|
2024-03-21 05:56:59 -04:00
|
|
|
exec src/redict-check-aof --fix $aof_manifest_file
|
Adapt redis-check-aof tool for Multi Part Aof (#10061)
Modifications of this PR:
1. Support the verification of `Multi Part AOF`, while still maintaining support for the
old-style `AOF/RDB-preamble`. `redis-check-aof` will automatically choose which
mode to use according to the incoming file format.
`Usage: redis-check-aof [--fix|--truncate-to-timestamp $timestamp] <AOF/manifest>`
2. Refactor part of the code to make it easier to understand
3. Currently only supports truncate (`--fix` or `--truncate-to-timestamp`) the last AOF
file (may be `BASE` or `INCR`)
The reasons for 3 above:
- for `--fix`: Only the last AOF may be truncated, this is guaranteed by redis
- for `--truncate-to-timestamp`: Normally, we only have `BASE` + `INCR` files
at most, and `BASE` cannot be truncated(It only contains a timestamp annotation
at the beginning of the file), so only `INCR` can be truncated. If we have a
`BASE+INCR1+INCR2` file (meaning we have an interrupted AOFRW), Only `INCR2`
files can be truncated at this time. If we still insist on truncate `INCR1`, we need to
manually delete `INCR2` and update the manifest file, then re-run `redis-check-aof`
- If we want to support truncate any file, we need to add very complicated code to support
the atomic modification of multiple file deletion and update manifest, I think this is unnecessary
2022-02-17 01:13:28 -05:00
|
|
|
} result
|
|
|
|
assert_match "*Failed to truncate AOF*because it is not the last file*" $result
|
|
|
|
}
|
|
|
|
|
2024-03-21 05:56:59 -04:00
|
|
|
test {Test redict-check-aof only truncates the last file for Multi Part AOF in truncate-to-timestamp mode} {
|
Adapt redis-check-aof tool for Multi Part Aof (#10061)
Modifications of this PR:
1. Support the verification of `Multi Part AOF`, while still maintaining support for the
old-style `AOF/RDB-preamble`. `redis-check-aof` will automatically choose which
mode to use according to the incoming file format.
`Usage: redis-check-aof [--fix|--truncate-to-timestamp $timestamp] <AOF/manifest>`
2. Refactor part of the code to make it easier to understand
3. Currently only supports truncate (`--fix` or `--truncate-to-timestamp`) the last AOF
file (may be `BASE` or `INCR`)
The reasons for 3 above:
- for `--fix`: Only the last AOF may be truncated, this is guaranteed by redis
- for `--truncate-to-timestamp`: Normally, we only have `BASE` + `INCR` files
at most, and `BASE` cannot be truncated(It only contains a timestamp annotation
at the beginning of the file), so only `INCR` can be truncated. If we have a
`BASE+INCR1+INCR2` file (meaning we have an interrupted AOFRW), Only `INCR2`
files can be truncated at this time. If we still insist on truncate `INCR1`, we need to
manually delete `INCR2` and update the manifest file, then re-run `redis-check-aof`
- If we want to support truncate any file, we need to add very complicated code to support
the atomic modification of multiple file deletion and update manifest, I think this is unnecessary
2022-02-17 01:13:28 -05:00
|
|
|
create_aof $aof_dirpath $aof_base_file {
|
|
|
|
append_to_aof "#TS:1628217470\r\n"
|
|
|
|
append_to_aof [formatCommand set foo1 bar1]
|
|
|
|
append_to_aof "#TS:1628217471\r\n"
|
|
|
|
append_to_aof [formatCommand set foo2 bar2]
|
|
|
|
append_to_aof "#TS:1628217472\r\n"
|
|
|
|
append_to_aof "#TS:1628217473\r\n"
|
|
|
|
append_to_aof [formatCommand set foo3 bar3]
|
|
|
|
append_to_aof "#TS:1628217474\r\n"
|
|
|
|
}
|
|
|
|
|
|
|
|
create_aof $aof_dirpath $aof_file {
|
|
|
|
append_to_aof [formatCommand set foo hello]
|
|
|
|
append_to_aof [formatCommand set bar world]
|
|
|
|
}
|
|
|
|
|
|
|
|
create_aof_manifest $aof_dirpath $aof_manifest_file {
|
|
|
|
append_to_manifest "file appendonly.aof.1.base.aof seq 1 type b\n"
|
|
|
|
append_to_manifest "file appendonly.aof.1.incr.aof seq 1 type i\n"
|
|
|
|
}
|
|
|
|
|
|
|
|
catch {
|
2024-03-21 05:56:59 -04:00
|
|
|
exec src/redict-check-aof --truncate-to-timestamp 1628217473 $aof_manifest_file
|
Adapt redis-check-aof tool for Multi Part Aof (#10061)
Modifications of this PR:
1. Support the verification of `Multi Part AOF`, while still maintaining support for the
old-style `AOF/RDB-preamble`. `redis-check-aof` will automatically choose which
mode to use according to the incoming file format.
`Usage: redis-check-aof [--fix|--truncate-to-timestamp $timestamp] <AOF/manifest>`
2. Refactor part of the code to make it easier to understand
3. Currently only supports truncate (`--fix` or `--truncate-to-timestamp`) the last AOF
file (may be `BASE` or `INCR`)
The reasons for 3 above:
- for `--fix`: Only the last AOF may be truncated, this is guaranteed by redis
- for `--truncate-to-timestamp`: Normally, we only have `BASE` + `INCR` files
at most, and `BASE` cannot be truncated(It only contains a timestamp annotation
at the beginning of the file), so only `INCR` can be truncated. If we have a
`BASE+INCR1+INCR2` file (meaning we have an interrupted AOFRW), Only `INCR2`
files can be truncated at this time. If we still insist on truncate `INCR1`, we need to
manually delete `INCR2` and update the manifest file, then re-run `redis-check-aof`
- If we want to support truncate any file, we need to add very complicated code to support
the atomic modification of multiple file deletion and update manifest, I think this is unnecessary
2022-02-17 01:13:28 -05:00
|
|
|
} result
|
|
|
|
assert_match "*Failed to truncate AOF*to timestamp*because it is not the last file*" $result
|
|
|
|
}
|
FLUSHDB and FLUSHALL add call forceCommandPropagation / FLUSHALL reset dirty counter to 0 if we enable save (#10691)
## FLUSHALL
We used to restore the dirty counter after `rdbSave` zeroed it if we enable save.
Otherwise FLUSHALL will not be replicated nor put into the AOF.
And then we do increment it again below.
Without that extra dirty++, when db was already empty, FLUSHALL
will not be replicated nor put into the AOF.
We now gonna replace all that dirty counter magic with a call
to forceCommandPropagation (REPL and AOF), instead of all the
messing around with the dirty counter.
Added tests to cover three part (dirty counter, REPL, AOF).
One benefit other than cleaner code is that the `rdb_changes_since_last_save` is correct in this case.
## FLUSHDB
FLUSHDB was not replicated nor put into the AOF when db was already empty.
Unlike DEL on a non-existing key, FLUSHDB always does something, and that's to call the module hook.
So basically FLUSHDB is never a NOP, and thus it should always be propagated.
Not doing that, could mean that if a module does something in that hook, and wants to
avoid issues of that hook being missing on the replica if the db is empty, it'll need to do complicated things.
So now FLUSHDB add call forceCommandPropagation, we will always propagate FLUSHDB.
Always propagating FLUSHDB seems like a safe approach that shouldn't have any drawbacks (other than looking odd)
This was mentioned in #8972
## Test section:
We actually found it while solving a race condition in the BGSAVE test (other.tcl).
It was found in extra_ci Daily Arm64 (test-libc-malloc).
```
[exception]: Executing test client: ERR Background save already in progress.
ERR Background save already in progress
```
It look like `r flushdb` trigger (schedule) a bgsave right after `waitForBgsave r` and before `r save`.
Changing flushdb to flushall, FLUSHALL will do a foreground save and then set the dirty counter to 0.
2022-05-11 04:21:16 -04:00
|
|
|
|
|
|
|
start_server {overrides {appendonly yes appendfsync always}} {
|
|
|
|
test {FLUSHDB / FLUSHALL should persist in AOF} {
|
|
|
|
set aof [get_last_incr_aof_path r]
|
|
|
|
|
|
|
|
r set key value
|
|
|
|
r flushdb
|
|
|
|
r set key value2
|
|
|
|
r flushdb
|
|
|
|
|
|
|
|
# DB is empty
|
|
|
|
r flushdb
|
|
|
|
r flushdb
|
|
|
|
r flushdb
|
|
|
|
|
|
|
|
r set key value
|
|
|
|
r flushall
|
|
|
|
r set key value2
|
|
|
|
r flushall
|
|
|
|
|
|
|
|
# DBs are empty.
|
|
|
|
r flushall
|
|
|
|
r flushall
|
|
|
|
r flushall
|
|
|
|
|
|
|
|
# Assert that each FLUSHDB command is persisted even the DB is empty.
|
|
|
|
# Assert that each FLUSHALL command is persisted even the DBs are empty.
|
|
|
|
assert_aof_content $aof {
|
|
|
|
{select *}
|
|
|
|
{set key value}
|
|
|
|
{flushdb}
|
|
|
|
{set key value2}
|
|
|
|
{flushdb}
|
|
|
|
{flushdb}
|
|
|
|
{flushdb}
|
|
|
|
{flushdb}
|
|
|
|
{set key value}
|
|
|
|
{flushall}
|
|
|
|
{set key value2}
|
|
|
|
{flushall}
|
|
|
|
{flushall}
|
|
|
|
{flushall}
|
|
|
|
{flushall}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2010-05-19 08:33:39 -04:00
|
|
|
}
|