fixed needed readme's over the writeback change

This commit is contained in:
2026-04-19 16:20:22 -04:00
parent 4399c81b6e
commit af14a5ca2c
3 changed files with 112 additions and 42 deletions
+56 -19
View File
@@ -62,20 +62,26 @@ NPM, LLDAP, and Authelia run actively on both servers at all times. HOST2 needs
Early testing ran the auth stack cold on failover. Results: 30-60 seconds of broken authentication after DNS cut over. Emby clients hit HOST2 before auth was ready — reconnects failed, streams died. Running warm eliminates this window entirely.
**What actually starts from stopped on failover (HOST1 goes down):**
**What actually starts from stopped — both directions:**
```
Emby ← starts from stopped on HOST2
DDNS updater ← HOST1's domain updater starts on HOST2
Tier 1 — immediate:
Emby ← starts from stopped on covering server
DDNS updater ← remote domain updater starts on covering server
Already running — verified healthy, NOT cold started:
NPM — serving his domain continuously
LLDAP — authenticating his users continuously
Authelia — protecting his services continuously
Certs — mirrored, valid, already loaded
Already running — verified healthy, NOT cold started:
NPM — serving both domains continuously
LLDAP — authenticating all users continuously
Authelia — protecting all services continuously
Certs — mirrored, valid, already loaded on both servers
Tier 4 — 18hr+ outage:
Arrs_Stack ← starts from stopped on covering server
mirrored Arrs_Stack appdata — starts in known good state
not running in normal operation on covering server
```
DNS cuts over in 1 minute. Auth is already ready. Library transcode users reconnect seamlessly through buffer. Live TV and direct play users notice and need to resume — the known, accepted tradeoff.
DNS cuts over in 1 minute. Auth is already ready. Library transcode users reconnect seamlessly through buffer. Live TV and direct play users notice and need to resume — the known, accepted tradeoff. Watch history worst case 15-30min behind — in reality a show or two, movies may be unaffected given their length.
**Independence — always one rsync stop away:**
@@ -470,17 +476,48 @@ If the state file gets stuck in a non-NORMAL state after testing or a failed han
## What Gets Written Back on Handback
| Data | Written back | Reason |
|------|-------------|--------|
| Emby userdata / playstates | ✅ Yes | Small, important — watch history |
| Auth stack data | ✅ Yes | Authelia sessions, LLDAP data |
| NextCloud data | ✅ Yes | File changes during outage |
| Emby metadata | ✅ Yes | Any metadata scraped during outage |
| Media files | ❌ No | Already on HOST1, never moved |
| Downloads | ❌ No | Start fresh — cleaner than partial state |
| Arr databases | ❌ No (if under 18hr) | Arrs never started, nothing to sync |
| Data | Written back | Condition |
|------|-------------|-----------|
| Emby userdata / playstates | ✅ If outage > TIER1_WRITEBACK_DELAY (60min) | Small, important — watch history |
| Auth stack data | ✅ If outage > TIER1_WRITEBACK_DELAY (60min) | Authelia sessions, LLDAP data |
| NextCloud data | ✅ If outage > TIER2_DELAY (120min) | File changes during outage |
| Secondary appdata | ✅ If outage > TIER3_DELAY (360min) | Any accumulated changes |
| Opposing host's media shares | ✅ If outage > TIER4_DELAY (1080min) | HOST1_DAILY_SYNC_SHARES or HOST2_DAILY_SYNC_SHARES — same list daily_sync.sh uses, opposite direction |
| Edge case paths | ✅ If outage > TIER4_DELAY | Anything in FAILOVER_HOST*_WRITEBACK_TIER4 |
| Media files (own truth shares) | ❌ Never | Already on primary, never moved |
| Downloads | ❌ Never | Start fresh — cleaner than partial state |
The minimal writeback is intentional and by design. The goal is to get HOST1 back to the state it was in before the outage plus the delta of what changed during it — not to sync everything.
**Writeback skip window — short outages skip writeback entirely:**
Emby syncs every 30 minutes from a live running container (dirty sync). A clean full sync runs nightly at 2:30am with Emby stopped. After a short outage, the primary's clean nightly state is more reliable than what accumulated on the covering server — skip writeback entirely.
```
Under 60min → skip Tier 1-3 writeback — primary has cleaner data
Under 120min → skip Tier 2-3 writeback
Under 360min → skip Tier 3 writeback
Under 1080min → skip Tier 4 writeback — arrs never started, nothing to sync back
Over 1080min → full tiered writeback — meaningful delta accumulated
```
Real world outage profile:
```
Power blip 2-10min → no writeback, clean restart (most common)
ISP issue 10-60min → no writeback, clean restart
Real outage 3hr → Tier 1+2 writeback, skip 3+4
Extended 18hr+ → full tiered writeback including media shares
```
**Tier 4 media writeback — opposing orch list:**
At Tier 4, the covering server has been running the other server's arrs against the mirrored media shares. New content downloaded during the outage needs to sync back before the primary's own arrs restart. Rather than maintaining a duplicate share list, Tier 4 writeback automatically uses the opposing host's `HOST*_DAILY_SYNC_SHARES` — the same list `daily_sync.sh` uses, but in the opposite direction.
```
Normal (daily_sync.sh): HOST1 → pushes Movies, Tv_Shows → HOST2
Tier 4 writeback: HOST2 → pushes Movies, Tv_Shows → HOST1 (opposite direction)
Same list, correct direction for the situation, no duplication.
```
Additional edge case paths outside the daily sync list can be added to `FAILOVER_HOST*_WRITEBACK_TIER4` in Master.conf.
---