Ütemezett karbantartás az Azure Database for MySQL-ben – rugalmas kiszolgáló
A rugalmas Azure Database for MySQL-kiszolgáló rendszeres karbantartást végez, hogy a felügyelt adatbázis biztonságos, stabil és naprakész maradjon. A karbantartás során a kiszolgáló új funkciókkal, frissítésekkel és javításokkal bővül.
Fontos
Az Azure Database for MySQL rugalmas kiszolgálókarbantartása során kerülje az összes kiszolgálóműveletet (módosításokat, konfigurációmódosításokat, a kiszolgáló indítását/leállítását). Ezeknek a tevékenységeknek a használata kiszámíthatatlan eredményekhez vezethet, ami hatással lehet a kiszolgáló teljesítményére és stabilitására. Várjon, amíg a karbantartás befejeződik, mielőtt végrehajtja a kiszolgálói műveleteket.
Karbantartási ciklus
Rutinszerű karbantartás
Standard karbantartási ciklusunk nem ritkábban van ütemezve, mint 30 naponta. Ez az időszak lehetővé teszi a rendszer stabilitásának és teljesítményének biztosítását, miközben minimalizáljuk a szolgáltatások megszakadását.
Kritikus karbantartás
Bizonyos esetekben, például a rendelkezésre állás és az adatintegritás fenntartása szempontjából kritikus fontosságú sürgős biztonsági javítások vagy frissítések üzembe helyezésének szükségessége esetén gyakoribb lehet a karbantartás. Ezek a kivételek az adatok védelme és a szolgáltatások folyamatos működésének biztosítása érdekében kerülnek sor.
Virtuális kanári karbantartása (nyilvános előzetes verzió)
A Virtual Canary egy kísérleti karbantartási program, amely korai hozzáférést biztosít a frissítésekhez, így az ügyfelek tesztelhetik a számítási feladatok kompatibilitását az új Azure MySQL-verziókkal. A rutinszerű karbantartástól eltérően a Virtuális Kanári nem követi a 30 napos minimális rést vagy a 7 napos értesítési időszakot. Ez a program segít az ügyfeleknek proaktívan érvényesíteni az új funkciókat, és korai visszajelzéseket küldeni a termékfejlesztésekhez. A nem éles környezetekhez gyakran használt, kipukkasztható termékváltozat-kiszolgálók automatikusan regisztrálva lesznek a Virtual Canary programban.
Virtuális kanári-regisztráció kezelése
Az Azure Database for MySQL rugalmasságot biztosít az ügyfelek számára a Virtuális Kanári programban való részvételük kezeléséhez. A Virtual Canary lehetővé teszi a karbantartási frissítések korai elérését, lehetővé téve a proaktív kompatibilitási tesztelést és az új funkciókkal kapcsolatos visszajelzéseket.
- Virtuális kanári-regisztráció ellenőrzése
Annak ellenőrzéséhez, hogy a kiszolgáló regisztrálva van-e a Virtual Canary programban, használja a következő parancsot:
az mysql flexible-server show --resource-group {resourcegroupname} --name {servername} --query "maintenancePolicy"
Ha az eredmény tartalmazza "patchStrategy": "VirtualCanary", a kiszolgáló regisztrálva lesz a Virtuális kanári programban.
- Regisztráció a Virtuális kanáriban
Ha regisztrálni szeretne egy kiszolgálót a Virtual Canary programban, futtassa a következő parancsot:
az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy VirtualCanary
- Kilépés a virtuális kanáriból
A Virtual Canary programból való kilépéshez és a standard karbantartási szabályzathoz való visszatéréshez használja ezt a parancsot:
az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy Regular
Ez az egyszerű folyamat lehetővé teszi az ügyfelek számára, hogy szükség szerint kilépjenek vagy kilépjenek a Virtuális Kanáriból, biztosítva a működési követelményeknek való megfelelést.
Karbantartási adatok megkeresése
Az egyes karbantartási frissítésekkel kapcsolatos részletekért tekintse meg a kibocsátási megjegyzéseinket. Ezek a megjegyzések átfogó információkat nyújtanak a karbantartás során alkalmazott frissítésekről, így megértheti és felkészülhet a környezetet érintő változásokra.
Feljegyzés
Az ütemezett frissítések során nem minden kiszolgáló fog feltétlenül karbantartást végezni, akár rutin, akár kritikus fontosságú. Az Azure MySQL csapata meghatározott kritériumokat alkalmaz annak meghatározásához, hogy mely kiszolgálók igényelnek karbantartást. Ez a szelektív megközelítés biztosítja, hogy a karbantartás hatékony és nélkülözhetetlen legyen, az egyes kiszolgálói környezetek egyedi igényeinek megfelelően, és minimalizálja az éles üzemidőt.
Karbantartási időszak kiválasztása
A karbantartást a hét egy adott napjára és a napon belül egy adott időszakra ütemezheti. Azt is megteheti, hogy a rendszer automatikusan kiválaszt egy napot és egy időablakot. Akárhogy is, a rendszer hét nappal a karbantartás futtatása előtt figyelmezteti Önt. A rendszer arról is értesítést küld, hogy mikor indul el a karbantartás, és mikor fejeződik be sikeresen.
A közelgő ütemezett karbantartással kapcsolatos értesítések a következőek lehetnek:
- E-mailben megadott címre küldve
- E-mailben elküldve egy Azure Resource Manager-szerepkörnek
- Sms-ben elküldve mobileszközökre
- Leküldéses értesítésként Azure-alkalmazásba
- Hangüzenetként
A karbantartási ütemezés beállításainak megadásakor kiválaszthatja a hét valamelyik napját és egy időszakot. Ha nem határoz meg időpontot, a rendszer a kiszolgáló régiójának időzónája szerint 23:00 és 7:00 közötti időpontot választ. Az Azure-előfizetés minden rugalmas kiszolgálójához különböző ütemezéseket határozhat meg.
Az ütemezési beállításokat bármikor frissítheti. Ha a rugalmas kiszolgálóhoz ütemezett karbantartás van ütemezve, és frissíti az ütemezési beállításokat, az aktuális bevezetés ütemezett módon folytatódik, és az ütemezési beállítások módosítása a következő ütemezett karbantartás sikeres befejezését követően lép életbe.
Az Azure-előfizetés minden rugalmas kiszolgálójához megadhat rendszer által felügyelt ütemezést vagy egyéni ütemezést.
- Egyéni ütemezéssel megadhatja a kiszolgáló karbantartási időszakát a hét napjának és egy egyórás időszakának kiválasztásával.
- A rendszer által felügyelt ütemezéssel a rendszer bármelyik egyórás ablakot kiválasztja 11:00 és 19:00 között a kiszolgáló régióidejében.
Fontos
2024. augusztus 31-től az Azure Database for MySQL már nem támogatja a kipukkanható termékváltozat-példányok egyéni karbantartási időszakait. Ennek a változásnak az az oka, hogy egyszerűsíteni kell a karbantartási folyamatokat, optimális teljesítményt kell biztosítani, és az elemzésünk azt jelzi, hogy az egyéni karbantartási időszakokat használó felhasználók száma a kipukkanható termékváltozatokon minimális. Az egyéni karbantartási időszak konfigurációival rendelkező meglévő kipukkasztható termékváltozat-példányok változatlanok maradnak; a felhasználók azonban nem módosíthatják ezeket az egyéni karbantartási időszak beállításait.
Az egyéni karbantartási időszakokat igénylő ügyfelek számára javasoljuk, hogy frissítsenek általános célú vagy üzletileg kritikus termékváltozatokra a funkció további használatához.
Ritkán előfordulhat, hogy a rendszer megszakítja a karbantartási eseményt, vagy sikertelenül fejeződik be. Ha a frissítés sikertelen, a rendszer visszaállítja a frissítést, és visszaállítja a bináris fájlok előző verzióját. Ilyen sikertelen frissítési forgatókönyvekben előfordulhat, hogy a karbantartási időszak alatt is újraindul a kiszolgáló. Ha a frissítés megszakad vagy sikertelen, a rendszer értesítést küld a megszakított vagy meghiúsult karbantartási eseményről, amely értesíti Önt. A következő karbantartási kísérlet az aktuális ütemezési beállításoknak megfelelően lesz ütemezve, és erről 5 nappal korábban értesítést fog kapni.
Közel nulla állásidő-karbantartás (nyilvános előzetes verzió)
A rugalmas Azure Database for MySQL-kiszolgáló "Közel nulla állásidő-karbantartás" funkciója úttörő fejlesztés a MAGAS rendelkezésre állású kiszolgálók számára. Ez a funkció jelentősen csökkenti a karbantartási állásidőt, biztosítva, hogy a legtöbb esetben a karbantartási állásidő várhatóan 40 és 60 másodperc között legyen. Ez a képesség kulcsfontosságú azon vállalatok számára, amelyek magas rendelkezésre állást és minimális megszakítást igényelnek az adatbázis-üzemeltetésben.
Pontos állásidő-várakozások
- Állásidő időtartama: A legtöbb esetben a karbantartás közbeni állásidő 10 és 30 másodperc között mozog.
- További szempontok: A feladatátvételi esemény után a DNS élettartamának (TTL) időtartama körülbelül 30 másodperc. Ezt az időszakot nem közvetlenül a karbantartási folyamat vezérli, hanem a DNS-viselkedés szokásos része. Az ügyfél szempontjából tehát a karbantartás során tapasztalt teljes állásidő 40 és 60 másodperc között lehet.
Korlátozások és előfeltételek
A funkció által ígért optimális teljesítmény elérése érdekében meg kell jegyezni bizonyos feltételeket és korlátozásokat:
- Elsődleges kulcsok minden táblában: Kritikus fontosságú annak biztosítása, hogy minden tábla rendelkezik elsődleges kulccsal. Az elsődleges kulcsok hiánya jelentősen növelheti a replikáció késését, ami hatással van az állásidőre.
- Alacsony munkaterhelés a karbantartási idő alatt: A karbantartási időszakoknak egybe kell esnie a kiszolgáló alacsony számítási feladatainak idejével, hogy az állásidő minimális maradjon. Javasoljuk, hogy az egyéni karbantartási időszak funkcióval ütemezze a karbantartást csúcsidőn kívül.
- Állásidő-garanciák: Bár igyekszünk a lehető legalacsonyabban tartani a karbantartási állásidőt, nem garantáljuk, hogy minden körülmények között mindig 60 másodpercnél rövidebb legyen. A különböző tényezők, például a nagy számítási feladatok vagy adott kiszolgálókonfigurációk hosszabb állásidőt eredményezhetnek. A legrosszabb esetben az állásidő hasonló lehet egy önálló kiszolgálóhoz.
Karbantartási átütemezett
A karbantartási átütemezett funkció nagyobb ellenőrzést biztosít a rugalmas Azure Database for MySQL-kiszolgálópéldány karbantartási tevékenységeinek időzítése felett. Miután megkapta a karbantartási értesítést, átütemezheti egy kényelmesebb időpontra, függetlenül attól, hogy rendszer vagy egyéni felügyelet alatt állt.
Paraméterek és értesítések átütemezése
Az átütemezés nem rögzített idősávokra korlátozódik; az aktuális karbantartási ciklus legkorábbi és legújabb megengedett időpontjaitól függ, amelyek általában a régió karbantartási időszakának első napjától az utolsó napig terjednek. Az átütemezés után a rendszer értesítést küld a módosítások megerősítéséhez a szabványos értesítési szabályzatok szerint.
Szempontok és korlátozások
A funkció használatakor vegye figyelembe a következőket:
- Igénykorlátozások: Előfordulhat, hogy az újraütemezett karbantartás megszakad, mert sok karbantartási tevékenység történik egyszerre ugyanabban a régióban.
- Zárolási időszak: Az átütemezés a szolgáltatás megbízhatóságának fenntartása érdekében az eredetileg ütemezett karbantartási idő előtt 15 perccel nem érhető el.
- Átütemezés – Szabályozás : Ha az ugyanabban a régióban túl sok kiszolgáló van ütemezve karbantartásra ugyanabban az időszakban, előfordulhat, hogy a kérések átütemezése sikertelen lesz. A felhasználók hibaüzenetet kapnak, ha ez bekövetkezik, és javasoljuk, hogy válasszon másik időpontot. Az újraütemezett karbantartás nem valószínű, hogy megszakad.
Nincs korlátozás arra, hogy egy karbantartás hányszor ütemezhető újra, amíg a karbantartás nem került "Előkészítés alatt" állapotba, bármikor átütemezheti a karbantartást egy másik időpontra.
Feljegyzés
Javasoljuk, hogy az előzetes verzióban szorosan monitorozza az értesítéseket a lehetséges módosítások érdekében.
Ezzel a funkcióval elkerülheti a kritikus adatbázis-műveletek során fellépő fennakadásokat. A funkció továbbfejlesztése során visszajelzést küldünk önnek.
GYIK
K: Miért kaptak egyes kiszolgálók karbantartási értesítéseket, míg mások nem?
Válasz: A karbantartás kezdési időpontja régiónként eltérő, így a különböző régiókban lévő kiszolgálók különböző időpontokban kaphatnak karbantartási értesítéseket.
K: Miért kaptak karbantartási értesítéseket az ugyanabban a régióban lévő kiszolgálók, míg mások nem?
Válasz: Ennek az lehet az oka, hogy az értesítéseket nem fogadó kiszolgálók a közelmúltban lettek létrehozva, és a rendszer megállapította, hogy még nem igényelnek karbantartást.
K: Kikapcsolhatom az ütemezett karbantartást?
Válasz: Nem, az ütemezett karbantartás letiltása nem engedélyezett. A karbantartási átütemezett funkcióval azonban módosíthatja az időzítést, vagy engedélyezheti a magas rendelkezésre állási (HA) funkciót az állásidő minimalizálása érdekében. PaaS-adatbázis-termékként elengedhetetlen, hogy időben karbantartsa az adatbázis biztonságát és megbízhatóságát.