Typer av reservationer. Kylreserv – rpo rto

Lämna en kommentar 6,950

Föreställ dig att ditt datacenter (eller stridsserver) kraschade idag. Han bara tog den och föll. Som praktiken visar är inte alla redo för detta:

93 % av företagen som förlorade sitt datacenter i 10 dagar eller mer på grund av en katastrof gick i konkurs inom ett år (National Archives & Records Administration i Washington)
140 000 hårddiskar går sönder i USA varje vecka (Mozy Online Backup)
75 % av företagen har inga katastrofåterställningslösningar (Forrester Research, Inc.)
34 % av företagen testar inte säkerhetskopior.
77 % av de som testade hittade oläsbara enheter i sina bibliotek.

I tidigare inlägg (ett och två) skrev jag om organisatoriska åtgärder som ska påskynda och underlätta återställningen av IT-system och relaterade företagsprocesser under nödsituation.

Låt oss nu prata om tekniska lösningar vem hjälper till med detta. Deras kostnad varierar från flera tusen till hundratusentals dollar.

Hög tillgänglighet och katastrofåterställning

Mycket ofta förväxlas lösningar för hög tillgänglighet (HA - High Availability) och katastrofåterställning (DR - Disaster Recovery). Först och främst, när vi talar om kontinuitet menar vi en backup-sajt. I relation till IT – backup datacenter. Affärskontinuitet handlar inte om backup till ett bibliotek i nästa rack (vilket också är väldigt viktigt). Detta innebär att företagets huvudbyggnad kommer att brinna ner och om några timmar eller dagar kommer vi att kunna återuppta arbetet och vända på en ny plats:
Detta innebär att ett backup-datacenter behövs. Vad är alternativen? Vanligtvis finns det tre: varma, varma och kalla reserver.

Kallreserv

Cold reserve innebär att det finns ett visst serverrum där du kan ta med utrustning och distribuera den där. Under restaurering kan det vara planerat att köpa hårdvara eller lagra den i ett lager. Du måste ta hänsyn till att de flesta system levereras på beställning, och du kan snabbt hitta dussintals enheter av servrar, lagringssystem, switchar, etc. kommer att vara en icke-trivial uppgift. Som ett alternativ till att lagra utrustning i egen regi kan du överväga att lagra din viktigaste eller sällsynta utrustning i dina leverantörers lager. Samtidigt måste telekommunikationskanaler finnas i lokalerna, men ingåendet av ett avtal med leverantören sker vanligtvis efter att beslut fattats om att lansera ett "kallt" datacenter. Att återställa driften i ett sådant datacenter i händelse av ett katastrofalt fel på huvudplatsen kan mycket väl ta flera veckor. Se till att ditt företag kan överleva dessa några veckor utan IT och inte tappa affärer (på grund av licensåterkallelse, eller ett irreparabelt kassagap, till exempel) – jag skrev om detta tidigare. Ärligt talat skulle jag inte rekommendera detta bokningsalternativ till någon. Jag kanske överdriver IT:s roll i vissa företags verksamhet.

Varm reserv

Det betyder att vi har en alternativ plattform som har aktivt internet och WAN-länkar, central telekommunikation och datorinfrastruktur. Den är alltid "svagare" än den huvudsakliga beräkningskraft, viss utrustning kanske inte finns där. Det viktigaste är att det alltid finns en uppdaterad säkerhetskopia av data på sajten. Med den gammaldags metoden kan du organisera regelbunden överföring av säkerhetskopior på band dit. Modern metod– replikering av säkerhetskopior över nätverket från huvuddatacentret. Genom att använda säkerhetskopiering med deduplicering kan du snabbt överföra säkerhetskopior även över en "tunn" kanal mellan datacenter.

Varm standby

Här är den, ett urval tuffa killar som stödjer IT-system, vars stillestånd även under några timmar medför stora förluster för företaget. Det finns all nödvändig utrustning för full drift av IT-system. Vanligtvis är grunden för en sådan plats ett datalagringssystem, på vilket data från huvuddatacentret speglas synkront eller asynkront. För att den heta reserven vid timme X ska kunna tjäna tillbaka pengarna som investerats i den, måste regelbundna testöverföringar av system utföras, inställningarna och OS-versionen av servrarna på huvud- och backupsajterna måste ständigt synkroniseras - manuellt eller automatiskt.

Nackdelen med varm och varm reserv är att dyr utrustning står inaktiv och väntar på en katastrof. Vägen ut ur denna situation är distribuerad datacenterstrategi. Med det här alternativet har två (eller flera) plattformar lika rättigheter - de flesta applikationer kan köras på både den ena och den andra. Detta gör att du kan använda kraften i all utrustning och säkerställa lastbalansering. Kraven på att automatisera överföringen av IT-tjänster mellan datacenter ökar däremot rejält. Om båda datacentren är ”combat” har verksamheten rätt att förvänta sig att om belastningen på en av applikationerna förväntas toppa så kan den snabbt överföras till ett friare datacenter. Oftast finns det i sådana datacenter synkron replikering mellan lagringssystem, men lätt asynkronisering är också möjlig (inom några minuter).

Tre magiska ord

Innan jag går direkt till katastrofbeständighetsteknologier för IT-tjänster, låt mig påminna dig om de tre "magiska" orden som bestämmer kostnaden för alla DR-lösningar: RTO, RPO, RCO.

RTO (Recovery Time Objective) – den tid under vilken det är möjligt att återställa ett IT-system
RPO (Recovery Point Objective) - hur mycket data kommer att gå förlorade under katastrofåterställning
RCO (Recovery capacity goal) - vilken del av lasten som ska tillhandahållas av backupsystemet. Denna indikator kan mätas i procent, IT-systemtransaktioner och andra kvantiteter.

RPO

Den första uppdelningen vi kan göra mellan alla olika IT-lösningar för att säkerställa katastrofresiliens är om de ger noll RPO eller inte. Ingen dataförlust under fel säkerställs genom synkron replikering. Oftast görs detta på lagringssystemnivå, men det kan också implementeras på DBMS- eller servernivå (med hjälp av avancerad LVM). I det första fallet får servern ingen bekräftelse från lagringssystemet som den fungerar med att skrivningen lyckades förrän lagringssystemet har överfört denna transaktion till det andra systemet och fått bekräftelse från det att skrivningen lyckades.

100 % av lagringssystemen tillhör mellanprissegmentet och vissa system kan göra synkron replikering nybörjarnivå från välkända leverantörer. Kostnaden för licenser för synkron replikering på "enkla" lagringssystem börjar från flera tusen dollar. Programvara för replikering på servernivå för 2-3 servrar kostar ungefär lika mycket. Om du inte har ett befintligt backupdatacenter, glöm inte att lägga till kostnaden för att köpa backuputrustning.

RPO på några minuter kan tillhandahållas genom asynkron replikering på lagringssystemnivå, servervolymhanteringsprogram (LVM - Logical volume manager) eller DBMS. Fram till nu är en standby-kopia av databasen en av de mest populära lösningarna för DR. Oftast är funktionen "loggfrakt", som DBMS-administratörer kallar det, inte separat licensierad av tillverkaren. Om du har en licensierad databas, replikera för gott. Kostnaden för asynkron replikering för servrar och lagringssystem skiljer sig inte från synkron replikering, se föregående stycke.

Om vi pratar om RPO på flera timmar, är det oftare replikering av säkerhetskopior från en plats till en annan. De flesta diskbibliotek kan göra detta, en del av programvaran för Reserv exemplar- Samma. Som jag redan sa, kommer deduplicering att hjälpa mycket med detta alternativ. Du kommer inte bara att ladda kanalen mindre genom att överföra säkerhetskopior, utan du kommer också att göra det mycket snabbare - varje överförd säkerhetskopia kommer att ta tiotals eller hundratals gånger kortare tid än i verkligheten. Å andra sidan måste vi komma ihåg att den första säkerhetskopieringen under deduplicering fortfarande måste överföra mycket unik data till systemet. Du kommer att se "riktig" deduplicering efter en veckolång säkerhetskopieringscykel. När du synkroniserar diskbibliotek - samma sak. Om den beräknade överföringstiden med din kanalbredd mellan datacenter är flera dagar eller till och med veckor (vilket kan kosta mycket), är det vettigt att först installera det andra biblioteket i närheten, utföra synkronisering och ta det till backupdatacentret.

Synkronisering av säkerhetskopior mellan datacenter

RTO

När uppgiften är att minimera återhämtningstiden ( RTO), bör processen vara så dokumenterad och automatiserad som möjligt. En av de bästa och mest universella lösningar– HA-kluster med geografiskt spridda noder. Oftast är sådana lösningar baserade på lagringsreplikering, men andra alternativ är också möjliga. Ledande produkter inom detta område, till exempel Symantec Veritas Cluster, inkluderar moduler för att arbeta med lagringssystem som byter replikeringsriktning när det är nödvändigt att starta om tjänsten på backupnoden. För mindre avancerade kluster (till exempel Microsoft Cluster Services, inbyggda i Windows) erbjuder de största lagringssystemtillverkarna (IBM, EMC, HP) tillägg som gör ett vanligt HA-kluster till ett katastroftolerant sådant.

Geografiskt fördelat kluster

Sällan tänker någon på intressant funktion De allra flesta datareplikeringslösningar är "one-shot". Du kan bara få ett datatillstånd på säkerhetskopieringsplatsen. Om systemet med dessa data inte startar av någon anledning går vi vidare till plan "B". Oftast är detta en återhämtning från säkerhetskopiering med stora dataförluster. Av de tekniker jag listade skulle det enda undantaget vara replikering av samma säkerhetskopior. Svaret här är att använda klassen Continuous Data Protection-lösningar. Deras kärna är att alla poster som kommer från servern är märkta och lagrade i en specifik journalvolym på backupplatsen. När du återställer systemet kan du välja vilken punkt som helst från den här loggen och få tillståndet inte bara vid tidpunkten för olyckan där data skadades, utan också på några sekunder. Sådana lösningar skyddar mot ett internt hot – radering av data från användare. När det gäller replikering av lagringssystem spelar det ingen roll vad som ska överföras - en tom volym eller din mest kritiska databas. När du använder CDP kan du välja ett ögonblick precis innan informationen raderades och återställa till den. CDP-system kostar vanligtvis tiotusentals dollar. Ett av de mest framgångsrika exemplen, enligt min mening, är EMC RecoverPoint.

Lösningsdiagram baserat på RecoverPoint

I Nyligen system blir allt populärare lagringsvirtualisering. Förutom deras huvudfunktion - att kombinera arrayer från olika leverantörer till en enda pool av resurser - kan de till stor hjälp hjälpa till att organisera ett distribuerat datacenter. Kärnan i lagringsvirtualisering är att ett mellanliggande lager av kontroller uppträder mellan servrar och lagringssystem och skickar all trafik genom dem. Lagringsvolymer presenteras inte direkt till servrar, utan till dessa virtualiserare. De i sin tur delar ut dem till värdarna. I virtualiseringslagret kan man replikera data mellan olika lagringssystem och ofta finns det mer avancerade möjligheter – ögonblicksbilder, multi-level storage etc. Samtidigt är virtualiserarens mest grundläggande funktion den mest nödvändiga för DR-ändamål. Om vi har två lagringssystem i olika datacenter sammankopplade med ett optiskt stamnät, tar vi volymer från var och en av dem och sätter ihop en "spegel" på virtualizernivå. Som ett resultat får vi en virtuell volym för två datacenter, vilket servrarna ser. Om dessa servrar är virtuella börjar Live Migration av virtuella maskiner att fungera och du kan överföra uppgifter mellan datacenter "i farten" - användare kommer inte att märka någonting.

Den fullständiga förlusten av datacentret kommer att hanteras av ett konventionellt HA-kluster i automatiskt läge under några minuter. Virtualisering av distribuerade lagringssystem tillåter kanske minimal återställningstid för de flesta applikationer. För DBMS finns en oöverträffad Oracle RAC och dess analoger, men kostnaden får dig att tänka. SAN virtualisering är inte heller billig ännu, för små volymer Kostnaden för en lagringslösning kan vara mindre än 100 000 USD, men i de flesta fall är priset högre. Enligt min mening är den mest beprövade lösningen IBM SAN Volume Controller (SVC), den mest tekniskt avancerade är EMC VPLEX.

Förresten, om inte alla dina applikationer fortfarande lever kvar virtuell miljö, är det värt att designa ett backup-datacenter för dem virtuella maskiner. För det första kommer det att bli mycket billigare, och för det andra, efter att ha gjort detta som en säkerhetskopia, är det inte långt ifrån att migrera huvudsystemen under kontroll av någon form av hypervisor...

Konkurrensen på marknaden för outsourcing av datacenter gör det mer lönsamt att hyra rackutrymme i en leverantörs datacenter jämfört med att bygga och driva ett eget backupcenter. Om du skriver med honom virtuell infrastruktur, kommer det att bli allvarliga besparingar på hyresbetalningar. Men outsourcing av datacenter är inte längre på höjdpunkten av framsteg. Det är bättre att bygga en backup-infrastruktur direkt i molnet. Datasynkronisering med huvudsystemen kan säkerställas genom replikering på servernivå (det finns en utmärkt familj av DoubleTake-lösningar från Vision Solutions).

Den sista, men mycket viktiga punkten som inte bör glömmas bort när man designar en katastrofbeständig IT-infrastruktur är användararbetsstationer. Att databasen är uppe betyder inte att affärsprocessen har återupptagits. Användaren måste kunna göra sitt jobb. Inte ens ett fullfjädrat backupkontor, med datorer avstängda för nyckelmedarbetare, är en idealisk lösning. En person på en förlorad arbetsplats kan ha referensmaterial, makron m.m. heltidsjobb utan vilken det är omöjligt. För företagets viktigaste användare verkar det rimligt att byta till virtuella skrivbord (VDI). Då lagras ingen data på arbetsstationen (vare sig det är en vanlig PC eller en snygg "tunn" klient), den används endast som en terminal för att nå Windows XP eller Windows 7 som körs på en virtuell maskin i datacentret. Tillgång till en sådan arbetsstation kan enkelt organiseras hemifrån eller från vilken dator som helst i filialnätet. Till exempel, om du har flera byggnader och en av dem är otillgänglig, kan nyckelanvändare komma till ett närliggande kontor och sitta på arbetsstationerna med "mindre nyckel". Sedan loggar de lugnt in i systemet, kommer in i sin virtuella maskin och företaget vaknar till liv!

Sammanfattningsvis, här är nyckelfrågorna att ställa när man utvärderar en DR-lösning:

Vilka misslyckanden skyddar den mot?
Vilken RPO/RTO/RCO tillhandahåller den?
Vad är priset?
Hur svårt är det att operera?

Det finns otaliga katastrofsäkra lösningar - både ur lådan och de som du kan göra praktiskt taget med dina egna händer. Vänligen dela i kommentarerna vad du har och berättelser om hur dessa lösningar hjälpte dig. Om något av systemen som beskrivs ovan eller deras analoger fungerar för dig, lämna feedback om hur lugnt du sover när IT-systemen är under deras skydd.

Vid designstadiet av ett solkraftverk, för att säkerställa den erforderliga tillförlitligheten, är det i många fall nödvändigt att åtminstone duplicera enskilda element och till och med enskilda system, d.v.s. använda reservation.

Redundans kännetecknas av det faktum att den tillåter att öka systemets tillförlitlighet jämfört med tillförlitligheten hos dess beståndsdelar. Att öka tillförlitligheten hos enskilda element kräver stora materialkostnader. Under dessa förhållanden är redundans, till exempel genom införandet av ytterligare element, ett effektivt sätt att säkerställa den erforderliga tillförlitligheten hos systemen.

Om den totala tillförlitligheten för systemet (dvs. sannolikheten för felfri drift) vid seriekoppling av element är lägre än tillförlitligheten för det mest opålitliga elementet, då med redundans, kan systemets totala tillförlitlighet vara högre än tillförlitligheten hos det mest pålitliga elementet.

Redundans uppnås genom att införa redundans. Beroende på den senares karaktär är reservationen:

Strukturell (hårdvara);

Information;

Temporär.

Strukturell redundans ligger i det faktum att ytterligare element, enheter introduceras i den minsta erforderliga versionen av ett system som består av grundläggande element, eller till och med istället för ett system, tillhandahålls användningen av flera identiska system.

Säkerhetskopiering av information innebär användning av överflödig information. Dess enklaste exempel är den upprepade överföringen av samma meddelande över en kommunikationskanal. Ett annat exempel är de koder som används i styrdatorer för att upptäcka och korrigera fel till följd av hårdvarufel och fel.

Tillfällig reservation innebär användning av överskottstid. Att återuppta systemets funktion, avbruten till följd av ett fel, sker genom att det återställs om det finns en viss tid.

Det finns två metoder för att öka systemets tillförlitlighet genom strukturell redundans:

1) allmän redundans, där systemet som helhet är redundant;

2) separat (element-för-element) redundans, där enskilda delar (element) av systemet är reserverade.

Schema med allmän och separat strukturell redundans presenteras i respektive fig. 1. 5.3 och 5.4, där n är antalet på varandra följande element i kretsen, m är antalet reservkretsar (med allmän redundans) eller reservelement för varje huvud (med separat redundans)

När m=1 är det duplicering och när m=2 är det tredubbling. Vanligtvis strävar de efter att använda separat redundans när det är möjligt, eftersom vinsten i tillförlitlighet ofta uppnås till betydligt lägre kostnader än med generell redundans.

Beroende på sättet att inkludera reservdelar skiljer man mellan permanent reservation, ersättningsreservation och glidande reservation.

Permanent reservation – Detta är en reservation där reservelement deltar i driften av anläggningen tillsammans med de viktigaste. I händelse av ett fel på huvudelementet krävs inga speciella enheter för att aktivera reservelementet, eftersom det tas i drift samtidigt med huvudelementet.

Bokning genom ersättning – Detta är en redundans där funktionerna för det primära elementet överförs till säkerhetskopian först efter att huvudelementet misslyckats. När det är redundant genom utbyte behövs övervaknings- och växlingsenheter för att upptäcka fel på huvudelementet och byta från huvudelementet till backupen.

Rullande reservation –är en typ av reservation genom ersättning, där huvudelementen i ett objekt säkerhetskopieras av element, som vart och ett kan ersätta alla misslyckade element.

Båda typerna av reservationer (permanent och ersättning) har sina fördelar och nackdelar.

Fördelen med permanent reservation är dess enkelhet, eftersom i det här fallet krävs inte övervaknings- och omkopplingsanordningar, vilket minskar systemets tillförlitlighet som helhet, och, viktigast av allt, det finns inget avbrott i driften. Nackdelen med konstant redundans är störningen av driftsläget för backupelementen i händelse av fel på de viktigaste.

Att aktivera en reserv genom att byta ut har följande fördel: det stör inte driftsläget för reservelement, bevarar reservelementens tillförlitlighet i större utsträckning och tillåter användning av ett reservelement för flera arbetare (med glidande reservation).

Beroende på reservelementens driftläge skiljer man mellan laddad (varm) och olastad (kall) reserv.

Laddad (het) reserv inom energibranschen kallas det också roterande eller påslaget. I detta läge backup-elementet är i samma läge som huvudelementet. Resursen av reservelement börjar förbrukas från det ögonblick som hela systemet tas i drift, och sannolikheten för felfri drift av reservelement i detta fall beror inte på vid vilken tidpunkt de tas i drift.

Lättvikts (varm) reserv kännetecknas av det faktum att reservelementet är i ett mindre belastat läge än huvudet. Därför, även om resursen för reservelementen också börjar förbrukas från det ögonblick som hela systemet slås på, är hastigheten för resursförbrukningen för reservelementen tills de slås på istället för de misslyckade betydligt lägre än under driftsförhållanden . Denna typ av reserv placeras vanligtvis på enheter som körs på tomgång och därför i I detta fall resursen av reservelement används mindre jämfört med driftsförhållanden när enheterna bär en last Sannolikheten för felfri drift av reservelement i fallet med denna typ av reserv kommer att bero både på tidpunkten för deras aktivering och på hur olika. distributionslagarna för sannolikheten för deras felfria drift är i drift- och reservförhållanden.

När lossad (kall) reserv backup-element börjar konsumera sina resurser från det ögonblick de tas i drift istället för de viktigaste. Inom energisektorn används denna typ av reserv vanligtvis av frånkopplade enheter.

Tillförlitlighetsberäkningar för system med parallellkopplade element beror på redundansmetoden.

SYSTEMTILLFÖRLITLIGHET MED KONSTANT ALLMÄN REDUNDANS

Vi kommer att anta att de reserverade och backup-elementen är lika tillförlitliga, dvs.
Och
. För enkelhetens skull anges sannolikheten för felfri drift och förekomsten av fel på enskilda element med versaler i detta och följande avsnitt.

Med hänsyn till den ekvivalenta kretsen (Figur 5.5) och formeln (5.18), kan sannolikheten för fel i ett system med m reservkretsar beräknas enligt följande:

, (5.22)

Var (t) – sannolikhet för fel på huvudkretsen,
– sannolikhet för fel i den i:te reservkretsen.

Följaktligen är sannolikheten för felfri drift av systemet

(5.23)

I enlighet med formel (5 8) har vi

(5.24)

Med lika sannolikhet för fel i huvud- och reservkretsen
formlerna (5 22) och (5 23) har formen:

, (5.25)

(5.26)

Genomsnittlig systemupptid med allmän redundans

(5.27)

Var – intensitet systemfel,
, – felfrekvens för någon av (m+1) kretsarna, – felfrekvens för det i-te elementet

För ett system med två parallella kretsar (m=1) har formel (5.27) formen:

(5.28)

Den genomsnittliga systemåterställningstiden i det allmänna fallet bestäms av formeln

(5.29)

Var – genomsnittlig återhämtningstid för den i:e kedjan.

För specialfallet m=1 har formeln (5.29) formen:

Exempel 5.2.

Beräkna sannolikheten för felfri drift under 3 månader, felfrekvensen, den genomsnittliga tiden mellan fel i en enkrets luftledning med en längd av l = 35 km tillsammans med en 110/10 kV nedtrappningstransformator och kopplingsutrustning (Figur 5.6).

Den tillförlitlighetsekvivalenta kretsen för SES som övervägs är en sekventiell struktur (Figur 5.7)

Felfrekvensen för element är hämtad från Tabell 3.2:

;

Enligt formel (5.7) bestämmer vi felfrekvensen för strömförsörjningskretsen

Denna beräkning visar att den dominerande inverkan på kretsbrott är skadorna på luftledningen. Medeltid mellan fel i en strömkrets

Sannolikhet för felfri drift av kretsen under t=0,25 år

Exempel 5.3.

Bestäm hur mycket högre tillförlitlighetsindikatorerna för en transformatorstation på 110/10 kV är med konstant gemensam drift av båda transformatorerna under 6 månader jämfört med en transformatorstation med en transformator. Vi försummar byte av enhetsfel och avsiktliga avstängningar.

Initial data hämtad från tabellen. 3.2 är följande:

;

Sannolikhet för felfri drift under 6 månader av en transformator

Genomsnittlig tid mellan fel på en transformator

Sannolikhet för felfri drift av en tvåtransformatorstation, beräknad med formeln (5.20):

Genomsnittlig tid mellan fel i en transformatorstation med två transformatorer, beräknad enligt formel (5.28):

år

Felfrekvens för en transformatorstation med två transformatorer

Genomsnittlig återhämtningstid för en transformatorstation med två transformatorer (se formel (5.30))

Analys av resultaten visar att tillförlitligheten hos en transformatorstation med två transformatorer är mycket högre än tillförlitligheten för en transformatorstation med en transformator.

Exempel 5.4.

Låt oss överväga en 6 kV ställverkssektion, från vilken 18 utgående linjer strömförsörjs (Fig. 5.8). Felfrekvensen för omkopplare som åtföljs av kortslutningar uppskattas av värdet = 0,003
, felfrekvens med

kortslutning för samlingsskenor per anslutning
(se tabell 3 2). Bestäm intensiteten för kortsiktiga inlösen av ställverkssektionen, utgå från den absoluta tillförlitligheten hos den automatiska överföringsomkopplaren (ATI) och Q2-omkopplaren som backar upp sektionens kraft.

Fiberoptik och optoelektronik hitta
Används ofta i konstruktionen av alla nivåer
nätverk
telekommunikation:
huvud
rader
långdistans- och stadskommunikationer, accessnät och
strukturerade kabelsystem.
På grund av vikten av de problem som löses med deras hjälp,
Kraven på tillförlitlighet är mycket höga.
I det här fallet betyder tillförlitlighet
förmåga att stödja överföring av information från
vid en given hastighet och med en given tillförlitlighet i
under den tid som krävs.

Hög nivå av tillförlitlighet av modern
nätverk optisk kommunikation tillhandahålls av genomförandet
komplex olika åtgärder, bland dem en av
de viktigaste är medel för fullständig eller åtminstone
partiell återställning av kommunikationer i nödsituationer
situationer.
Traditionellt
För
detta
applicerad
reservation - en riktad introduktion till
ett system med viss redundans för ändamålet
tillhandahållande
vanligt
fungerar
objekt efter att ett fel uppstår i dess element.

Fiberoptiska kommunikationslinjer behöver
pålitlig reservation. Eftersom de är mottagliga
naturkatastrofer som inträffar i
främst på vintern och i samband med frysning
utrustning eller jord, vilket medför
inre fiberskada eller fel
linjär fiberoptisk utrustning.

Alternativ för att öka nätverkets tillförlitlighet med hjälp av redundans:

Alternativ för att öka nätverkets tillförlitlighet med
locka till sig reservationer:
LINJEBOKNING
SYSTEMBOKNING
WDM-BASERAD BOKNING

LINJEBOKNING:

Nödsituationer i den linjära delen av nätet i
i de flesta fall uppstår på grund av mekaniska
skada (brott) optisk fiber, Det är därför
Den uppenbara lösningen på detta problem är
öka
kvantiteter
tillgängliga
fysisk
överföringsvägar på vilka
byter när ett fel uppstår.

RINGSTRUKTURER
När man bygger fiberoptiska kommunikationsnät används det ofta
ringtopologi för vilken självläkning är naturlig
fast egendom. I de flesta fall den linjära delen av ringstrukturen i nätverk
kommunikation allmänt brukär byggd på basis av ett par fibrer (den sk
dubbelring). Som ett resultat har den sändande noden två alternativ
tillgång till receptionen: medurs och i motsatt riktning. En av
rutter utför huvudfunktionerna och används för att överföra trafik,
den andra betraktas som en backup.
Driftschema för en nätsektion med linjär redundans
a) normalt läge; b) användningssätt för reservatet.

SYSTEMBOKNING:

Organisation
systemisk
reservationer
V
optiskt nätverk innebär samtidig introduktion
ytterligare fibrer i den linjära delen och blockerar in
aktiv transceiverutrustning på noder
nätverk. Om på huvudöverföringsriktningen
ljusledare är skadade eller ett nodfel inträffar
nätverksutrustning och växlar sedan till
backup riktning.
Diagram över en nätverkssektion med systemredundans.

WDM-BASERAD BOKNING

I system med våglängdsmultiplexering, utöver
beskrivs
högre
sätt,
Burk
inse
redundans på optisk nivå. För detta
ytterligare (reserv)våglängder allokeras för
som växlar vid huvudfel
optisk bärare.
CWDM-nätverksredundansschema med fysisk ring
topologi.

10. Beroende på driftsläget för reservelementen innan huvudelementet misslyckas, särskiljs följande typer av reserv:

"het" (laddad) reserv;
"varm" (lätt) reserv;
"kall" (lossad) reserv;

11. 1

12.

För att ersätta ett misslyckat element räcker det
ha en reserv (reserv) vara i lager. dock
varaktighet manuellt byte uppgår till enheter
timmar,
Vad
För
många
system
automatisering
oacceptabelt lång. Minska påtvingad tid
driftstopp tillåter användning av styrenheter och moduler
I/O med löstagbara terminalkontakter
och hot-swappable.

13. "het" reserv

Under hot standby, backup
enheten är strömsatt och i ev
ögonblick redo att ta över
fungerar när dess ingång är påslagen och
gå ut till signalkanalen. I den
resursläge reservenhetär förbrukad
samma som den huvudsakliga. Varm reserv
kallas utrustning som har samma
egenskaper,
Vad
Och
huvud,
parallellkopplad och i drift
samtidigt som henne.

14.

För att säkerställa "het"
tillhandahålla följande:
ersättare
nödvändig
● skydd från statisk elektricitet, som kan
visas på kroppen av den operatör som utför bytet
anordningar;
● erforderlig sekvens av spänningsmatning
strömförsörjning och externa signaler (för detta använder de t.ex
mått, kontakter med kontakter av olika längd och sekvenser
inuti enheten);
● skydd av systemet från överspänning orsakad av laddning
kapacitet för den anslutna enheten, till exempel med hjälp av
strömbegränsningsmotstånd eller en separat källa
näring;
● skydd av enheten från överspänning, kortslutning
kortslutningar,
polaritetsomkastningar,
överstiger
Spänning
ström, heltidsanslutning

15. "kall" reserv

Kall
boka
kallad
Utrustning,
ägande
de där
samma
egenskaper som är desamma som den huvudsakliga, funktionsdugliga och
redo att slås på när som helst, men
fungerar inte samtidigt med den huvudsakliga. På
kall
reservationer
reserv
blockera
helt frånkopplad från strömkällor.
Resursen för reservblocket förbrukas inte
tills blocket slås på.

16.

Grunderna
skillnad
mellan
"varm"
"kall" och "varm" reserv består av
övergångsperiodens varaktighet till reserv.
Med "het" backup av kontroller
växla tidsintervall från enheter
millisekunder till bråkdelar av en sekund, med "varm" -
sekunder, när "kallt" - minuter.

17.

Den huvudsakliga egenskapen hos strukturell
reservation är dess mångfald -
förhållandet mellan antalet redundanta element till
antal reserverade element (huvud),
uttryckt som en oförkortad bråkdel: Hot Spare), ibland slang hotspar- Teknik för redundant elektronisk utrustning, där reserven är ansluten till systemet och ersätter den felaktiga komponenten automatiskt, eller åtminstone utan att avbryta systemets drift. Används oftast för hårddiskar, random access minne datorer. I samband med vissa system kan det helt enkelt kallas "reserv" (vilket antyder att kallbytbara enheter helt enkelt inte är synliga i systemet och inte kräver en speciell term).

Hot reservdelar för lagringssystem

Oftast används hot-swappable diskar i kombination med RAID-arrayer. I det här fallet finns det flera typer av hotspare-skivor:

lokal (engelska) lokal, Engelsk arrayägd) - disken tillhör en specifik array och används endast för att ersätta en defekt disk i given array, om det finns flera arrayer i systemet och en disk misslyckas i en angränsande array, används inte en disk lokal för den andra arrayen för ersättning.
global, allmän global, Engelsk delad) - disken tillhör inte någon array och kan användas för att ersätta en defekt disk i någon av arrayerna. När man kombinerar globala och lokala hotspars finns det två algoritmer för att använda dem: antingen först lokal och sedan global, eller först global och sedan lokal. Det andra alternativet låter dig skapa arrayer med något större tillförlitlighet för utvalda arrayer, det första - för alla.
grupp (engelska) grupp) - i det här fallet kombineras vissa arrayer till en grupp, inom vilken den kan användas backup disk. Arrayer som inte ingår i en grupp tar inte emot den här disken (det här alternativet använder till exempel linux-raid).

Indikation

Vissa system och raid-kontroller kan använda en specifik LED-beteckning (eller speciell sort blinkande lysdiod) för att indikera hett par.

Övervakning av status för en varm reserv

Många system kontrollerar med jämna mellanrum statusen för reservdiskar (genom att läsa eller skriva) för att säkerställa att ersättningsdisken är i gott skick. i gott skick och skydda mot en situation där en disk som lagts till i arrayen istället för en misslyckad visar sig vara felaktig.

Återuppbyggnad av nödsystem

Ofta hårddiskar misslyckas inte helt, utan delvis (inom flera sektorer). Vissa system kan förkopiera data från en delvis påverkad array till en reservenhet innan den berörda enheten tas bort. Dåliga platser byggs om enligt RAID-algoritmer, normala kopieras helt enkelt från en halvdålig disk. Detta minimerar tiden när arrayen är i ett försämrat tillstånd och minskar belastningen (eftersom det inte finns något behov av att räkna om kontrollsummor för hela arrayen).

Alternativ

Kallreserv(enheten kräver manuell anslutning), oftast är detta namnet på reservkomponenter som finns i ett lager nära utrustningen. Ibland isolerad varm reserv, det vill säga komponenter som kräver manuellt byte, men som inte kräver att systemet stoppas (se varmbyte).

se även

Wikimedia Foundation. 2010.

Se vad "Hot reserve" är i andra ordböcker:

Se Hjälplokets körsträcka. Teknisk järnvägsordbok. M.: Statens Transportjärnvägs förlag. N. N. Vasiliev, O. N. Isaakyan, N. O. Roginsky, Ya B. Smolyansky, V. A. Sokovich, T. S. Khachaturov. 1941... Teknisk järnvägsordbok

varm reserv- - Telekommunikationsämnen, grundläggande begrepp EN hot stand byhot standby...

varm reserv- aktyvusis rezervas statusas T sritis Standartizacija ir metrologija apibrėžtis Rezervas, apibūdinamas tuo, kad atsarginiai įtaisai veikia ta pačia veika, kaip ir pagrindiniai įtaisai. atitikmenys: engl. aktiv reserv; laddad reserv vok.… … Penkiakalbis aiškinamasis metrologijos terminų žodynas Teknisk översättarguide

ingår effektreserv för fartygets elkraftsystem- NDP. snurrande reserv varmreserv Skillnaden mellan värdena för den påslagna kraften och belastningen på fartygets elektriska kraftsystem i det aktuella driftläget. [GOST 22652 77] Otillåtet, rekommenderas inte roterande reservvärmeserv ... Teknisk översättarguide

Ingår kraftreserv för fartygets elkraftsystem- 27. Inkluderad effektreserv för fartygets elkraftsystem NDP. Spinningsreserv Varmreserv Skillnaden mellan de påslagna effektvärdena och belastningen av fartygets elektriska kraftsystem i det aktuella driftläget

Termen "hot standby" används för att beskriva möjligheten att ansluta till en server och utföra läsbegäranden medan servern är i backup- eller arkivåterställningsläge. Detta är användbart både för replikeringsändamål och för att återställa önskat tillstånd från en säkerhetskopia med Hög precision. Termen "hot standby" beskriver också förmågan hos en server att övergå från återställningsläge till normal drift medan användare fortsätter att utföra förfrågningar och/eller deras anslutningar förblir öppna.

I hot standby-läge exekveras förfrågningar ungefär som i normalt läge, med vissa skillnader i användning och administration som beskrivs nedan.

26.5.1. Översikt på användarnivå

Transaktioner som körs i varmt vänteläge kan utföra följande kommandon:

Transaktioner som startas i hot standby-läge får aldrig ett transaktions-ID och kan inte skrivas till förskrivningsloggen. Därför, när du försöker utföra följande åtgärder fel kommer att uppstå:

Datamanipuleringskommandon (DML) - INFOGA, UPPDATERA, DELETE, KOPIERA FRÅN, TRUNCATE. Det bör noteras att det inte finns några tillåtna åtgärder som skulle få utlösaren att aktiveras när den körs på standbyservern. Denna begränsning gäller även för temporära tabeller, eftersom tabellrader inte kan läsas eller skrivas utan tillgång till transaktions-ID, vilket för närvarande inte är möjligt i en varm standby-miljö.

Data Definition Commands (DDL) - CREATE, DROP, ALTER, COMMENT. Dessa begränsningar gäller även för temporära tabeller, eftersom operationer kan kräva uppdatering av systemkatalogtabeller.

VÄLJ ... FÖR ATT DELA | UPPDATERA eftersom ett radlås inte kan hållas utan uppdatering av motsvarande datafiler.

Regler för SELECT-satser som resulterar i att DML-kommandon körs.

LÅS som helt klart kräver ett strängare läge än ROW EXCLUSIVE MODE.

LÅS i kort form med standardinställningar, eftersom det kräver EXKLUSIVT LÄGE FÖR ÅTKOMST.

Transaktionskontrollkommandon som uttryckligen kräver icke-skrivskyddat läge

BÖRJA LÄS SKRIV, BÖRJA TRANSAKTION LÄS SKRIV
SÄTTA TRANSAKTION LÄS SKRIV , SÄTT SESSIONS KARAKTERISTIKA SOM TRANSAKTION LÄS SKRIV
SET transaction_read_only = av

De tvåfasiga commit-kommandona är PREPARE TRANSACTION, COMMIT PREPARED, ROLLBACK PREPARED, eftersom även skrivskyddade transaktioner behöver skrivas till WAL i förberedelsefasen (den första fasen av en två-fas commit).

Uppdaterar sekvenser - nextval() , setval()

Under normal transaktionsdrift « bara för att läsa» kan använda kommandona LISTEN och NOTIFY; sålunda fungerar heta standby-sessioner under något större begränsningar än vanliga skrivskyddade sessioner. Det är möjligt att vissa av dessa begränsningar kommer att mildras i framtida utgåvor.

I hot standby-läge är transaktion_läs_endast alltid sant och kan inte ändras. Men om du inte försöker ändra innehållet i databasen, är det inte annorlunda att ansluta till servern i det här läget från att ansluta till vanliga databaser. När en failover eller rollväxling inträffar återgår databasen till normal drift. När servern ändrar driftläge förblir etablerade sessioner anslutna. Efter att ha lämnat hot standby-läget blir det möjligt att börja skriva transaktioner (även i sessioner som startas i hot standby-läget).

Användare kan ta reda på om en session är i skrivskyddat läge genom att använda kommandot SHOW transaction_read_only. Dessutom ger en uppsättning funktioner (tabell 9.80) användare tillgång till information om backupservern. Detta gör att du kan skapa program som tar hänsyn till databasens aktuella status. Det här läget kan vara användbart för att övervaka återställningsprocessen eller för att skriva komplex återställning för speciella fall.

26.5.2. Hantera förfrågningskonflikter

Lead- och backupservrarna är sammankopplade av många svaga band. Händelser på den primära servern påverkar backupservern. Som ett resultat finns potentialen negativ påverkan eller konflikt mellan dem. Den enklaste konflikten att förstå är prestanda: om en mycket stor mängd data laddas på den primära servern skapas en motsvarande ström av WAL-poster på backupservern. Således tävlar förfrågningar på backupen om systemresurser t.ex. I/O.

En ytterligare typ av konflikt kan också uppstå på den heta standby-servern. Denna konflikt kallas svår konflikt , har en inverkan på förfrågningar, vilket leder till att de avbryts och i vissa fall till att sessionen avslutas för att lösa konflikter. Användare förses med en uppsättning verktyg för att hantera sådana konflikter. Fall av konflikt inkluderar:

Att ställa in ett exklusivt lås på den primära servern, antingen med ett explicit LOCK-kommando eller med olika DDL, vilket leder till en konflikt i åtkomst till tabeller på backupservern.

Att ta bort ett tabellutrymme på den primära servern orsakar en konflikt på standbyservern när frågor använder detta utrymme för att lagra temporära arbetsfiler.

Att ta bort en databas på den primära servern kommer i konflikt med sessioner som är anslutna till denna databas på backupservern.

Programmet som rensar inaktuella transaktioner från WAL kommer i konflikt med transaktioner i vänteläge som använder en ögonblicksbild av data som fortfarande ser några av raderna rensade på den primära.

Applikationen för att rensa upp inaktuella transaktioner från WAL kommer i konflikt med förfrågningar till målsidan på standby-servern, oavsett om data är raderad eller synlig.

I dessa fall väntar huvudservern helt enkelt; Användaren bör välja vilken av de motstridiga parterna som ska avbrytas. Standby har dock inget val: åtgärderna från WAL har redan inträffat på mastern, så standby måste tillämpa dem. Dessutom kan det vara högst oönskat att låta WAL-hanteraren vänta på obestämd tid, eftersom fördröjningen mellan backupservern och den primära servern kan öka. På detta sätt säkerställer mekanismen att förfrågningar på standbyservern som kommer i konflikt med de tillämpade WAL-posterna avbryts med tvång.

Ett exempel på ett sådant problem kan vara situationen: en administratör på den primära servern utfärdade ett DROP TABLE-kommando för en tabell som för närvarande deltar i en fråga i vänteläge. Det är tydligt att denna fråga inte kan köras vidare om kommandot DROP TABLE används i vänteläge. Om den här frågan kördes på mastern, skulle kommandot DROP TABLE vänta tills det avslutades. Men när endast ett DROP TABLE-kommando utfärdas på mastern, vet inte mastern vilka frågor som körs i vänteläget, så den kan inte vänta på att sådana frågor ska slutföras. Därför, om modifierade WAL-poster anländer till standby-servern medan frågan fortfarande körs, kommer en konflikt att uppstå. I det här fallet måste standbyservern antingen fördröja tillämpningen av dessa WAL-poster (och alla andra som följer dem) eller avbryta den motstridiga begäran så att DROP TABLE kan tillämpas.

Om den motstridiga begäran är kort, är det vanligtvis önskvärt att tillåta den att slutföras genom att kort fördröja tillämpningen av WAL-posterna, men för mycket fördröjning i tillämpningen av WAL är vanligtvis inte önskvärt. Därför har avbrytningsmekanismen parametrarna max_standby_archive_delay och max_standby_streaming_delay som definierar den maximalt tillåtna fördröjningstiden för WAL-applikation. Motstridiga förfrågningar kommer att ignoreras om de varar längre än den tillåtna fördröjningstiden för tillämpning av på varandra följande WAL-poster. Det finns två parametrar så att du kan ange olika värden för att läsa WAL-poster från arkivet (det vill säga när initial återhämtning från baskopian eller när "komma ikapp" masterserver i händelse av en stor eftersläpning) och för att erhålla WAL-poster under strömmande replikering.

På en standby-server som främst är designad för feltolerans är det bäst att hålla latensinställningarna relativt låga så att den inte kan ligga för långt efter den primära på grund av förseningar i samband med att vänta på hot standby-förfrågningar. Men om standby-servern är dedikerad till att köra långa frågor, då högt värde eller till och med att vänta på obestämd tid kan vara att föredra. Var dock medveten om att långvariga frågor kan påverka andra sessioner på standbyservern genom att göra att mastern missar de senaste ändringarna på grund av förseningen i tillämpningen av WAL-poster.

Om fördröjningen som definieras av max_standby_archive_delay eller max_standby_streaming_delay överskrids, kommer den motstridiga begäran att avbrytas. Detta uttrycks vanligtvis som ett avbokningsfel, men om kommandot DROP DATABASE spelas upp avslutas hela den motstridiga sessionen. Dessutom, om en konflikt uppstår under blockering orsakad av en transaktion i IDLE-läge, bryts den motstridiga sessionen (detta beteende kan ändras i framtiden).

Avbrutna förfrågningar kan omedelbart försökas igen (efter att en ny transaktion har påbörjats, naturligtvis). Eftersom orsaken till annulleringen beror på vilken typ av WAL-poster som spelas, kan en begäran som avbröts exekveras framgångsrikt igen.

Observera att latensparametrarna räknas från det att backupservern tar emot WAL-data. Således kan perioden för tillåtet arbete för en förfrågan på standby-servern aldrig vara längre än fördröjningsparametern och kan vara betydligt kortare om standby-läget redan är i fördröjningsläge som ett resultat av väntan på en tidigare förfrågan eller resultatet inte är tillgängligt på grund av en hög uppdateringsbelastning.

Den vanligaste orsaken till konflikter mellan förfrågningar på standby-servern och WAL-replay är för tidig tömning. PostgreSQL tillåter vanligtvis att gamla versioner av poster rensas, förutsatt att ingen transaktion kan se dem, enligt reglerna för datasynlighet för MVCC. Dessa regler gäller dock endast transaktioner som utförs på huvudservern. Det är alltså möjligt att en post redan har rensats på huvudservern, men samma post är fortfarande synlig för transaktioner på backupservern.

För erfarna användare Det bör noteras att både att rensa gamla radversioner och frysa en radversion potentiellt kan orsaka konflikter med förfrågningar på standbyservern. Att köra kommandot VACUUM FREEZE manuellt kan resultera i en konflikt, även på en tabell utan uppdaterade eller raderade rader.

Användare bör vara medvetna om att regelbundet och aktivt ändra data i tabeller på den primära servern riskerar att avbryta långvariga frågor på standby-servern. I ett sådant fall fungerar inställningen av max_standby_archive_delay eller max_standby_streaming_delay till ett slutligt värde som en statement_timeout-begränsning.

Om antalet avbrutna förfrågningar på backupservern är oacceptabelt finns det ett antal ytterligare alternativ. Det första alternativet är att ställa in parametern hot_standby_feedback, som förhindrar VACUUM-kommandot från att radera poster som nyligen har blivit ogiltiga, vilket förhindrar rensningskonflikter. Observera att detta orsakar en fördröjning när det gäller att rensa döda rader på ledaren, vilket kan leda till oönskad tabelluppsvällning. Men i slutändan blir situationen inte värre än om förfrågningar till backupservern exekveras direkt på den primära, men den positiva effekten av lastdelning kommer att finnas kvar. I de fall anslutningen mellan backupservrarna och mastern ofta avbryts, den period under vilken Respons via hot_standby_feedback tillhandahålls inte. Du kan till exempel överväga att öka max_standby_archive_delay så att förfrågningar inte omedelbart avbryts när det finns konflikter med WAL-arkivet under frånkopplingsperioden. Det kan också vara meningsfullt att öka max_standby_streaming_delay för att förhindra att förfrågningar snabbt avbryts på grund av mottagna WAL-poster efter att anslutningen har återställts.

En annan möjlighet är att öka vacuum_defer_cleanup_age på masterservern så att döda poster inte rensas upp lika snabbt som normal drift. Detta ger förfrågningar på standby-servern mer tid att slutföra innan de kan avbrytas utan att öka fördröjningen max_standby_streaming_delay. Det är dock mycket svårt att tillhandahålla något specifikt tidsfönster med detta tillvägagångssätt, eftersom vacuum_defer_cleanup_age mäts i antalet transaktioner som körs på huvudservern.

Antalet avbrutna förfrågningar och orsakerna till avbokningen kan ses i systemvyn pg_stat_database_conflicts på standbyservern. Systemvyn pg_stat_database innehåller också sammanfattningsinformation.

26.5.3. Översikt över den administrativa delen

Om hot_standby är inställd på på (standard) i postgresql.conf-filen och det finns en recovery.conf-fil, kommer servern att starta i hot standby-läge. Det kan dock ta lite tid innan den kan anslutas till, eftersom den inte accepterar anslutningar förrän den har återställts till ett konsekvent tillstånd som är lämpligt för att utföra förfrågningar. (Statens konsistensinformation registreras på huvudservern i Kontrollpunkt.) Under denna period kommer klienter att få ett felmeddelande när de försöker ansluta. Du kan se till att servern är igång genom att antingen upprepa anslutningsförsök från programmet tills anslutningen lyckas, eller genom att vänta på att dessa meddelanden ska visas i serverloggarna:

LOG: går in i vänteläge ... sedan en tid senare ... LOGG: konsekvent återställningstillstånd uppnått LOG: databassystemet är redo att acceptera skrivskyddade anslutningar

Du kan inte aktivera hot standby om WAL skrevs under en period då parametern wal_level på masterservern var inställd på varken replika eller logisk. Uppnåendet av ett konsensustillstånd kan också försenas om båda dessa tillstånd inträffar:

En skrivtransaktion har mer än 64 deltransaktioner

Mycket långa skrivtransaktioner

Om du använder filbaserad loggreplikering (varm standby) kan du behöva vänta på att nästa WAL-fil kommer (den maximala väntetiden ställs in av parametern archive_timeout på huvudservern).

Värdena för vissa parametrar på backupservern måste ändras när du ändrar dem på den primära servern. För sådana parametrar måste värdena på backupservern inte vara mindre än värdena på den primära servern. Så om du vill öka dem måste du först göra det på standby-servrarna och sedan tillämpa ändringarna på mastern. Omvänt, om du vill minska dem, gör det först på den primära servern och tillämpar sedan ändringarna på alla standby-servrar. Om parametrarna inte är inställda på tillräckligt stora värden kommer backupservern inte att kunna börja fungera. I det här fallet kan du öka dem och försöka starta servern igen så att återställningen återupptas. Detta gäller följande parametrar:

max_prepared_transactions
max_locks_per_transaction
max_arbetarprocesser

Det är mycket viktigt för administratören att välja lämpliga värden för max_standby_archive_delay och max_standby_streaming_delay. Det optimala värdet beror på prioriteringar. Till exempel om huvudsyftet med servern är att tillhandahålla hög grad tillgänglighet, då bör en kort period ställas in, kanske till och med noll, även om detta är ett mycket strikt alternativ. Om backupservern är planerad som en extra server för analytiska frågor, skulle en maximal fördröjning på flera timmar eller till och med -1 vara acceptabel, vilket innebär att man väntar på obestämd tid på att frågan ska slutföras.

Tilläggstransaktionsstatusbitar som skrivs till mastern hamnar inte i WAL, så de kommer sannolikt att skrivas över av mastern när data bearbetas. På så sätt kommer backupservern att skriva till disken även om alla användare bara läser data utan att ändra något. Dessutom kommer användare att skriva temporära filer när de sorterar stora volymer och uppdatera cachefiler. Därför är ingen del av databasen skrivskyddad i hot standby-läge. Det bör noteras att det även går att skriva till fjärrbas data som använder dblink-modulen och andra operationer utanför databasen med PL-funktioner, även om transaktioner fortfarande bara kommer att kunna läsa data.

Följande typer av administrativa kommandon är inte tillgängliga under återställningsläge:

Data definition (DDL) kommandon - till exempel: CREATE INDEX

Kommandon för att utfärda privilegier och tilldela äganderätt - BETYD, ÅTERTILL, ÅTERTILLDELA

Underhållskommandon - ANALYSE, VAKUUM, KLUSTER, REINDEXERA

Återigen bör det noteras att vissa av dessa kommandon faktiskt är tillgängliga på huvudservern för skrivskyddade transaktioner.

Som ett resultat kan ytterligare index eller statistik inte skapas så att de bara finns i vänteläge. Om sådana administrativa kommandon behövs bör de köras på den primära servern och sedan kommer dessa ändringar att spridas till backupservrarna.

Funktionerna pg_cancel_backend() och pg_terminate_backend() fungerar på användarsidan, men inte på startprocessen som ger återställningen. Vyn pg_stat_activity visar inte återvinningsbara transaktioner som aktiva. Därför är vyn pg_prepared_xacts alltid tom under återställning. Om du behöver analysera tvivelaktiga förberedda transaktioner, bör du komma åt pg_prepared_xacts på mastern och köra kommandon för att analysera transaktionerna där, eller analysera dem efter att återställningen är klar.

pg_locks visar lås som uppstår när servern körs som vanligt. pg_locks visas också virtuella transaktioner, bearbetas av startprocessen som äger alla AccessExclusiveLocks som införts av transaktioner i återställningsläge. Det bör noteras att startprocessen inte begär lås för att göra ändringar i databasen, så andra lås än AccessExclusiveLocks visas inte i pg_locks för startprocessen, deras existens antas.

Check_pgsql-modulen för Nagios kommer att fungera eftersom servern har problem enkel information, vars närvaro han kontrollerar. Övervakningsskriptet check_postgres fungerar på samma sätt, även om resultaten kan variera eller vara missvisande för vissa mätvärden som det producerar. Du kan till exempel inte spåra tiden för den senaste rensningen eftersom rensningen inte utförs på standbyservern. Rengöring startas på den ledande servern och resultatet av dess arbete överförs till backup-servern.

WAL-filhanteringskommandon som pg_start_backup, pg_switch_wal, etc. kommer inte att fungera under återställning.

Dynamiskt laddade moduler kommer att fungera, inklusive pg_stat_statements.

Rådgivande låsning fungerar normalt under återställning, inklusive detektering av dödläge. Det bör noteras att det rådgivande låset aldrig kommer in i WAL, så det är omöjligt för det rådgivande låset på vare sig den primära eller standby-servern att komma i konflikt med WAL-uppspelning. Men det är möjligt att få ett rådgivande lås på den primära servern, och sedan få ett liknande rådgivande lås på backupservern. Ett rådgivande block gäller endast servern som det togs emot på.

Triggerbaserade replikeringssystem som Slony, Londiste och Bucardo kan inte köras på standby-servern överhuvudtaget, även om de fungerar bra på masterservern tills ett kommando ges att inte skicka ändringar till standby-servern. WAL-uppspelning är inte triggerbaserad, så WAL-strömmen kan inte sändas från en backupserver till ett annat system som kräver ytterligare inträde i databasen eller fungerar baserat på triggers.

Nya OID:n kan inte utfärdas, även om till exempel UUID-generatorer kommer att kunna fungera så länge de inte försöker skriva nytt tillstånd till databasen.

I för närvarande att skapa tillfälliga tabeller är inte tillåtet i en skrivskyddad transaktion, i vissa fall kommer det befintliga skriptet inte att fungera korrekt. Denna begränsning kan mildras i framtida utgåvor. Detta är både ett SQL-standardkrav och ett tekniskt krav.

Kommandot DROP TABLESPACE kan endast utföras om tabellutrymmet är tomt. Vissa vänteserveranvändare kan aktivt använda tabellutrymmet genom parametern temp_tablespaces. Om det finns temporära filer i tabellutrymmena avbryts alla aktiva frågor för att säkerställa att de temporära filerna tas bort, sedan kan tabellutrymmet tas bort och WAL-uppspelningen kan fortsätta.

Om du kör kommandot DROP DATABASE eller ALTER DATABASE ... SET TABLESPACE på den primära servern skapas en WAL-post som tvingar alla användare som är anslutna till databasen i vänteläge att kopplas bort. Detta händer omedelbart, oavsett värdet på max_standby_streaming_delay. Det bör noteras att kommandot ALTER DATABASE ... RENAME inte kopplar bort användare, så det fungerar vanligtvis tyst, även om i vissa fall program som är beroende av databasnamnet kan krascha.

Om du är i normalt läge (inte i återställningsläge), utför DROP USER eller DROP ROLE på den anslutna rollen medan den användaren är ansluten, på given användare detta kommer inte att påverka det på något sätt - det kommer att förbli uppkopplat. Han kommer dock inte längre att kunna återansluta. Samma beteende gäller i återställningsläge - om du utför DROP USER på den primära servern kommer användaren inte att kopplas bort från säkerhetskopian.

Statistikinsamlaren körs under återhämtning. Alla skanningar, läsningar, blockeringar, indexanvändning etc. kommer att registreras som vanligt på standby-servern. Åtgärderna som inträffar under omspelning kommer inte att duplicera åtgärderna på huvudservern, det vill säga att omspelning av kommandot infoga inte ökar värdet på kolumnen Infogar i vyn pg_stat_user_tables. Statistikfiler raderas när återställningen påbörjas, så statistiken på primär- och backupservrarna kommer att vara olika. Detta är en funktion, inte en bugg.

Information om alla pågående transaktioner krävs innan en ögonblicksbild av data kan skapas. Transaktioner som använder ett stort antal deltransaktioner (för närvarande fler än 64) kommer att fördröja starten av en skrivskyddad anslutning tills den längsta skrivtransaktionen har slutförts. Om denna situation inträffar kommer ett förklarande meddelande att skrivas till serverloggen.

Lämpliga startpunkter för förfrågningar på backupservern skapas vid varje kontrollpunkt på huvudservern. Om standbyservern går ner medan mastern var nere, kanske det inte går att ta upp den igen som ett hot standby innan mastern startar upp och lägger till följande startpunkter i WAL-loggarna. Denna situation är inte ett problem i de flesta fall där det kan inträffa. Vanligtvis, om masterservern är nere och inte längre är tillgänglig, är detta en följd av ett allvarligt fel och kräver i alla fall konvertering av standby till den nya mastern. I en situation där mastern är inaktiverad avsiktligt är det också en normal procedur att kontrollera säkerhetskopieringens beredskap att konvertera till mastern.

I slutet av återställningen kräver AccessExclusiveLocks orsakade av förberedda transaktioner dubbelt så många tabellpostlås. Om du planerar att använda antingen ett stort antal konkurrerande förberedda transaktioner, vanligtvis anrop till AccessExclusiveLocks, eller stora transaktioner med stora mängder AccessExclusiveLocks, det rekommenderas att välja ett stort värde för parametern max_locks_per_transaction, kanske två gånger värdet av parametern på huvudservern. Inget av detta spelar någon roll när max_prepared_transactions är 0.

Den serialiserbara transaktionsisoleringsnivån är för närvarande inte tillgänglig i hot standby. (Se underavsnitt 13.2.3 och underavsnitt 13.4.1 för detaljer.) Ett försök att ställa in denna isoleringsnivå för en transaktion i hot standby-läge kommer att orsaka ett fel.