Kumulatívny update (CU) pri Always On – rolling upgrade

Cieľ rolling upgradu: primárna replika je nedostupná len počas **jedného manuálneho failoveru** (dvoch, ak sa vraciaš na pôvodný server). Platí rovnako pre CU aj pre upgrade verzie.

> [!WARNING]
> **Nikdy nepatchuj primárnu repliku ako prvú.** Primárna na novšom builde nevie posielať log na staršie sekundárky – pohyb dát sa pozastaví, automatický failover prestane fungovať a databázy sú vystavené strate dát.

## 1. Príprava

1. Prečítaj **known issues** daného CU a over podporovanú cestu upgradu.
2. FULL zálohy všetkých AG databáz a [DBCC CHECKDB](script.php?id=34&s=dbcc-checkdb-sablona-s-dry-run).
3. [Always On AG – stav replík](script.php?id=42&s=always-on-ag-stav-replik-a-synchronizacie): všetko `HEALTHY`, synchrónne repliky `SYNCHRONIZED`, malé send / redo queue.
4. Nastav **preferenciu záloh na primárnu** – počas upgradu sa na upgradovanej replike zálohovať nedá.
5. Ideálne si vopred vyskúšaj manuálny failover na synchrónnu repliku.
6. Cluster-Aware Updating na AG nepoužívaj.

## 2. Poradie

1. **Vypni automatický failover** na všetkých synchrónnych replikách (`FAILOVER_MODE = MANUAL`).
2. Patchuj **asynchrónne** sekundárne repliky.
3. Patchuj **vzdialené synchrónne** sekundárne repliky.
4. Patchuj **lokálne synchrónne** sekundárne repliky.
5. Po každom serveri: over build (`SELECT @@VERSION`, [Identita a konfigurácia](script.php?id=11&s=identita-a-konfiguracia-instancie)) a že je replika znova `SYNCHRONIZED`.
6. **Manuálny failover** na už patchovanú synchrónnu repliku (tá musí byť `SYNCHRONIZED`):

```sql
-- na cieľovej (patchovanej) sekundárnej replike
ALTER AVAILABILITY GROUP [MojaAG] FAILOVER;
```

7. Patchuj **pôvodnú primárnu** (teraz sekundárnu).
8. **Vráť automatický failover** (`FAILOVER_MODE = AUTOMATIC`) a podľa potreby urob druhý failover späť na pôvodnú primárnu.

## 3. Na čo myslieť

- **Readable secondaries:** upgradovaná sekundárka nie je čitateľná, kým primárna neprejde na nový build. Po prvom failoveri prebieha upgrade databáz – vtedy nie sú čitateľné žiadne repliky. Reporty na sekundárke počas okna nepobežia.
- **Jediná vzdialená async replika (DR):** patchni ju, prepni na synchrónny commit, počkaj na `SYNCHRONIZED`, failover, patchni lokálnu, failover späť, vráť async. Synchrónny commit cez WAN zvyšuje latenciu – rob to mimo špičky.
- **Distribuované AG:** najprv sekundárky downstream AG, failover forwardera, zvyšok downstream, failover globálnej primárnej, nakoniec upstream – medzi krokmi vždy kontrola synchronizácie.
- **CDC / replikácia** v AG databázach: pozri release notes CU, či netreba `sp_vupgrade_replication` (od SQL Server 2019 CU1 netreba).
- **Zmiešané verzie** sú podporované len počas rolling upgradu – nenechávaj ich dlho.

## 4. Návrat späť (rollback)

- Ak CU spôsobí problém na sekundárke, ešte pred failoverom: odinštaluj CU (Programs and Features → View installed updates) a over synchronizáciu.
- Po failoveri na nový build je návrat zložitejší – databázy už prešli upgradom; preto **failover až po patchnutí všetkých sekundárok** a s overeným plánom.
- Vždy maj pripravené zálohy z kroku 1.

## 5. Po upgrade

- Všetky repliky na **rovnakom builde**, AG `HEALTHY`, automatický failover zapnutý, preferencia záloh vrátená.
- Joby na všetkých replikách (zálohy, údržba) bežia.
- Ak servery evidueš v DeadlockCafe (**Evidencia serverov**, len pre prihlásených), aktualizuj build servera – zmizne upozornenie „N CU pozadu“.

> [!TIP]
> Zapíš si časy failoverov a dĺžku výpadku – nabudúce vieš aplikačnému tímu povedať presné okno.

## Zdroje

- [Upgrade availability group replicas (rolling upgrade)](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/upgrading-always-on-availability-group-replica-instances)