A rugalmas Azure Database for MySQL-kiszolgáló szolgáltatási szintjei
A következőkre vonatkozik:
Azure Database for MySQL – rugalmas kiszolgáló
Rugalmas Azure Database for MySQL-kiszolgálópéldányt három különböző szolgáltatási szint egyikében hozhat létre: Burstable, General Purpose és üzletileg kritikus. A szolgáltatási szinteket a mögöttes virtuálisgép-termékváltozat, a B sorozat, a D sorozat és az E sorozat különbözteti meg. A számítási szint és a méret kiválasztása határozza meg a kiszolgálón elérhető memóriát és virtuális magokat. Minden szolgáltatási szinten ugyanazt a tárolási technológiát használják. Minden erőforrás rugalmas Azure Database for MySQL-kiszolgálópéldány szintjén van kiépítve. Egy kiszolgáló egy vagy több adatbázissal rendelkezhet.
| Erőforrás/réteg | Kipukkanható | Általános célú | üzletileg kritikus |
|---|---|---|---|
| Virtuálisgép-sorozatok | B sorozat | Dadsv5-sorozatDdsv4-sorozat | Edsv4 Edsv5 sorozatú*/Eadsv5-sorozat/ |
| Virtuális magok | 1, 2, 4, 8, 12, 16, 20 | 2, 4, 8, 16, 32, 48, 64 | 2, 4, 8, 16, 32, 48, 64, 80, 96 |
| Memória virtuális magonként | Változó | 4 GiB | 8 GiB ** |
| Tárterület mérete | 20 GiB–16 TiB | 20 GiB–16 TiB | 20 GiB–16 TiB |
| Adatbázis biztonsági mentésének megőrzési időtartama | 1–35 nap | 1–35 nap | 1–35 nap |
** A 64,80 és 96 virtuális mag kivételével, amelyek 504 GiB, 504 GiB és 672 GiB memóriával rendelkeznek.
* Az Ev5 compute a QPS és a késés szempontjából a legjobb teljesítményt nyújtja a többi virtuálisgép-sorozat között. Itt tudhat meg többet az Ev5 compute teljesítményéről és régiónkénti elérhetőségéről.
Számítási szint kiválasztásához használja az alábbi táblázatot kiindulási pontként.
| Számítási szint | Megcélzott számítási feladatok |
|---|---|
| Átmenetileg fokozható teljesítmény | A legjobb olyan számítási feladatokhoz, amelyeknek nincs szükségük a teljes cpu-ra folyamatosan. |
| Általános célú | A legtöbb olyan üzleti számítási feladat, amely kiegyensúlyozott számítást és memóriát igényel skálázható I/O-átviteli sebességgel. Ilyenek például a web- és mobilalkalmazások üzemeltetésére szolgáló kiszolgálók, valamint az egyéb nagyvállalati alkalmazások. |
| Üzletileg kritikus | Nagy teljesítményű adatbázis-számítási feladatok, amelyek memórián belüli teljesítményt igényelnek a gyorsabb tranzakciófeldolgozáshoz és a nagyobb egyidejűséghez. Ilyenek például a valós idejű adatokat feldolgozó kiszolgálók és a nagy teljesítményű, tranzakciós vagy elemző alkalmazások. |
A kiszolgáló létrehozása után a számítási szint, a számítási méret és a tárterület mérete módosítható. A számítási skálázás újraindítást igényel, és 60–120 másodpercet vesz igénybe, míg a tárolóméretezés nem igényel újraindítást. A biztonsági másolatok megőrzési időtartamát egymástól függetlenül is módosíthatja. További információ: Erőforrások méretezése szakasz.
Szolgáltatási szintek, méret és kiszolgálótípusok
A számítási erőforrások a szint és a méret alapján választhatók ki. Ez határozza meg a virtuális magokat és a memória méretét. A virtuális magok a mögöttes hardver logikai CPU-ját jelölik.
Az elérhető kiszolgálótípusok részletes specifikációi a következők : Burstable:
| Számítási méret | Virtuális magok | Fizikai memória mérete (GiB) | Teljes memóriaméret (GiB) | Maximális támogatott IOPS | Kapcsolatok maximális száma | Temp Storage (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_B1s | 0 | 0 | 1,1 | 320 | 171 | 0 |
| Standard_B1ms | 0 | 2 | 2,2 | 640 | 341 | 0 |
| Standard_B2s | 2 | 4 | 4.4 | 1280 | 683 | 0 |
| Standard_B2ms | 2 | 8 | 8.8 | 1700 | 1365 | 0 |
| Standard_B4ms | 4 | 16 | 17,6 | 2400 | 2731 | 0 |
| Standard_B8ms | 8 | 32 | 35.2 | 3100 | 5461 | 0 |
| Standard_B12ms | 12 | 48 | 52.8 | 3800 | 8193 | 0 |
| Standard_B16ms | 16 | 64 | 70.4 | 4300 | 10923 | 0 |
| Standard_B20ms | 20 | 80 | 88. | 5000 | 13653 | 0 |
Az elérhető kiszolgálótípusok részletes specifikációi az általános célúak:
| Számítási méret | Virtuális magok | Fizikai memória mérete (GiB) | Teljes memóriaméret (GiB) | Maximális támogatott IOPS | Kapcsolatok maximális száma | Temp Storage (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_D2ads_v5 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D2ds_v4 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D4ads_v5 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D4ds_v4 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D8ads_v5 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D8ds_v4 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D16ads_v5 | 16 | 64 | 88. | 20000 | 10923 | 430 |
| Standard_D16ds_v4 | 16 | 64 | 88. | 20000 | 10923 | 430 |
| Standard_D32ads_v5 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D32ds_v4 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D48ads_v5 | 48 | 192 | 264 | 20000 | 32 768 | 1290 |
| Standard_D48ds_v4 | 48 | 192 | 264 | 20000 | 32 768 | 1290 |
| Standard_D64ads_v5 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
| Standard_D64ds_v4 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
Az elérhető kiszolgálótípusok részletes specifikációi az alábbi üzletileg kritikus:
| Számítási méret | Virtuális magok | Fizikai memória mérete (GiB) | Teljes memóriaméret (GiB) | Maximális támogatott IOPS | Kapcsolatok maximális száma | Temp Storage (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_E2ds_v4 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E2ads_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v4 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E4ads_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v4 | 8 | 64 | 88. | 18 000 | 10923 | 151 |
| Standard_E8ads_v5 | 8 | 64 | 88. | 18 000 | 10923 | 151 |
| Standard_E16ds_v4 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E16ads_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v4 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E20ads_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v4 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E32ads_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v4 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E48ads_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v4 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E64ads_v5 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E80ids_v4 | 80 | 504 | 693 | 72000 | 86016 | 1224 |
| Standard_E2ds_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v5 | 8 | 64 | 88. | 18 000 | 10923 | 151 |
| Standard_E16ds_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v5 | 64 | 512 | 704 | 64000 | 87383 | 1208 |
| Standard_E96ds_v5 | 96 | 672 | 924 | 80000 | 100 000 | 2004 |
Memóriakezelés rugalmas Azure Database for MySQL-kiszolgálón
A MySQL-ben a memória fontos szerepet játszik a különböző műveletekben, beleértve a lekérdezésfeldolgozást és a gyorsítótárazást. A rugalmas Azure Database for MySQL-kiszolgáló optimalizálja a memóriafoglalást a MySQL-kiszolgáló folyamatához (mysqld), biztosítva, hogy elegendő memóriaerőforrást kapjon a hatékony lekérdezésfeldolgozáshoz, gyorsítótárazáshoz, ügyfélkapcsolat-kezeléshez és szálkezeléshez. További információ arról, hogy a MySQL hogyan használja a memóriát.
Fizikai memória mérete (GB)
Az alábbi táblázatban szereplő fizikai memóriaméret (GB) a rugalmas Azure Database for MySQL-kiszolgálón gigabájtban (GB) található véletlenszerű hozzáférésű memóriát (RAM) jelöli.
Teljes memóriaméret (GB)
A rugalmas Azure Database for MySQL-kiszolgáló teljes memóriaméretet (GB) biztosít. Ez a kiszolgáló számára rendelkezésre álló teljes memóriát jelöli, amely a fizikai memória és az ideiglenes tároló SSD-összetevőjének kombinációja. Ez az egységes nézet úgy lett kialakítva, hogy egyszerűsítse az erőforrás-kezelést, így csak az Azure MySQL Server (mysqld) folyamat számára elérhető teljes memóriára összpontosíthat. A Memória százalékos (memory_percent) metrika az Azure MySQL-kiszolgálói folyamat (mysqld) által elfoglalt memória százalékos arányát jelöli. Ezt a metrikát a rendszer a teljes memóriaméretből (GB) számítja ki. Ha például a Memória százalékos metrika 60 értéket jelenít meg, az azt jelenti, hogy az Azure MySQL Server-folyamat a rugalmas Azure Database for MySQL-kiszolgálón elérhető teljes memóriaméret (GB) 60%-át használja.
MySQL-kiszolgáló (mysqld)
A mysqld Azure MySQL-kiszolgálói folyamat az adatbázis-műveletek alapvető motorjaként szolgál. Indításkor inicializálja az összes összetevőt, például az InnoDB pufferkészletet és a szálgyorsítótárat, a konfiguráció és a számítási feladatok igényei alapján felhasználva a memóriát. Az InnoDB pufferkészlet például a gyakran használt adatokat és indexeket gyorsítótárazza a lekérdezések végrehajtási sebességének javítása érdekében, míg a szálgyorsítótár kezeli az ügyfélkapcsolati szálakat. További információ.
InnoDB-tárolómotor
A MySQL alapértelmezett tárolómotorjaként az InnoDB memóriát használ a gyakran használt adatok gyorsítótárazására, valamint olyan belső struktúrák kezelésére, mint az innodb pufferkészlet és a naplópuffer. Az InnoDB pufferkészlet táblaadatokat és indexeket tárol a memóriában a lemez I/O minimalizálása érdekében, ami növeli a teljesítményt. Az InnoDB pufferkészlet mérete paraméter kiszámítása a kiszolgálón elérhető fizikai memóriaméret (GB) alapján történik. További információ a rugalmas Azure Database for MySQL-kiszolgálón elérhető InnoDB pufferkészlet méretéről.
Szálak
Az ügyfélkapcsolatokat a kapcsolatkezelő által kezelt dedikált szálak kezelik. Ezek a szálak kezelik a hitelesítést, a lekérdezések végrehajtását és az eredmények lekérését az ügyfél-interakciókhoz. További információ.
Az elérhető számítási sorozatokkal kapcsolatos további információkért tekintse meg az Azure-beli virtuálisgép-dokumentációt a Burstable (B sorozat), az Általános célú Dadsv5 sorozatúDdsv4 sorozat és üzletileg kritikus Edsv4/Edsv5 sorozatú/Eadsv5-sorozathoz.
A kipukkanható sorozatpéldányok teljesítménykorlátozásai
Feljegyzés
A burstable (B sorozatú) számítási szint esetén, ha a virtuális gép elindult/leállított vagy újraindult, előfordulhat, hogy a kreditek elvesznek. További információ: Burstable (B-Series) – gyakori kérdések.
A kipukkasztható számítási szint úgy lett kialakítva, hogy költséghatékony megoldást nyújtson olyan számítási feladatokhoz, amelyek nem igényelnek folyamatos teljes processzorhasználatot folyamatosan. Ez a szint ideális nem gyártási számítási feladatokhoz, például fejlesztési, előkészítési vagy tesztelési környezetekhez. A kipukkasztható számítási szint egyedi jellemzője, hogy képes "kipukkasztani", azaz az alapszintű processzorteljesítménynél többet használni a vCPU akár 100%-ának felhasználásával, amikor a számítási feladat megköveteli. Ezt egy CPU-kreditmodell teszi lehetővé, amely lehetővé teszi, hogy a B sorozatú példányok alacsony processzorhasználati időszakokban "CPU-krediteket" halmozjanak fel. Ezek a kreditek ezután magas processzorhasználati időszakokban is felhasználhatók, ami lehetővé teszi, hogy a példány az alap CPU-teljesítménye fölé törjön.
Fontos azonban megjegyezni, hogy ha egy kipukkasztható példány kimeríti a CPU-krediteket, az alap cpu-teljesítményén működik. Egy Standard_B1ms alap cpu-teljesítménye például 20%, azaz 0,2 virtuális mag. Ha a kipukkasztható rétegkiszolgáló olyan számítási feladatot futtat, amely az alapszintnél nagyobb processzorteljesítményt igényel, és kimerítette a cpu-krediteket, a kiszolgáló teljesítménykorlátozásokat tapasztalhat, és végül hatással lehet a kiszolgáló különböző rendszerműveleteire, például a leállításra/indításra/újraindításra.
Feljegyzés
A kipukkasztható (B sorozatú) számítási szinten lévő kiszolgálók, például Standard_B1s/Standard_B1ms/Standard_B2s viszonylag kisebb gazdagépmemória-méretük folyamatos számítási feladat esetén összeomláshoz (memóriakimaradáshoz) vezethet, még akkor is, ha a memory_percent metrika nem érte el a 100%-ot.
A szabályozás miatt a kiszolgáló csatlakozási problémákba ütközhet, és a rendszerműveleteket is érintheti. Ilyen helyzetekben a javasolt művelet az, hogy szünetelteti a számítási feladatot a kiszolgálón, hogy a B sorozatú hitel banki modellnek megfelelően halmozódjon fel kreditek, vagy fontolja meg a kiszolgáló magasabb szintekre, például általános célú vagy üzletileg kritikus szintekre való skálázását.
Ezért bár a kipukkasztható számítási szint jelentős költség- és rugalmassági előnyöket biztosít bizonyos számítási feladatokhoz, nem ajánlott olyan éles számítási feladatokhoz, amelyek konzisztens processzorteljesítményt igényelnek. A kipukkasztható szint nem támogatja az olvasási replikák és a magas rendelkezésre állású funkciók létrehozását. Az ilyen számítási feladatok és funkciók esetében az egyéb számítási szintek, például az Általános célú vagy a üzletileg kritikus megfelelőbbek.
Az Azure B sorozatú CPU-kreditmodellel kapcsolatos további információkért tekintse meg a B sorozatú kipukkasztható példányokat és a B sorozatú CPU-kreditmodellt.
Cpu-kreditek monitorozása kipukkanható szinten
A cpu-kreditegyenleg monitorozása elengedhetetlen az optimális teljesítmény fenntartásához a burstable számítási szinten. A rugalmas Azure Database for MySQL-kiszolgáló két fő metrikát biztosít a CPU-kreditekhez. A riasztások aktiválásának ideális küszöbértéke a konkrét számítási feladatoktól és teljesítménykövetelményektől függ.
Felhasznált CPU-kredit: Ez a metrika a példány által felhasznált CPU-kreditek számát jelzi. A metrika figyelésével megismerheti a példány processzorhasználati mintáit, és hatékonyan kezelheti annak teljesítményét.
Fennmaradó CPU-kredit: Ez a metrika a példányhoz fennmaradó CPU-kreditek számát mutatja. Ha figyeli ezt a metrikát, megakadályozhatja, hogy a példány teljesítménycsökkenést szenvedjen el a cpu-kreditek kimerítése miatt. Ha a cpu-kredit fennmaradó metrika egy bizonyos szint alá csökken (például a teljes rendelkezésre álló kredit kevesebb mint 30%-a), ez azt jelzi, hogy a példány ki van téve annak a kockázatának, hogy kimeríti a CPU-krediteket, ha az aktuális cpu-terhelés folytatódik.
A metrikákra vonatkozó riasztások beállításáról további információt ebben az útmutatóban talál.
Tárolás
Az Ön által kiépített tárterület a rugalmas kiszolgáló rendelkezésére álló tárolókapacitás-mennyisége. A tároló az adatbázisfájlokhoz, az ideiglenes fájlokhoz, a tranzakciónaplókhoz és a MySQL-kiszolgálónaplókhoz használható. A minimálisan támogatott tárterület 20 GiB, a maximális pedig 16 TiB az összes szolgáltatási szinten. A tárterület 1 GiB-növekményben van skálázva, és a kiszolgáló létrehozása után felskálázható.
Feljegyzés
A tárolást csak felfelé lehet skálázni, lefelé nem.
A tárterület-felhasználást az Azure Portalon (az Azure Monitorral) figyelheti a tárterületkorlát, a tárterület százalékos aránya és a felhasznált tárolási metrikák használatával. A metrikákról a monitorozási cikkből tájékozódhat.
Tárhelykorlát elérése
Ha a kiszolgálón felhasznált tárterület közel van a kiosztott korlát eléréséhez, a kiszolgáló írásvédett üzemmódba kerül, hogy megvédje a kiszolgálót az írások elvesztésétől. A 100 GiB-kiosztott tárterületnél kisebb kiszolgáló írásvédettként van megjelölve, ha az ingyenes tárterület kisebb, mint a kiosztott tárterület méretének 5%-a. A több mint 100 GiB-tárolóval rendelkező kiszolgálók írásvédettként vannak megjelölve, ha az ingyenes tárterület kevesebb, mint 5 GiB.
Ha például 110 GiB tárterületet létesített, és a tényleges kihasználtság meghaladja a 105 GiB-t, a kiszolgáló írásvédettként van megjelölve. Másik lehetőségként, ha 5 GiB tárterületet létesített, a kiszolgáló írásvédettként lesz megjelölve, ha az ingyenes tárterület eléri a 256 MB-ot.
Bár a szolgáltatás megpróbálja írásvédetté tenni a kiszolgálót, az összes új írási tranzakciós kérés le lesz tiltva, és a meglévő aktív tranzakciók továbbra is végrehajtásra kerülnek. A kiszolgáló csak olvashatóként való beállításakor minden későbbi írási művelet és tranzakció meghiúsul. Az olvasási lekérdezések továbbra is zavartalanul működnek.
A kiszolgáló írásvédett módjának megszüntetéséhez növelje a kiszolgálón kiépített tárterületet. Ezt az Azure Portalon vagy az Azure CLI használatával teheti meg. A növekedés után a kiszolgáló készen áll az írási tranzakciók újbóli elfogadására.
Javasoljuk, hogy állítson be egy riasztást, amely értesíti Önt, ha a kiszolgáló tárhelye megközelíti a küszöbértéket, így elkerülheti a csak olvasható állapotba kerülést. További információkért tekintse meg a riasztások beállításának dokumentációját.
A tárterület automatikus növekedése
A tároló automatikus növekedése megakadályozza, hogy a kiszolgáló elfogyjon a tárolóból, és írásvédetté váljon. Ha a tárterület automatikus kihasználtság engedélyezve van, a tárterület automatikusan nő anélkül, hogy ez hatással lenne a számítási feladatra. A tárterület automatikus telepítése alapértelmezés szerint engedélyezve van az összes új kiszolgáló létrehozása esetén. A 100 GB-nál kisebb kiosztott tárterülettel rendelkező kiszolgálók esetében a kiosztott tárterület mérete 5 GB-kal nő, ha az ingyenes tárterület a kiosztott tárterület 10%-a alatt van. A 100 GB-nál nagyobb kiépített tárterülettel rendelkező kiszolgálók esetén a rendszer 5%-kal növeli a kiépített tárterületet, amint a rendelkezésre álló terület 10 GB alá esik a kiépített tárterületen. A fentiekben megadott maximális tárolókorlátok vannak érvényben. A kiszolgálópéldány frissítésével a frissített kiépített tárterület megjelenik a Beállítások menüpont Számítás és tárolás lapján.
Ha például 1000 GB tárterületet létesített, és a tényleges kihasználtság meghaladja a 990 GB-ot, a kiszolgáló tárterületének mérete 1050 GB-ra nő. Másik lehetőségként, ha 20 GB tárterületet létesített, a tárterület mérete 25 GB-ra nő, ha kevesebb mint 2 GB tárterület ingyenes.
Ne feledje, hogy az automatikus méretezést követően a tárterület nem skálázható le.
Feljegyzés
A tároló automatikus kibontása alapértelmezés szerint engedélyezve van egy magas rendelkezésre állású konfigurált kiszolgálón, és nem tiltható le.
IOPS
A rugalmas Azure Database for MySQL-kiszolgáló támogatja az előre kiépített IOPS-t és az automatikus skálázású IOPS-t. További információ. A minimális IOPS 360 az összes számítási méretben, és a maximális IOPS-t a kiválasztott számítási méret határozza meg. Ha többet szeretne megtudni a számítási méretenkénti maximális IOPS-ról, tekintse meg a táblát.
Fontos
**A minimális IOPS 360 minden számítási méretben
**A maximális IOPS-értéket a kiválasztott számítási méret határozza meg.
Az I/O-használatot az Azure Portalon (az Azure Monitorral) az IO százalékos metrikájával figyelheti. Ha a számításon alapuló maximális IOPS-értéknél több IOPS-ra van szüksége, akkor skáláznia kell a kiszolgáló számítását.
Előre kiépített IOPS
A rugalmas Azure Database for MySQL-kiszolgáló előre kiépített IOPS-t kínál, amely lehetővé teszi, hogy meghatározott számú IOPS-t rendeljen a rugalmas Azure Database for MySQL-kiszolgálópéldányhoz. Ez a beállítás konzisztens és kiszámítható teljesítményt biztosít a számítási feladatokhoz. Az előre kiosztott IOPS-val meghatározhat egy meghatározott IOPS-korlátot a tárterületre vonatkozóan, garantálva a másodpercenkénti kérések kezelését. Ez megbízható és biztos teljesítményt eredményez. Az előre kiosztott IOPS lehetővé teszi további IOPS kiépítését az IOPS-korlát felett. A funkció azt is lehetővé teszi, hogy a számítási feladatok követelményei alapján bármikor csökkentse vagy növelje az IOPS-mennyiséget.
IOPS automatikus méretezése
A rugalmas Azure Database for MySQL-kiszolgáló sarokköve, hogy képes a legjobb teljesítményt elérni az 1. rétegbeli számítási feladatokhoz, ami javítható azáltal, hogy lehetővé teszi, hogy a kiszolgáló automatikusan skálázza az adatbázis-kiszolgálók teljesítményét (IO) a számítási feladatok igényeinek megfelelően. Ez egy olyan bejelentkezési funkció, amellyel a felhasználók igény szerint méretezhetik az IOPS-t anélkül, hogy előre ki kellene építeniük egy bizonyos mennyiségű IO-t másodpercenként. Az automatikus skálázású IOPS kiemelt engedélyezésével mostantól élvezheti a rugalmas Azure Database for MySQL-kiszolgálón az ingyenes IO-felügyeletet, mivel a kiszolgáló a számítási feladatok igényeitől függően automatikusan fel- vagy leskálázza az IOPS-eket.
Az automatikus skálázású IOPS-ben csak a kiszolgáló által használt IO-ért kell fizetnie, és nem kell többé kiépítenie és fizetnie a nem teljes mértékben használt erőforrásokért, így időt és pénzt takaríthat meg. Emellett a kritikus fontosságú 1. rétegbeli alkalmazások konzisztens teljesítményt érhetnek el azáltal, hogy bármikor további IO-t tehetnek elérhetővé a számítási feladatok számára. Az automatikus skálázási IOPS kiküszöböli a rugalmas Azure Database for MySQL-kiszolgálói ügyfelek számára a lehető legjobb teljesítmény biztosításához szükséges adminisztrációt.
Dinamikus skálázás: Az IOPS automatikus méretezése dinamikusan módosítja az adatbázis-kiszolgáló IOPS-korlátját a számítási feladat tényleges igényei alapján. Ez manuális beavatkozás vagy konfigurálás nélkül biztosítja az optimális teljesítményt.
Számítási feladatok kiugró értékeinek kezelése: Az automatikus skálázási IOPS lehetővé teszi, hogy az adatbázis zökkenőmentesen kezelje a számítási feladatok csúcsait vagy ingadozásait az alkalmazások teljesítményének veszélyeztetése nélkül. Ez a funkció egyenletes válaszidőt biztosít még a csúcshasználati időszakokban is.
Költségmegtakarítás: Ellentétben az előre kiosztott IOPS-sel, ahol rögzített IOPS-korlát van megadva, és használattól függetlenül fizetnek érte, az automatikus skálázási IOPS csak a felhasznált I/O-műveletek számáért teszi lehetővé a fizetést.
Backup
A szolgáltatás automatikusan biztonsági másolatot készít a kiszolgálóról. Megőrzési időtartamot 1 és 35 nap között választhat. További információ a biztonsági másolatokról a biztonsági mentési és visszaállítási fogalmakról szóló cikkben.
Erőforrások skálázása
A kiszolgáló létrehozása után egymástól függetlenül módosíthatja a számítási szintet, a számítási méretet (virtuális magok és memória), valamint a tárterület mennyiségét és a biztonsági mentés megőrzési időtartamát. A számítási méret fel- vagy leskálázható. A biztonsági másolatok megőrzési időtartama 1-től 35 napig fel- vagy leskálázható. A tárterület mérete csak növelhető. Az erőforrások skálázása a portálon vagy az Azure CLI-vel végezhető el.
Feljegyzés
A tárterület mérete csak növelhető. A növekedés után nem léphet vissza kisebb méretűre.
A számítási szint vagy a számítási méret módosításakor a kiszolgáló újraindul az új kiszolgálótípus érvénybe lépéséhez. Az új kiszolgálóra való váltás pillanatában nem hozható létre új kapcsolat, és a nem véglegesített tranzakciók vissza lesznek állítva. Ez az ablak változó, de a legtöbb esetben 60-120 másodperc között van.
A tárterület skálázása és a biztonsági másolatok megőrzési idejének módosítása online műveletek, és nem igényelnek kiszolgáló-újraindítást.
Díjszabás
A legfrissebb díjszabási információkért tekintse meg a szolgáltatás díjszabási oldalát. A kívánt konfiguráció költségeinek megtekintéséhez az Azure Portal megjeleníti a havi költséget a Compute + Storage lapon a kiválasztott beállítások alapján. Ha nem rendelkezik Azure-előfizetéssel, az Azure díjszabási kalkulátorával lekérheti a becsült árat. Az Azure díjkalkulátor webhelyén válassza az Elemek hozzáadása lehetőséget, bontsa ki az Adatbázisok kategóriát, válassza az Azure Database for MySQL-t és a rugalmas kiszolgálót üzembehelyezési típusként a beállítások testreszabásához.
Ha optimalizálni szeretné a kiszolgáló költségeit, a következő tippeket érdemes megfontolnia:
- A számítási szint vagy a számítási méret (virtuális magok) vertikális leskálázása, ha a számítás kihasználatlan.
- Érdemes lehet átváltani a Burstable számítási szintre, ha a számítási feladatnak nincs szüksége a teljes számítási kapacitásra folyamatosan az Általános célú és üzletileg kritikus szintekről.
- Állítsa le a kiszolgálót, ha nincs használatban.
- Csökkentse a biztonsági mentés megőrzési időtartamát, ha nincs szükség hosszabb biztonsági mentésre.
Kapcsolódó tartalom
- Megtudhatja, hogyan hozhat létre rugalmas Azure Database for MySQL-kiszolgálópéldányt a portálon.
- További információ a szolgáltatáskorlátozásokról.