mirror of
https://github.com/neondatabase/neon.git
synced 2026-01-06 04:52:55 +00:00
4be2223a4c
This PR contains the first version of a [FoundationDB-like](https://www.youtube.com/watch?v=4fFDFbi3toc) simulation testing for safekeeper and walproposer. ### desim This is a core "framework" for running determenistic simulation. It operates on threads, allowing to test syncronous code (like walproposer). `libs/desim/src/executor.rs` contains implementation of a determenistic thread execution. This is achieved by blocking all threads, and each time allowing only a single thread to make an execution step. All executor's threads are blocked using `yield_me(after_ms)` function. This function is called when a thread wants to sleep or wait for an external notification (like blocking on a channel until it has a ready message). `libs/desim/src/chan.rs` contains implementation of a channel (basic sync primitive). It has unlimited capacity and any thread can push or read messages to/from it. `libs/desim/src/network.rs` has a very naive implementation of a network (only reliable TCP-like connections are supported for now), that can have arbitrary delays for each package and failure injections for breaking connections with some probability. `libs/desim/src/world.rs` ties everything together, to have a concept of virtual nodes that can have network connections between them. ### walproposer_sim Has everything to run walproposer and safekeepers in a simulation. `safekeeper.rs` reimplements all necesary stuff from `receive_wal.rs`, `send_wal.rs` and `timelines_global_map.rs`. `walproposer_api.rs` implements all walproposer callback to use simulation library. `simulation.rs` defines a schedule – a set of events like `restart <sk>` or `write_wal` that should happen at time `<ts>`. It also has code to spawn walproposer/safekeeper threads and provide config to them. ### tests `simple_test.rs` has tests that just start walproposer and 3 safekeepers together in a simulation, and tests that they are not crashing right away. `misc_test.rs` has tests checking more advanced simulation cases, like crashing or restarting threads, testing memory deallocation, etc. `random_test.rs` is the main test, it checks thousands of random seeds (schedules) for correctness. It roughly corresponds to running a real python integration test in an environment with very unstable network and cpu, but in a determenistic way (each seed results in the same execution log) and much much faster. Closes #547 --------- Co-authored-by: Arseny Sher <sher-ars@yandex.ru>
46 lines
1.2 KiB
Rust
46 lines
1.2 KiB
Rust
use tracing::info;
|
|
use utils::lsn::Lsn;
|
|
|
|
use crate::walproposer_sim::{log::init_logger, simulation::TestConfig};
|
|
|
|
pub mod walproposer_sim;
|
|
|
|
// Check that first start of sync_safekeepers() returns 0/0 on empty safekeepers.
|
|
#[test]
|
|
fn sync_empty_safekeepers() {
|
|
let clock = init_logger();
|
|
let config = TestConfig::new(Some(clock));
|
|
let test = config.start(1337);
|
|
|
|
let lsn = test.sync_safekeepers().unwrap();
|
|
assert_eq!(lsn, Lsn(0));
|
|
info!("Sucessfully synced empty safekeepers at 0/0");
|
|
|
|
let lsn = test.sync_safekeepers().unwrap();
|
|
assert_eq!(lsn, Lsn(0));
|
|
info!("Sucessfully synced (again) empty safekeepers at 0/0");
|
|
}
|
|
|
|
// Check that there are no panics when we are writing and streaming WAL to safekeepers.
|
|
#[test]
|
|
fn run_walproposer_generate_wal() {
|
|
let clock = init_logger();
|
|
let config = TestConfig::new(Some(clock));
|
|
let test = config.start(1337);
|
|
|
|
let lsn = test.sync_safekeepers().unwrap();
|
|
assert_eq!(lsn, Lsn(0));
|
|
info!("Sucessfully synced empty safekeepers at 0/0");
|
|
|
|
let mut wp = test.launch_walproposer(lsn);
|
|
|
|
// wait for walproposer to start
|
|
test.poll_for_duration(30);
|
|
|
|
// just write some WAL
|
|
for _ in 0..100 {
|
|
wp.write_tx(1);
|
|
test.poll_for_duration(5);
|
|
}
|
|
}
|