You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: apps/fortuna/README.md
+59Lines changed: 59 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,6 +17,11 @@ a database to be available at build time. Create a `.env` file in the root of th
17
17
DATABASE_URL="sqlite:fortuna.db?mode=rwc"
18
18
```
19
19
20
+
Install sqlx for cargo with:
21
+
```bash
22
+
cargo install sqlx
23
+
```
24
+
20
25
Next, you need to create the database and apply the schema migrations. You can do this by running:
21
26
22
27
```bash
@@ -40,6 +45,60 @@ Please add the changed files in the `.sqlx` folder to your git commit.
40
45
The Fortuna binary has a command-line interface to perform useful operations on the contract, such as
41
46
registering a new randomness provider, or drawing a random value. To see the available commands, simply run `cargo run`.
42
47
48
+
## Multiple Replica Setup
49
+
50
+
Fortuna supports running multiple replica instances for high availability and reliability. This prevents service interruption if one instance goes down and distributes the workload across multiple instances.
51
+
52
+
### How Replica Assignment Works
53
+
54
+
- Each replica is assigned a unique `replica_id` (0, 1, 2, etc.)
55
+
- Requests are distributed using modulo assignment: `sequence_number % total_replicas`
56
+
- Each replica primarily handles requests assigned to its ID
57
+
- After a configurable delay, replicas will process requests from other replicas as backup (failover)
1. **Separate Wallets**: Each replica MUST use a different private key to avoid nonce conflicts
91
+
2. **Backup Delay**: Set `backup_delay_seconds` long enough to allow primary replica to process requests, but short enough for acceptable failover time (recommended: 30-60 seconds)
92
+
3. **Monitoring**: Monitor each replica's processing metrics to ensure proper load distribution
93
+
4. **Gas Management**: Each replica needs sufficient ETH balance for gas fees
94
+
95
+
### Failover Behavior
96
+
97
+
- Primary replica processes requests immediately
98
+
- Backup replicas wait for `backup_delay_seconds` before checking if request is still unfulfilled
99
+
- If request is already fulfilled during the delay, backup replica skips processing
100
+
- This prevents duplicate transactions and wasted gas while ensuring reliability
101
+
43
102
## Local Development
44
103
45
104
To start an instance of the webserver for local testing, you first need to perform a few setup steps:
let keeper_private_key_option = config.keeper.private_key.load()?;
98
99
if keeper_private_key_option.is_none(){
99
100
tracing::info!("Not starting keeper service: no keeper private key specified. Please add one to the config if you would like to run the keeper service.")
100
101
}
102
+
103
+
let keeper_replica_config = config.keeper.replica_config.clone();
104
+
101
105
let chains:Arc<RwLock<HashMap<ChainId,ApiBlockChainState>>> = Arc::new(RwLock::new(
0 commit comments