Megosztás a következőn keresztül:

Az Azure Database for MySQL rugalmas 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 szolgáltatási szint egyikében hozhat létre: Burstable, General Purpose és Business Critical. A virtuális gép mögöttes SKU-ja különbözteti meg a B sorozat, a D sorozat és az E sorozat által használt szolgáltatási szinteket. 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. A pontos tárolási technológiát az összes szolgáltatási szinten használják. Minden erőforrás az Azure Database for MySQL rugalmas 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
VM-sorozatok B-sorozatú átmenetileg fokozható virtuális gépek méretei 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 vCore-onként Változó 4 GiB 8 GiB **
Tárterület mérete 20 GiB–16 TiB 20 GiB–16 TiB 20 GiB–32 TiB
Adatbázis biztonsági mentésének megőrzési időtartama 1–35 nap 1–35 nap 1–35 nap

** Kivéve a 64,80 és 96 virtuális magot, amelyek 504 GiB, 504 GiB és 672 GiB memóriával rendelkeznek.

* Az Ev5 compute a legjobban teljesít a többi virtuálisgép-sorozat közül a QPS és a késés tekintetében. Itt tudhat meg többet az Ev5-számítás teljesítményéről és régiónkénti elérhetőségéről.

Rugalmas kiszolgálói szolgáltatási szintek

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 munkaterhelések
Átmenetileg fokozható teljesítmény A legjobb olyan számítási feladatokhoz, amelyeknek nincs szükségük a teljes CPU-ra.
általános célú A legtöbb üzleti számítási feladat 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 módosíthatja a számítási szintet, a számítási méretet és a tárterület méretét. 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árterület-méretezés nem. A biztonsági mentés megőrzési időtartamát önállóan is módosíthatja felfelé vagy lefelé. További információkért tekintse meg az Erőforrások méretezése szakaszt.

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.

Átmenetileg fokozható teljesítmény

Az elérhető kiszolgálótípusok részletes specifikációi a burstable szolgáltatási szinthez a következők.

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 Ideiglenes tárhely (SSD) GiB
Standard_B1ms 1 2 2,2 640 341 0
Standard_B2s 2 4 4.4 1280 683 0
Standard_B2ms 2 8 8.8 1700-as év 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. 5 000 13653 0

Megjegyzés: A kipukkasztható számítási szint olyan nem gyártási számítási feladatokhoz lett kialakítva, mint a fejlesztési, előkészítési vagy tesztelési környezetek, ezért nem jogosult a 24/7 támogatásra vagy a kiváltó okok elemzésére (RCA).

általános célú

Az elérhető kiszolgálótípusok részletes specifikációi az általános célú szolgáltatási szinthez a következők:

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 Ideiglenes tárhely (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 12 800 5461 215
Standard_D8ds_v4 8 32 44 12 800 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 48000 32 768 1290
Standard_D48ds_v4 48 192 264 48000 32 768 1290
Standard_D64ads_v5 64 256 352 48000 43691 1720
Standard_D64ds_v4 64 256 352 48000 43691 1720
Standard_D96ads_v5 96 384 528 48000 65536 2580

üzletileg kritikus

Az elérhető kiszolgálótípusok részletes specifikációi a üzletileg kritikus szolgáltatási szinthez a következők.

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 Ideiglenes tárhely (SSD) GiB
Standard_E2ds_v4 2 16 22 5 000 2731 37
Standard_E2ads_v5, Standard_E2ds_v5 2 16 22 5 000 2731 37
Standard_E4ds_v4 4 32 44 10 000 5461 75
Standard_E4ads_v5, Standard_E4ds_v5 4 32 44 10 000 5461 75
Standard_E8ds_v4 8 64 88. 18 000 10923 151
Standard_E8ads_v5, Standard_E8ds_v5 8 64 88. 18 000 10923 151
Standard_E16ds_v4 16 128 176 28000 21845 302
Standard_E16ads_v5, Standard_E16ds_v5 16 128 176 28000 21845 302
Standard_E20ds_v4 20 160 220 28000 27306 377
Standard_E20ads_v5, Standard_E20ds_v5 20 160 220 28000 27306 377
Standard_E32ds_v4 32 256 352 38000 43691 604
Standard_E32ads_v5, Standard_E32ds_v5 32 256 352 38000 43691 604
Standard_E48ds_v4 48 384 528 48000 65536 906
Standard_E48ads_v5, Standard_E48ds_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_E64ds_v5 64 512 704 64000 87383 1208
Standard_E80ids_v4 80 504 693 72000 86016 1224
Standard_E96ads_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) lévő 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% használ.

MySQL-kiszolgáló (mysqld)

Az Azure MySQL-kiszolgáló folyamata( mysqld) az adatbázis-üzemeltetési motor. 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.

Témák

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 VM dokumentációt a B sorozatú felfutásos virtuálisgép-méretekkel, az Általános célú Dadsv5- és Ddsv4-sorozatokkal, valamint az Üzletileg kritikus Edsv4, /- és Eadsv5-sorozatokkal kapcsolatban.

A kipukkanható sorozatpéldányok teljesítménykorlátozásai

Feljegyzés

B sorozatú, kipukkasztható virtuálisgép-méretek esetén a virtuális gép indítása/leállítása vagy újraindítása esetén előfordulhat, hogy a kreditek elvesznek. További információért lásd: B sorozatú, rugalmasan skálázható virtuális gépek méretei.

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 olyan nem gyártási számítási feladatokhoz, mint a fejlesztési, előkészítési vagy tesztelési környezetek. 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. Tegyük fel, hogy a burstable rétegkiszolgáló olyan számítási feladatot futtat, amely az alapszintnél nagyobb processzorteljesítményt igényel, és kimerítette a PROCESSZOR-krediteket. Ebben az esetben előfordulhat, hogy a kiszolgáló teljesítménykorlátozásokat tapasztal, é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 B sorozatú, kipukkasztható virtuálisgép-méretekben (például Standard_B1s/Standard_B1ms/Standard_B2s) lévő kiszolgálók viszonylag kisebb gazdamemóriája folyamatos számítási feladat esetén összeomláshoz (memóriakihasználtsághoz) 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 Burstable szint nem támogatja az Azure Database for MySQL - Rugalmas kiszolgáló funkcióban az Olvasási replikák létrehozásának és a Azure Database for MySQL - Rugalmas kiszolgáló szolgáltatáson belüli magas rendelkezésre állás koncepciójának használatát. Az egyéb számítási szintek, például az általános célú vagy üzletileg kritikus, jobban megfelelnek az ilyen számítási feladatoknak és funkcióknak.

Az Azure B sorozatú CPU-kreditmodellel kapcsolatos további információkért tekintse meg a B sorozatú, kipukkasztható virtuális gépek méretét és a B sorozatú CPU-kreditmodellt.

CPU-kreditek monitorozása rugalmas 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 számítási feladattól és a teljesítménykövetelményektől függ.

Monitorozza az Azure Database for MySQL - Rugalmas kiszolgálót: Ez a metrika azt jelzi, hogy a példány hány CPU-kreditet használt fel. A metrika figyelésével megismerheti a példány processzorhasználati mintáit, és hatékonyan kezelheti annak teljesítményét.

Azure Database for MySQL – Rugalmas Kiszolgáló monitorozása: Ez a metrika a példányhoz rendelkezésre álló CPU-kreditek számát mutatja. A metrika monitorozásával megakadályozhatja, hogy a példány teljesítménycsökkenést szenvedjen 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.

Storage

A kiosztott tároló a rugalmas kiszolgáló számára elérhető tárolókapacitás. 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 burstable és az általános célú szolgáltatási szintek esetében a tárterület legalább 20 GiB-től legfeljebb 16 TiB-osig terjed. Ezzel szemben a tárolási támogatás akár 32 TiB-ot is kiterjeszthet üzletileg kritikus szolgáltatási szinthez. A tárterület minden szolgáltatási szinten 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.

A tárterület korlátjának 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 a kiszolgálón lévő elveszett írások védelme érdekében. 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 kisebb, 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édetté válik, amikor a szabad tárhely kevesebb mint 256 MB-ra csökken.

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. Ha a kiszolgáló írásvédettre van állítva, minden későbbi írási művelet és tranzakció véglegesítése meghiúsul, de 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 kapcsolja be a tárterület automatikus növelését , vagy á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 az írásvédett állapotba kerülést. További információkért tekintse meg a riasztások beállításának dokumentációját.

Automatikus tárhely-növekedés

A tárhely automatikus növelése megakadályozza, hogy a kiszolgáló kifusson a tárhelyből, és írásvédetté váljon. Ha a tárterület automatikus növekedése engedélyezve van, a tárterület automatikusan nő a számítási feladat befolyásolása nélkül. A tárterület automatikus növekedése alapértelmezés szerint engedélyezve van az új kiszolgálók létrehozásakor. 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 a magas rendelkezésre állású konfigurált kiszolgálókhoz és a gyorsított naplókhoz engedélyezett kiszolgálókhoz, é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. Storage IOPS az Azure Database for MySQL-ben – rugalmas kiszolgáló : A minimális IOPS 360 minden számítási méretben, a maximális IOPS-t pedig 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ázatot.

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) monitorozhatja az Azure Database for MySQL rugalmas kiszolgálómetrikájával. Ha a számítás alapján több IOPS-ra van szüksége, mint a maximális IOPS-érték, 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. Ez 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 az opt-in funkció lehetővé teszi a felhasználók számára az IOPS igény szerinti skálázásá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 funkcióval mostantól gondtalan IO-kezelést élvezhet a rugalmas Azure Database for MySQL-kiszolgálón, mivel a kiszolgáló a számítási feladatok igényeinek megfelelően automatikusan fel- vagy leskálázza az IOPS-eket. Az automatikus skálázási IOPS automatikusan felskálázódik az egyes szolgáltatási szintek maximális támogatott IOPS-értékére és számítási méretére a szolgáltatási szintek dokumentációjában meghatározottak szerint. Ez biztosítja az optimális teljesítményt manuális skálázási erőfeszítések nélkül

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 elérhetővé teszik a további IO-t a számítási feladat számára. Az automatikus IOPS-skálázás kiküszöböli az adminisztráció szükségességét, amely az Azure Database for MySQL rugalmas kiszolgáló ügyfelei számára a lehető legjobb teljesítmény eléréséhez szükséges, minimális költségek mellett.

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: Az előre kiosztott IOPS-sel ellentétben, amely rögzített IOPS-korlátot határoz meg, és használattól függetlenül fizet, az automatikus skálázási IOPS csak a felhasznált I/O-műveletek számáért fizethet.

Backup

A szolgáltatás automatikusan biztonsági másolatot készít a kiszolgálóról. 1–35 napos megőrzési időtartamot 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 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), 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 vertikálisan fel- vagy leskálázható, a biztonsági mentés megőrzési időtartama pedig 1 és 35 nap között 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 tárolási méretre.

A számítási szint vagy a számítási méret módosításakor a kiszolgálót újra kell indítani az új kiszolgálótípus érvénybe lépéséhez. Amikor a rendszer átvált az új kiszolgálóra, nem hozható létre új kapcsolat, és a rendszer visszaállítja az összes nem véglegesített tranzakciót. Ez az ablak változó, de a legtöbb esetben 60 és 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.

Ár

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, az alábbi tippeket érdemes figyelembe vennie:

  • Csökkentse a számítási szintet vagy a számítási méretet (virtuális magok), ha a számítás nincs teljesen kihasználva.
  • É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

  • Last updated on