Sdílet prostřednictvím

Repliky pro čtení na flexibilním serveru Azure Database for PostgreSQL

  • Článek

PLATÍ PRO: Flexibilní server Azure Database for PostgreSQL

Funkce repliky pro čtení umožňuje replikovat data z instance flexibilního serveru Azure Database for PostgreSQL do repliky jen pro čtení. Repliky se aktualizují asynchronně pomocí nativní technologie fyzické replikace modulu PostgreSQL. Výchozím provozním režimem je replikace streamování s využitím slotů replikace. V případě potřeby se k zachytávání používá přesouvání protokolů na základě souborů. Z primárního serveru můžete replikovat až do pěti replik.

Repliky jsou nové servery, které spravujete podobně jako běžné instance flexibilních serverů Azure Database for PostgreSQL. Pro každou repliku pro čtení se vám účtuje zřízený výpočetní výkon ve virtuálních jádrech a úložišti v GB/měsíc.

Naučte se vytvářet a spravovat repliky.

Kdy použít repliku pro čtení

Funkce repliky pro čtení pomáhá zvýšit výkon a zlepšit škálování úloh náročných na čtení. Úlohy čtení je možné izolovat do replik a úlohy zápisu je možné směrovat na primární server. Repliky pro čtení je možné nasadit také v jiné oblasti a v případě potřeby zotavení po havárii je možné je zvýšit na server pro čtení i zápis.

Typickým scénářem je mít úlohy BI a analytické úlohy, které repliku pro čtení používají jako zdroj dat pro vytváření sestav.

Vzhledem k tomu, že jsou repliky jen pro čtení, nesnižují přímo kapacitu zápisu na primárním serveru.

Důležité informace

Repliky pro čtení jsou primárně určené pro scénáře, kdy je snižování zátěže dotazů přínosné a je možné je spravovat mírné prodlevy. Jsou optimalizované tak, aby poskytovaly aktualizace téměř v reálném čase z primárního serveru pro většinu úloh a představují vynikající řešení pro scénáře náročné na čtení. Je ale důležité si uvědomit, že nejsou určené pro scénáře synchronní replikace, které vyžadují až minutovou přesnost dat. Zatímco data v replice se nakonec stanou konzistentní s primárním serverem, může dojít ke zpoždění, které se obvykle pohybuje od několika sekund do minut a v některých scénářích s vysokou latencí nebo vysokou latencí může toto zpoždění prodloužit na hodiny. Repliky pro čtení ve stejné oblasti jako primární mají obvykle menší prodlevu než geografické repliky, protože druhá z nich často řeší latenci vyvolanou geografickou vzdáleností. Další informace o dopadu geografické replikace na výkon najdete v článku o geografické replikaci . Data na replice nakonec budou konzistentní s daty na primárním serveru. Tuto funkci použijte pro úlohy, kterým toto zpoždění nevadí.

Poznámka:

Pro většinu úloh repliky pro čtení nabízejí replikaci aktualizací z primárního serveru téměř v reálném čase. V případě trvalých primárních úloh náročných na zápis však může prodleva replikace i nadále růst a může být schopná dohnat pouze primární úlohy. To může také zvýšit využití úložiště na primárním serveru, protože soubory WAL se odstraní pouze jednou přijaté v replice. Pokud tato situace přetrvává, odstranění a opětovné vytvoření repliky pro čtení po dokončení úloh náročných na zápis, můžete repliku vrátit zpět do dobrého stavu pro prodlevu. Repliky pro asynchronní čtení nejsou pro takové úlohy náročné na zápis vhodné. Při vyhodnocování replik pro čtení pro vaši aplikaci monitorujte prodlevu repliky pro kompletní cyklus úloh aplikace ve špičce i mimo špičku, abyste posoudili možnou prodlevu a očekávané RTO/RPO v různých bodech cyklu úloh.

Vytvoření repliky

Primární server pro flexibilní server Azure Database for PostgreSQL je možné nasadit v libovolné oblasti, která tuto službu podporuje. Repliky primárního serveru můžete vytvořit ve stejné oblasti nebo v různých globálních oblastech Azure, ve kterých je k dispozici flexibilní server Azure Database for PostgreSQL. Možnost vytvářet repliky se teď rozšiřuje na některé speciální oblasti Azure. Seznam speciálních oblastí, ve kterých můžete vytvářet repliky, najdete v článku o geografické replikaci .

Když spustíte pracovní postup vytvoření repliky, vytvoří se prázdná instance flexibilního serveru Azure Database for PostgreSQL. Nový server je naplněn daty na primárním serveru. Při vytváření replik ve stejné oblasti se používá přístup k snímkům. Proto je čas vytvoření nezávislý na velikosti dat. Geografické repliky se vytvářejí pomocí základní zálohy primární instance, která se pak přenáší přes síť; proto může doba vytváření v závislosti na primární velikosti v závislosti na primární velikosti být v rozsahu od minut až po několik hodin.

Replika se považuje za úspěšně vytvořenou pouze při splnění dvou podmínek: do repliky se musí zkopírovat celá záloha primární instance a transakční protokoly se musí synchronizovat s maximálně 1 GB prodlevou.

Pokud chcete dosáhnout úspěšné operace vytvoření, vyhněte se vytváření replik v době vysokého transakčního zatížení. Měli byste se například vyhnout vytváření replik při migraci z jiných zdrojů na flexibilní server Azure Database for PostgreSQL nebo během náročných operací hromadného zatížení. Pokud migrujete data nebo načítáte velké objemy dat, je nejlepší tuto úlohu dokončit jako první. Po dokončení můžete začít nastavovat repliky. Po dokončení migrace nebo hromadného načtení zkontrolujte, jestli se velikost transakčního protokolu vrátila do normální velikosti. Velikost transakčního protokolu by se obvykle měla blížit hodnotě definované v parametru serveru max_wal_size pro vaši instanci. Využití úložiště transakčních protokolů můžete sledovat pomocí metriky Využité úložiště transakčních protokolů, která poskytuje přehled o velikosti úložiště používaného transakčním protokolem. Monitorováním této metriky můžete zajistit, aby velikost transakčního protokolu byla v očekávaném rozsahu a aby bylo možné spustit proces vytvoření repliky.

Důležité

Repliky pro čtení se v současné době podporují pro výpočetní úrovně serveru pro obecné účely a optimalizováno pro paměť. Výpočetní úroveň nárazového serveru není podporována.

Důležité

Při provádění operací vytváření, odstraňování a povýšení repliky primární server přejde do stavu aktualizace. Během této doby nebudou k dispozici operace správy serveru, jako je úprava parametrů serveru, změna možností vysoké dostupnosti nebo přidání nebo odebrání bran firewall. Je důležité si uvědomit, že stav aktualizace má vliv jenom na operace správy serveru a nemá vliv na operace roviny dat. To znamená, že váš databázový server zůstane plně funkční a bude moct přijímat připojení a obsluhovat provoz čtení a zápisu.

Přečtěte si, jak vytvořit repliku pro čtení na webu Azure Portal.

Správa konfigurace

Při nastavování replik pro čtení pro flexibilní server Azure Database for PostgreSQL je důležité pochopit konfigurace serveru, které je možné upravit, zděděné z primárního serveru a všechna související omezení.

Zděděné konfigurace

Při vytvoření repliky pro čtení dědí konkrétní konfigurace serveru z primárního serveru. Tyto konfigurace je možné změnit buď během vytváření repliky, nebo po jeho nastavení. Konkrétní nastavení, jako je geografická záloha, se ale do repliky pro čtení nereplikují.

Konfigurace během vytváření repliky

  • Velikost úložiště: U operace "Zvýšení úrovně na primární server" musí být stejná jako u primárního serveru. Operace "Zvýšit úroveň na nezávislý server a odebrat z replikace" může být stejná nebo vyšší než primární server.
  • Úroveň výkonu (IOPS): Nastavitelná.
  • Šifrování dat: Nastavitelné, zahrnují přesun z klíčů spravovaných službou na klíče spravované zákazníkem.

Konfigurace po vytvoření

  • Pravidla brány firewall: Lze přidat, odstranit nebo upravit.
  • Velikost úložiště: U operace "Zvýšení úrovně na primární server" musí být stejná jako u primárního serveru. Operace "Zvýšit úroveň na nezávislý server a odebrat z replikace" může být stejná nebo vyšší než primární server.
  • Úroveň výkonu (IOPS): Nastavitelná.
  • Metoda ověřování: Nastavitelné, možnosti zahrnují přepnutí z ověřování PostgreSQL na Microsoft Entra.
  • Parametry serveru: Většina je nastavitelná. Ty, které mají vliv na velikost sdílené paměti, by však měly odpovídat primárnímu, zejména pro potenciální scénáře "povýšení na primární server". U operace "Zvýšit úroveň na nezávislý server a odebrat z replikace" by tyto parametry měly být stejné nebo by měly být vyšší než parametry v primárním serveru.
  • Plán údržby: Nastavitelné.

Nepodporované funkce replik pro čtení

Některé funkce jsou omezené na primární servery a není možné je nastavit na replikách pro čtení. Tady jsou některé z nich:

  • Zálohy, včetně geografických záloh.
  • Vysoká dostupnost

Pokud je zdrojová instance flexibilního serveru Azure Database for PostgreSQL šifrovaná pomocí klíčů spravovaných zákazníkem, přečtěte si dokumentaci k dalším aspektům.

Připojení k replice

Při vytváření repliky dědí pravidla brány firewall nebo koncový bod služby virtuální sítě primárního serveru. Tato pravidla se můžou během vytváření repliky a kdykoli později změnit.

Replika dědí účet správce z primárního serveru. Všechny uživatelské účty na primárním serveru se replikují do replik pro čtení. K replice pro čtení se můžete připojit jenom pomocí uživatelských účtů dostupných na primárním serveru.

Existují dvě metody připojení k replice:

  • Přímo k instanci repliky: K replice se můžete připojit pomocí názvu hostitele a platného uživatelského účtu, stejně jako v běžné instanci flexibilního serveru Azure Database for PostgreSQL. Pro server s názvem myreplica s uživatelským jménem správce myadmin se můžete připojit k replice pomocí:psql
psql -h myreplica.postgres.database.azure.com -U myadmin postgres

Na příkazovém řádku zadejte heslo k uživatelskému účtu.

K usnadnění procesu připojení navíc azure Portal poskytuje připravené připojovací řetězec. Najdete je na stránce Připojit . Zahrnují proměnné libpq i připojovací řetězec přizpůsobené pro konzoly Bash.

  • Prostřednictvím virtuálních koncových bodů: Existuje alternativní metoda připojení pomocí virtuálních koncových bodů, jak je podrobně popsáno v článku o virtuálních koncových bodech . Pomocí virtuálních koncových bodů můžete nakonfigurovat koncový bod jen pro čtení tak, aby konzistentně odkazovali na repliku bez ohledu na to, který server aktuálně obsahuje roli repliky.

Monitorování replikace

Funkce repliky pro čtení na flexibilním serveru Azure Database for PostgreSQL závisí na mechanismu slotů replikace. Hlavní výhodou slotů replikace je, že automaticky upraví počet transakčních protokolů (segmentů WAL) vyžadovaných všemi servery repliky. To pomáhá zabránit tomu, aby se repliky nesynchronizují, protože zabraňuje odstranění segmentů WAL na primárním serveru před jejich odesláním do replik. Nevýhodou přístupu je riziko, že na primárním serveru v případě, že slot replikace zůstane po delší dobu neaktivní. Vtakovýchch Když využití úložiště dosáhne 95 % nebo pokud je dostupná kapacita menší než 5 GiB, server se automaticky přepne do režimu jen pro čtení, aby nedocházelo k chybám spojeným s plnými situacemi na disku.
Monitorování prodlevy replikace a stavu slotů replikace je proto zásadní pro repliky pro čtení.

Doporučujeme nastavit pravidla upozornění pro využité úložiště nebo procento úložiště a prodlevy replikace, pokud překročí určité prahové hodnoty, abyste mohli aktivně jednat, zvětšit velikost úložiště a odstranit opožděné repliky pro čtení. Můžete například nastavit upozornění, pokud procento úložiště překročí 80 % využití a pokud prodleva repliky je vyšší než 5 minut. Metrika Využité úložiště transakčních protokolů ukazuje, jestli je akumulace souborů WAL hlavním důvodem nadměrného využití úložiště.

Flexibilní server Azure Database for PostgreSQL poskytuje dvě metriky pro monitorování replikace. Dvě metriky jsou maximální prodleva fyzické replikace a prodleva repliky pro čtení. Informace o tom, jak tyto metriky zobrazit, najdete v části Monitorování repliky článku s postupy repliky pro čtení.

Metrika Max Physical Replication Lag zobrazuje prodlevu v bajtech mezi primární a nejvíce zpožděnou replikou. Tato metrika je použitelná a dostupná pouze na primárním serveru a bude dostupná jenom v případě, že je k primárnímu serveru připojena aspoň jedna z replik pro čtení. Informace o prodlevě se vyskytují také v případě, že replika probíhá v procesu zachycení primární repliky, během vytváření repliky nebo když je replikace neaktivní.

Metrika Prodleva repliky čtení zobrazuje čas od poslední přehrání transakce. Pokud například na primárním serveru nedochází k žádným transakcím a poslední transakce se přehrála před 5 sekundami, prodleva repliky čtení ukazuje 5sekundové zpoždění. Tato metrika je použitelná a dostupná jenom na replikách.

Nastavte upozornění, které vás informuje, když prodleva repliky dosáhne hodnoty, která není pro vaši úlohu přijatelná.

Pokud chcete získat další přehled, dotazujte se přímo na primární server a získejte prodlevu replikace na všech replikách.

Poznámka:

Pokud se primární server nebo replika pro čtení restartuje, čas potřebný k restartování a zachycení se projeví v metrice Replica Lag.

Stav replikace

Pokud chcete monitorovat průběh a stav operace replikace a zvýšení úrovně, na webu Azure Portal se podívejte na sloupec Stav replikace. Tento sloupec se nachází na stránce replikace a zobrazuje různé stavy, které poskytují přehled o aktuální podmínce replik pro čtení a jejich propojení s primárním serverem. Pro uživatele, kteří se spoléhají na rozhraní API Azure Resource Manageru, se při vyvolání GetReplica rozhraní API zobrazí stav v kontejneru replica vlastností jako ReplicationState.

Tady jsou možné hodnoty:

Stav replikace Popis Zvýšit pořadí Pořadí vytvoření repliky pro čtení
Překonfigurování Čeká se na zahájení primárního propojení repliky. Pokud replika nebo její oblast například není dostupná kvůli havárii, může zůstat delší. 0 –
Zajišťování Replika pro čtení se zřizuje a replikace mezi těmito dvěma servery se ještě musí spustit. Dokud se zřizování nedokončí, nemůžete se připojit k replice pro čtení. – 0
Aktualizace Konfigurace serveru se připravuje po aktivované akci, jako je povýšení nebo vytvoření repliky pro čtení. 2 2
Zachytávání Soubory WAL se použijí na repliku. Doba trvání této fáze během povýšení závisí na zvolené možnosti synchronizace dat – plánované nebo vynucené. 3 3
Aktivní Stav v pořádku označující, že replika pro čtení byla úspěšně připojena k primárnímu serveru. Pokud jsou servery zastavené, ale byly úspěšně připojeny dříve, stav zůstane aktivní. 4 4
Rozbitý Stav není v pořádku, což značí, že operace povýšení selhala, nebo se replika nemůže z nějakého důvodu připojit k primárnímu serveru. Odstraňte repliku a znovu vytvořte repliku, aby se to vyřešilo. – N/A

Zjistěte, jak monitorovat replikaci.

Důležité informace

Tato část shrnuje důležité informace o funkci repliky pro čtení. Platí následující aspekty.

  • Výkonové operace: Operace napájení, včetně akcí spuštění a zastavení, lze použít na primární i replikované servery. Pokud však chcete zachovat integritu systému, měla by být dodržena konkrétní posloupnost. Před zastavením replik pro čtení se nejprve ujistěte, že je primární server zastavený. Při zahájení operací před spuštěním primárního serveru zahajte akci spuštění na serverech repliky.
  • Pokud server obsahuje repliky pro čtení, před odstraněním primárního serveru by se měly nejprve odstranit repliky pro čtení.
  • Místní upgrade hlavní verze na flexibilním serveru Azure Database for PostgreSQL vyžaduje odebrání všech replik pro čtení, které jsou na serveru aktuálně povolené. Po odstranění replik je možné primární server upgradovat na požadovanou hlavní verzi. Po dokončení upgradu můžete repliky vytvořit znovu a obnovit tak proces replikace.
  • Ssd úrovně Premium v2: Od aktuální verze se v případě, že primární server používá pro úložiště disk SSD úrovně Premium v2, nepodporuje se vytváření replik pro čtení.
  • Resetování hesla správce: Resetování hesla správce na serveru repliky se v současné době nepodporuje. Aktualizace hesla správce spolu s povýšením operace repliky ve stejné žádosti se navíc nepodporuje. Pokud to chcete udělat, musíte nejprve zvýšit úroveň serveru repliky a pak aktualizovat heslo na nově propagovaný server samostatně.

Nové repliky

Replika pro čtení se vytvoří jako nová instance flexibilního serveru Azure Database for PostgreSQL. Existující server nejde vytvořit do repliky. Repliku jiné repliky pro čtení nemůžete vytvořit, to znamená, že kaskádová replikace není podporovaná.

Přesun prostředků

Uživatelé mohou vytvářet repliky pro čtení v jiné skupině prostředků než primární. Přesunutí replik pro čtení do jiné skupiny prostředků po jejich vytvoření však není podporováno. Kromě toho přesun replik do jiného předplatného a přesunutí primární repliky s replikami pro čtení do jiné skupiny prostředků nebo předplatného se nepodporuje.

Automatické zvětšování úložiště

Při konfiguraci replik pro čtení pro instanci flexibilního serveru Azure Database for PostgreSQL je nezbytné zajistit, aby nastavení automatického zvětšování úložiště na replikách odpovídalo nastavení primárního serveru. Funkce automatického zvětšování úložiště umožňuje, aby se úložiště databáze automaticky zvýšilo, aby se zabránilo výpadku místa, což by mohlo vést k výpadkům databáze. Tady je postup, jak efektivně spravovat nastavení automatického zvětšování úložiště:

  • Automatické zvětšení úložiště můžete povolit na libovolné replice bez ohledu na nastavení primárního serveru.
  • Pokud je na primárním serveru povolená funkce automatického zvětšování úložiště, musí být na replikách také povolená, aby se zajistila konzistence v chování škálování úložiště.
  • Pokud chcete povolit automatické zvětšování úložiště na primárním serveru, musíte ho nejprve povolit na replikách. Toto pořadí operací je zásadní pro zachování integrity replikace.
  • Pokud chcete naopak zakázat automatické zvětšování úložiště, začněte tím, že ho před replikami zakážete na primárním serveru, abyste se vyhnuli komplikacím replikace.

Zálohování a obnovení

Při správě záloh a obnovení pro instanci flexibilního serveru Azure Database for PostgreSQL je důležité mít na paměti aktuální a předchozí roli serveru v různých scénářích povýšení. Tady jsou klíčové body, které je potřeba si zapamatovat:

Zvýšení úrovně na primární server

  1. Z replik pro čtení se nepřebývají žádné zálohy: Zálohy se nikdy nepřebíjí ze serverů replik pro čtení bez ohledu na jejich předchozí roli.

  2. Zachování minulých záloh: Pokud byl server jednou primárním serverem a během tohoto období se zálohy provedly, tyto zálohy se zachovají. Zachovají se až do doby uchovávání definované uživatelem.

  3. Omezení operace obnovení: I když existují předchozí zálohy pro server, který přešel na repliku pro čtení, operace obnovení jsou omezené. Operaci obnovení můžete zahájit pouze v případech, kdy byl server povýšen zpět na primární roli.

Pro přehlednost je tady tabulka, která znázorňuje tyto body:

Role serveru Pořízené zálohování Obnovení povoleno
Primární Ano Yes
Replika pro čtení No Ne
Replika pro čtení povýšená na primární Ano Yes

Zvýšení úrovně na nezávislý server a odebrání replikace

Zatímco je server replikou pro čtení, nejsou pořízeny žádné zálohy. Po povýšení na nezávislý server se ale zazálohuje jak upřednostněný server, tak primární server se zálohují a obnovení jsou povolená na obou serverech.

Sítě

Repliky pro čtení podporují všechny možnosti sítě podporované flexibilním serverem Azure Database for PostgreSQL.

Důležité

Obousměrná komunikace mezi primárním serverem a replikami pro čtení je zásadní pro nastavení flexibilního serveru Azure Database for PostgreSQL. Musí existovat zřízení pro odesílání a příjem provozu na cílovém portu 5432 v podsíti virtuální sítě Azure.

Výše uvedený požadavek usnadňuje nejen proces synchronizace, ale také zajišťuje správné fungování mechanismu povýšení, kdy repliky můžou potřebovat komunikovat v obráceném pořadí – od repliky k primární – zejména během povýšení na primární operace. Kromě toho musí být připojení k účtu úložiště Azure, který ukládá archivy WAL (Write-Ahead Logging), povolena k zachování stálosti dat a umožnění efektivních procesů obnovení.

Další informace o konfiguraci privátního přístupu (integrace virtuální sítě) pro repliky pro čtení a vysvětlení důsledků replikace mezi oblastmi Azure a virtuálními sítěmi v kontextu privátní sítě najdete v tématu Replikace mezi oblastmi Azure a virtuálními sítěmi se stránkou privátní sítě .

Zmírnění potíží s slotem replikace

Ve výjimečných případech může vysoká prodleva způsobená sloty replikace vést ke zvýšení využití úložiště na primárním serveru kvůli kumulovaným souborům WAL. Pokud využití úložiště dosáhne 95 % nebo dostupná kapacita klesne pod 5 GiB, server se automaticky přepne do režimu jen pro čtení, aby se zabránilo chybám na disku.

Vzhledem k tomu, že udržování stavu a funkčnosti primárního serveru je prioritou, může se v takových hraničních případech vynechat slot replikace, aby primární server zůstal funkční pro provoz čtení a zápisu. Replikace se tedy přepne do režimu přesouvání protokolu založeného na souborech, což může vést k vyšší prodlevě replikace.

Před eskalacemi je nezbytné monitorovat využití úložiště a prodlevu replikace a provádět nezbytné akce ke zmírnění potenciálních problémů.

Parametry serveru

Při vytvoření repliky pro čtení dědí parametry serveru z primárního serveru. To zajistí konzistentní a spolehlivý výchozí bod. Všechny změny parametrů serveru na primárním serveru provedené po vytvoření repliky pro čtení se ale automaticky nereplikují. Toto chování nabízí výhodu individuálního ladění repliky pro čtení, například zvýšení výkonu operací náročných na čtení beze změny parametrů primárního serveru. I když to poskytuje flexibilitu a možnosti přizpůsobení, vyžaduje také pečlivou a ruční správu, aby se zachovala konzistence mezi primárním serverem a jeho replikou, pokud je vyžadována jednotnost parametrů serveru.

Správci můžou změnit parametry serveru na serveru repliky pro čtení a nastavit jiné hodnoty než na primárním serveru. Jedinou výjimkou jsou parametry, které mohou ovlivnit obnovení repliky, uvedené také v části "Škálování" níže: max_connections, , max_prepared_transactionsmax_locks_per_transaction, max_wal_senders, . max_worker_processes Aby se zajistilo, že obnovení repliky pro čtení je bezproblémové a nenarazí na omezení sdílené paměti, měly by být tyto konkrétní parametry vždy nastaveny na hodnoty, které jsou ekvivalentní nebo větší než ty nakonfigurované na primárním serveru.

Měřítko

Můžete vertikálně navýšit nebo snížit kapacitu výpočetních prostředků (virtuálních jader), změnit úroveň služby z úrovně Pro obecné účely na Optimalizováno pro paměť (nebo naopak) a vertikálně navýšit kapacitu úložiště, ale platí následující upozornění.

Škálování výpočetních prostředků:

  • Flexibilní server Azure Database for PostgreSQL vyžaduje, aby několik parametrů na replikách bylo větší nebo rovno nastavení na primárním serveru, aby se zajistilo, že replika během obnovení nevyčerchá sdílenou paměť. Ovlivněné parametry: max_connections, max_prepared_transactions, max_locks_per_transactionmax_wal_senders, , max_worker_processes.

  • Vertikální navýšení kapacity: Nejprve vertikálně navyšte kapacitu výpočetních prostředků repliky a pak vertikálně navyšte kapacitu primární kapacity.

  • Vertikální snížení kapacity: Nejprve vertikálně snížit kapacitu výpočetních prostředků primárního serveru a pak vertikálně snížit kapacitu repliky.

  • Výpočty na primárním serveru musí být vždy stejné nebo menší než výpočetní prostředky na nejmenší replice.

Škálování úložiště:

  • Vertikální navýšení kapacity: Nejprve vertikálně navyšte kapacitu úložiště repliky a pak vertikálně navyšte kapacitu primárního úložiště.

  • Velikost úložiště na primárním serveru musí být vždy stejná nebo menší než velikost úložiště na nejmenší replice.

Související obsah