fixed needed readme's over the writeback change
This commit is contained in:
+56
-19
@@ -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.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user