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

Kiszolgálóparaméterek az Azure Database for MySQL-ben – rugalmas kiszolgáló

Ez a cikk megfontolandó szempontokat és irányelveket tartalmaz a kiszolgálóparaméterek konfigurálásához a rugalmas Azure Database for MySQL-kiszolgálón.

Feljegyzés

Ez a cikk a Microsoft által már nem használt rabszolga kifejezésre mutató hivatkozásokat tartalmaz. Ha a kifejezés el lesz távolítva a szoftverből, eltávolítjuk ebből a cikkből.

Mik azok a kiszolgálóparaméterek?

A MySQL-motor számos kiszolgálóparamétert (más néven változót) biztosít, amelyekkel konfigurálhatja és hangolhatja a motor viselkedését. Egyes paraméterek futásidőben dinamikusan állíthatók be. Mások statikusak, és a beállítás után újra kell indítani a kiszolgálót.

A rugalmas Azure Database for MySQL-kiszolgálón módosíthatja a különböző MySQL-kiszolgálóparaméterek értékét az Azure Database for MySQL -rugalmas kiszolgáló kiszolgálóparamétereinek konfigurálásával az Azure Portal használatával, valamint a kiszolgálóparaméterek konfigurálása az Azure Database for MySQL-ben – rugalmas kiszolgálói paraméterek konfigurálása az Azure CLI használatával a számítási feladat igényeinek megfelelően.

Konfigurálható kiszolgálóparaméterek

A rugalmas Azure Database for MySQL-kiszolgáló konfigurációját kiszolgálóparaméterek használatával kezelheti. A kiszolgálóparaméterek a kiszolgáló létrehozásakor az alapértelmezett és ajánlott értékekkel vannak konfigurálva. Az Azure Portal Kiszolgálóparaméterek paneljén mind a módosítható, mind a nem módosítható paraméterek láthatók. A nem módosítható kiszolgálóparaméterek nem érhetők el.

A támogatott kiszolgálóparaméterek listája folyamatosan növekszik. Az Azure Portal használatával rendszeresen megtekintheti a kiszolgálóparaméterek teljes listáját, és konfigurálhatja az értékeket.

Ha a portál használatával módosít egy statikus kiszolgálóparamétert, újra kell indítania a kiszolgálót a módosítások érvénybe lépéséhez. Ha automatizálási szkripteket használ (például Azure Resource Manager-sablonokon, Terraformon vagy Az Azure CLI-ben), a szkriptnek rendelkeznie kell egy kiosztással, amely újraindítja a szolgáltatást a beállítások érvénybe lépéséhez, még akkor is, ha a konfigurációt a létrehozási folyamat részeként módosítja.

Ha módosítani szeretne egy nem módosítható kiszolgálóparamétert a környezetéhez, küldjön egy ötletet közösségi visszajelzésen keresztül, vagy szavazzon, ha a visszajelzés már létezik (ami segíthet a rangsorolásban).

A következő szakaszok a gyakran frissített kiszolgálóparaméterek korlátait ismertetik. A korlátokat a kiszolgáló számítási szintje és mérete (virtuális magok) határozzák meg.

lower_case_table_names

A MySQL 8.0+-os verziójához További információ. lower_case_table_names A kiszolgáló inicializálása után a beállítás módosítása tilos. A MySQL 8.0-s verziójának támogatott értékei a rugalmas Azure Database for MySQL-kiszolgálón találhatók 12 . Az alapértelmezett érték 1.

Ezeket a beállításokat a portálon a kiszolgáló létrehozása során úgy konfigurálhatja, hogy megadja a kívánt értéket a Kiszolgálóparaméterek területen a További konfiguráció lapon. Visszaállítási műveletek vagy replikakiszolgáló létrehozásakor a paraméter automatikusan ki lesz másolva a forráskiszolgálóról, és nem módosítható.

Képernyőkép a kisbetűs táblanév-kiszolgáló paraméterének konfigurálásáról a létrehozáskor.

A MySQL 5.7-es verziója esetén az alapértelmezett érték lower_case_table_names a rugalmas Azure Database for MySQL-kiszolgálón található 1 . Bár a támogatott érték 2módosítható, a visszalépés 21 nem engedélyezett. Ha segítségre van szüksége az alapértelmezett érték módosításához, hozzon létre egy támogatási jegyet.

innodb_tmpdir

A rugalmas Azure Database for MySQL-kiszolgáló innodb_tmpdir paraméterével definiálhatja az újraépítendő online ALTER TABLE műveletek során létrehozott ideiglenes rendezési fájlok könyvtárát.

Az alapértelmezett érték az innodb_tmpdir/mnt/temp. Ez a hely az ideiglenes tárolónak (SSD) felel meg, és gibibyte-ben (GiB) érhető el minden egyes kiszolgáló számítási méretével. Ez a hely ideális olyan műveletekhez, amelyek nem igényelnek nagy mennyiségű helyet.

Ha több helyre van szüksége, beállíthatja a következőt innodb_tmpdir/app/work/tmpdir: . Ez a beállítás a rugalmas Azure Database for MySQL-kiszolgálón elérhető tárkapacitást használja. Ez a beállítás olyan nagyobb műveleteknél lehet hasznos, amelyek több ideiglenes tárterületet igényelnek.

Ne feledje, hogy az eredmények használata /app/work/tmpdir az alapértelmezett ideiglenes tárolási (SSD)képest lassabb teljesítményt eredményez. Döntsön a műveletek konkrét követelményei alapján.

A megadott innodb_tmpdir információk a innodb_temp_tablespaces_dir, tmpdir és slave_load_tmpdir paraméterekre vonatkoznak, ahol:

  • Az alapértelmezett érték /mnt/temp gyakori.
  • Az alternatív címtár /app/work/tmpdir a megnövekedett ideiglenes tárolás konfigurálásához érhető el, és a teljesítmény adott üzemeltetési követelményeken alapuló kompromisszumot biztosít.

log_bin_trust_function_creators

A rugalmas Azure Database for MySQL-kiszolgálón a bináris naplók mindig engedélyezve vannak (azaz log_bin a beállítás ONértéke). A log_bin_trust_function_creators paraméter alapértelmezés szerint rugalmas kiszolgálókon van beállítva ON .

A bináris naplózási formátum mindig ROWa soralapú bináris naplózást használja, és a kiszolgálóhoz való kapcsolatok mindig soralapú bináris naplózást használnak. Soralapú bináris naplózás esetén a biztonsági problémák nem léteznek, és a bináris naplózás nem tud megtörni, így biztonságosan engedélyezheti log_bin_trust_function_creators , hogy továbbra is mint ON.

Ha log_bin_trust_function_creators be van állítva OFF , és megpróbál triggereket létrehozni, a következőhöz hasonló hibaüzenetek jelenhetnek meg: "Nem rendelkezik SUPER jogosultsággal, és a bináris naplózás engedélyezve van (érdemes lehet a kevésbé biztonságos log_bin_trust_function_creators változót használni)."

innodb_buffer_pool_size (az InnoDB adatbázis motor puffer medence mérete)

A paraméter megismeréséhez innodb_buffer_pool_size tekintse át a MySQL dokumentációját.

Az alábbi táblázatban szereplő fizikai memória mérete a rugalmas Azure Database for MySQL-kiszolgálón elérhető véletlenszerű hozzáférésű memória (RAM) gigabájtban (GB) kifejezve.

Számítási méret Virtuális magok Fizikai memória mérete (GB) Alapértelmezett érték (bájt) Minimális érték (bájt) Maximális érték (bájt)
Kipukkanható
Standard_B1s 0 0 134217728 33554432 268435456
Standard_B1ms 0 2 536870912 134217728 1073741824
Standard_B2s 2 4 2147483648 134217728 2147483648
Standard_B2ms 2 8 4294967296 134217728 5368709120
Standard_B4ms 4 16 12884901888 134217728 12884901888
Standard_B8ms 8 32 25769803776 134217728 25769803776
Standard_B12ms 12 48 51539607552 134217728 32212254720
Standard_B16ms 16 64 2147483648 134217728 51539607552
Standard_B20ms 20 80 64424509440 134217728 64424509440
Általános célú
Standard_D2ads_v5 2 8 4294967296 134217728 5368709120
Standard_D2ds_v4 2 8 4294967296 134217728 5368709120
Standard_D4ads_v5 4 16 12884901888 134217728 12884901888
Standard_D4ds_v4 4 16 12884901888 134217728 12884901888
Standard_D8ads_v5 8 32 25769803776 134217728 25769803776
Standard_D8ds_v4 8 32 25769803776 134217728 25769803776
Standard_D16ads_v5 16 64 51539607552 134217728 51539607552
Standard_D16ds_v4 16 64 51539607552 134217728 51539607552
Standard_D32ads_v5 32 128 103079215104 134217728 103079215104
Standard_D32ds_v4 32 128 103079215104 134217728 103079215104
Standard_D48ads_v5 48 192 154618822656 134217728 154618822656
Standard_D48ds_v4 48 192 154618822656 134217728 154618822656
Standard_D64ads_v5 64 256 206158430208 134217728 206158430208
Standard_D64ds_v4 64 256 206158430208 134217728 206158430208
üzletileg kritikus
Standard_E2ds_v4 2 16 12884901888 134217728 12884901888
Standard_E2ads_v5, Standard_E2ds_v5 2 16 12884901888 134217728 12884901888
Standard_E4ds_v4 4 32 25769803776 134217728 25769803776
Standard_E4ads_v5, Standard_E4ds_v5 4 32 25769803776 134217728 25769803776
Standard_E8ds_v4 8 64 51539607552 134217728 51539607552
Standard_E8ads_v5, Standard_E8ds_v5 8 64 51539607552 134217728 51539607552
Standard_E16ds_v4 16 128 103079215104 134217728 103079215104
Standard_E16ads_v5, Standard_E16ds_v5 16 128 103079215104 134217728 103079215104
Standard_E20ds_v4 20 160 128849018880 134217728 128849018880
Standard_E20ads_v5, Standard_E20ds_v5 20 160 128849018880 134217728 128849018880
Standard_E32ds_v4 32 256 206158430208 134217728 206158430208
Standard_E32ads_v5, Standard_E32ds_v5 32 256 206158430208 134217728 206158430208
Standard_E48ds_v4 48 384 309237645312 134217728 309237645312
Standard_E48ads_v5, Standard_E48ds_v5 48 384 309237645312 134217728 309237645312
Standard_E64ds_v4 64 504 405874409472 134217728 405874409472
Standard_E64ads_v5 , Standard_E64ds_v5 64 512 412316860416 134217728 412316860416
Standard_E80ids_v4 80 504 405874409472 134217728 405874409472
Standard_E96ds_v5 96 672 541165879296 134217728 541165879296

innodb_file_per_table

A MySQL az InnoDB-táblát különböző táblaterekben tárolja a tábla létrehozása során megadott konfiguráció alapján. A rendszer táblatere az InnoDB adatszótár tárolási területe. A táblánkénti fájltáblázatok egyetlen InnoDB-tábla adatait és indexeit tartalmazzák, és a fájlrendszerben tárolják a saját adatfájljában. Ezt a viselkedést a innodb_file_per_table kiszolgálóparaméter vezérli.

A beállítás innodb_file_per_table hatására az OFF InnoDB táblákat hoz létre a rendszer táblaterében. Ellenkező esetben az InnoDB táblákat hoz létre a fájlonkénti táblaterekben.

Az Azure Database for MySQL – Rugalmas kiszolgáló egyetlen adatfájlban legfeljebb 8 terabájtot (TB) támogat. Ha az adatbázis mérete 8 TB-nál nagyobb, akkor a táblát a innodb_file_per_table táblatérben kell létrehoznia. Ha egyetlen táblázatmérete nagyobb, mint 8 TB, használja a partíciótáblát.

innodb_log_file_size

A innodb_log_file_size értéke a naplófájlok mérete (bájtban). A naplófájlok összesített mérete (innodb_log_file_size * innodb_log_files_in_group) nem haladhatja meg az 512 GB-nál valamivel kisebb maximális értéket.

A nagyobb naplófájlméret jobb a teljesítményhez, de hátránya, hogy az összeomlás utáni helyreállítási idő magas. Ki kell egyensúlyoznia a helyreállítási időt egy összeomlás ritka eseménye esetén, és maximalizálnia kell az átviteli sebességet a csúcsműveletek során. A nagyobb naplófájlméret hosszabb újraindítási időt is eredményezhet.

Konfigurálhat innodb_log_size 256 megabájtot (MB), 512 MB-ot, 1 GB-ot vagy 2 GB-ot a rugalmas Azure Database for MySQL-kiszolgálóhoz. A paraméter statikus, és újraindítást igényel.

Feljegyzés

Ha a paramétert az innodb_log_file_size alapértelmezett értékről módosította, ellenőrizze, hogy az érték 30 másodpercig show global status like 'innodb_buffer_pool_pages_dirty' marad-e az újraindítás késleltetésének 0 elkerülése érdekében.

maximális_kapcsolatok

A kiszolgáló memóriamérete határozza meg a max_connections. Az alábbi táblázatban szereplő fizikai memóriaméret a rugalmas Azure Database for MySQL-kiszolgálón gigabájtban elérhető RAM-ot jelöli.

Számítási méret Virtuális magok Fizikai memória mérete (GB) Alapértelmezett érték Minimális érték Maximális érték
Kipukkanható
Standard_B1s 0 0 85 10 171
Standard_B1ms 0 2 171 10 341
Standard_B2s 2 4 341 10 683
Standard_B2ms 2 4 683 10 1365
Standard_B4ms 4 16 1365 10 2731
Standard_B8ms 8 32 2731 10 5461
Standard_B12ms 12 48 4097 10 8193
Standard_B16ms 16 64 5461 10 10923
Standard_B20ms 20 80 6827 10 13653
Általános célú
Standard_D2ads_v5 2 8 683 10 1365
Standard_D2ds_v4 2 8 683 10 1365
Standard_D4ads_v5 4 16 1365 10 2731
Standard_D4ds_v4 4 16 1365 10 2731
Standard_D8ads_v5 8 32 2731 10 5461
Standard_D8ds_v4 8 32 2731 10 5461
Standard_D16ads_v5 16 64 5461 10 10923
Standard_D16ds_v4 16 64 5461 10 10923
Standard_D32ads_v5 32 128 10923 10 21845
Standard_D32ds_v4 32 128 10923 10 21845
Standard_D48ads_v5 48 192 16384 10 32 768
Standard_D48ds_v4 48 192 16384 10 32 768
Standard_D64ads_v5 64 256 21845 10 43691
Standard_D64ds_v4 64 256 21845 10 43691
üzletileg kritikus
Standard_E2ds_v4 2 16 1365 10 2731
Standard_E2ads_v5, Standard_E2ds_v5 2 16 1365 10 2731
Standard_E4ds_v4 4 32 2731 10 5461
Standard_E4ads_v5, Standard_E4ds_v5 4 32 2731 10 5461
Standard_E8ds_v4 8 64 5461 10 10923
Standard_E8ads_v5, Standard_E8ds_v5 8 64 5461 10 10923
Standard_E16ds_v4 16 128 10923 10 21845
Standard_E16ads_v5, Standard_E16ds_v5 16 128 10923 10 21845
Standard_E20ds_v4 20 160 13653 10 27306
Standard_E20ads_v5, Standard_E20ds_v5 20 160 13653 10 27306
Standard_E32ds_v4 32 256 21845 10 43691
Standard_E32ads_v5, Standard_E32ds_v5 32 256 21845 10 43691
Standard_E48ds_v4 48 384 32 768 10 65536
Standard_E48ads_v5, Standard_E48ds_v5 48 384 32 768 10 65536
Standard_E64ds_v4 64 504 43008 10 86016
Standard_E64ads_v5, Standard_E64ds_v5 64 512 43691 10 87383
Standard_E80ids_v4 80 504 43008 10 86016
Standard_E96ds_v5 96 672 50000 10 100 000

Ha a kapcsolatok túllépik a korlátot, a következő hibaüzenet jelenhet meg: "HIBA: 1040 (08004): Túl sok kapcsolat".

Az új ügyfélkapcsolatok létrehozása a MySQL-hez időt vesz igénybe. A kapcsolatok létrehozása után azok akkor is lefoglalják az adatbázis-erőforrásokat, ha inaktívak. A legtöbb alkalmazás sok rövid élettartamú kapcsolatot igényel, ami ezt a helyzetet is meghatározza. Az eredmény az, hogy kevesebb erőforrás érhető el a tényleges számítási feladathoz, ami a teljesítmény csökkenéséhez vezet.

Egy kapcsolatkészletező, amely csökkenti az üresjárati kapcsolatokat, és újra felhasználja a meglévő kapcsolatokat, segít elkerülni ezt a problémát. A legjobb élmény érdekében javasoljuk, hogy a kapcsolatok hatékony kezeléséhez használjon egy olyan kapcsolatkészletezőt, mint a ProxySQL. A ProxySQL beállításával kapcsolatos további információkért tekintse meg ezt a blogbejegyzést.

Feljegyzés

A ProxySQL egy nyílt forráskódú közösségi eszköz. A Microsoft minden tőle telhetőt megtesz. Ha mérvadó útmutatással szeretne éles támogatást kapni, forduljon a ProxySQL terméktámogatásához.

innodb_strict_mode

Ha a "Túl nagy sorméret (> 8126) " hibához hasonló hibaüzenet jelenik meg, érdemes lehet kikapcsolni a innodb_strict_mode kiszolgálóparamétert. Ez a paraméter globálisan nem módosítható a kiszolgáló szintjén, mert ha a soradatok mérete nagyobb, mint 8K, akkor az adatok hiba nélkül csonkulnak. Ez a csonkolás potenciális adatvesztéshez vezethet. Javasoljuk, hogy módosítsa a sémát az oldalméret korlátjának megfelelően.

Ezt a paramétert a munkamenet szintjén állíthatja be a következővel init_connect: . További információ: Nem módosítható kiszolgálóparaméterek beállítása.

Feljegyzés

Ha olvasási replikakiszolgálóval rendelkezik, a forráskiszolgáló munkamenet szintjén történő beállítása innodb_strict_modeOFF megszakítja a replikációt. Javasoljuk, hogy ON az olvasási replikák esetén állítsa be a paramétert.

időzóna

Az időzóna-táblákat feltöltheti a legújabb időzóna-adatokkal, ha meghívja a mysql.az_load_timezone tárolt eljárást egy olyan eszközről, mint a MySQL parancssor vagy a MySQL Workbench, majd az Azure Portal vagy az Azure CLI használatával beállíthatja a globális időzónákat. Az időzónákat a rendszer automatikusan betölti a kiszolgáló létrehozásakor, így az ügyfeleknek nincs szükségük arra, hogy manuálisan végrehajtsák a mysql.az_load_timezone tárolt eljárást az időzóna betöltéséhez.

innodb_temp_data_file_size_max

Rugalmas Azure Database for MySQL-kiszolgáló esetén (csak 5.7-es verzió) innodb_temp_data_file_size_max paraméter határozza meg az InnoDB ideiglenes táblatér adatfájljainak maximális méretét MB-ban. Az érték 0 értékre állítása nem jelent korlátot, ami lehetővé teszi a teljes tárterület méretének növelését. A 64 MB alatti nem nulla értékek 64 MB-ra vannak kerekítve, míg a 64 MB feletti értékek a megadott módon lesznek alkalmazva. Ez egy statikus változó, és a módosítások érvénybe lépéséhez újra kell indítani a kiszolgálót.

Feljegyzés

  • Megjegyzés: A MySQL 8.0-s és újabb verziókban a globális ideiglenes táblatér (ibtmp1) csak a felhasználó által létrehozott ideiglenes táblák módosításaihoz tárolja a visszaállítási szegmenseket. Ezért ez a paraméter már nem releváns.

binlog_expire_logs_seconds

A rugalmas Azure Database for MySQL-kiszolgálón a binlog_expire_logs_seconds paraméter megadja, hogy a szolgáltatás hány másodpercet vár a bináris naplófájl törlése előtt.

A bináris napló olyan eseményeket tartalmaz, amelyek az adatbázis változásait írják le, például a táblalétrehozási műveleteket vagy a táblaadatok módosítását. A bináris napló olyan utasítások eseményeit is tartalmazza, amelyek esetleg módosításokat is okozhattak. A bináris naplót elsősorban két célra használják: replikációs és adat-helyreállítási műveletekre.

A bináris naplók általában azonnal törlődnek, amint a leíró mentes a szolgáltatástól, a biztonsági mentéstől vagy a replikakészlettől. Ha több replika is létezik, a bináris naplók megvárják, amíg a leglassabb replika felolvassa a módosításokat a törlés előtt.

Ha hosszabb ideig szeretné őrizni a bináris naplókat, konfigurálhatja a paramétert binlog_expire_logs_seconds . Ha binlog_expire_logs_seconds az alapértelmezett értékre 0van állítva, a rendszer azonnal törli a bináris naplót, amint felszabadítja a leírót. Ha az érték binlog_expire_logs_seconds nagyobb, akkor 0a bináris napló a konfigurált másodpercek száma után törlődik.

A rugalmas Azure Database for MySQL-kiszolgáló belsőleg kezeli a felügyelt funkciókat, például a bináris fájlok biztonsági mentését és olvasását. Amikor replikálja az adatokat az Azure Database for MySQL rugalmas kiszolgálóról, ezt a paramétert az elsődleges helyen kell beállítani, hogy elkerülje a bináris naplók törlését, mielőtt a replika beolvassa az elsődleges módosításokat. Ha magasabb értékre állítja be binlog_expire_logs_seconds , a bináris naplók nem törlődnek elég hamar. Ez a késés a tárterület számlázásának növekedéséhez vezethet.

Korlátozások

A gyorsított naplók funkció engedélyezése után a binlog_expire_logs_seconds kiszolgálóparaméter teljes mértékben figyelmen kívül lesz hagyva, és a konfigurált értékeknek már nincs hatása. Ha azonban a gyorsított naplók funkció le van tiltva, a kiszolgáló ismét betartja a bináris naplók megőrzéséhez használt binlog_expire_logs_seconds konfigurált értékét. Ez a replikakiszolgálókra is vonatkozik.

eseményütemező

A rugalmas Azure Database for MySQL-kiszolgálón a kiszolgálóparaméter kezeli az event_scheduler események létrehozását, ütemezését és futtatását. Ez azt jelzi, hogy a paraméter egy speciális MySQL-eseményütemező-szál által ütemezés szerint futtatott feladatokat kezel. event_scheduler A paraméter beállításakor ONaz Eseményütemező szál démonfolyamatként jelenik meg a kimenetbenSHOW PROCESSLIST.

Az 5.7-es verziójú MySQL-kiszolgálók esetében a kiszolgálóparaméter event_scheduler automatikusan ki van kapcsolva a biztonsági mentés indításakor, és a kiszolgálóparaméter event_scheduler "BE" állapotba kerül a biztonsági mentés sikeres befejezése után. A Rugalmas Azure Database for MySQL-kiszolgálóHoz készült MySQL 8.0-s verziójában a event_scheduler a biztonsági mentések során nem érintik. A zökkenőmentesebb működés érdekében ajánlott a MySQL 5.7-kiszolgálókat a 8.0-s verzióra frissíteni egy főverziófrissítéssel.

Eseményeket az alábbi SQL-szintaxissal hozhat létre és ütemezhet:

CREATE EVENT <event name>
ON SCHEDULE EVERY _ MINUTE / HOUR / DAY
STARTS TIMESTAMP / CURRENT_TIMESTAMP
ENDS TIMESTAMP / CURRENT_TIMESTAMP + INTERVAL 1 MINUTE / HOUR / DAY
COMMENT '<comment>'
DO
<your statement>;

Az esemény létrehozásával kapcsolatos további információkért tekintse meg az eseményütemező következő dokumentációját a MySQL referencia-kézikönyvében:

A event_scheduler kiszolgálóparaméter konfigurálása

Az alábbi forgatókönyv a paraméter rugalmas Azure Database for MySQL-kiszolgálón való használatának event_scheduler egyik módját mutatja be.

A forgatókönyv bemutatásához tekintse meg egy egyszerű táblázat alábbi példáját:

mysql> describe tab1;
+-----------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
| +-----------+-------------+------+-----+---------+----------------+ |
| id | int(11) | NO | PRI | NULL | auto_increment |
| CreatedAt | timestamp | YES | | NULL | |
| CreatedBy | varchar(16) | YES | | NULL | |
| +-----------+-------------+------+-----+---------+----------------+ |
| 3 rows in set (0.23 sec) |
| ``` |
| To configure the `event_scheduler` server parameter in Azure Database for MySQL - Flexible Server, perform the following steps: |

1. In the Azure portal, go to your Azure Database for MySQL - Flexible Server instance. Under **Settings**, select **Server parameters**.
1. On the **Server parameters** pane, search for `event_scheduler`. In the **VALUE** dropdown list, select **ON**, and then select **Save**.

    > [!NOTE]
    > Deployment of the dynamic configuration change to the server parameter doesn't require a restart.

1. To create an event, connect to the Azure Database for MySQL - Flexible Server instance and run the following SQL command:
    ```sql

    CREATE EVENT test_event_01
    ON SCHEDULE EVERY 1 MINUTE
    STARTS CURRENT_TIMESTAMP
    ENDS CURRENT_TIMESTAMP + INTERVAL 1 HOUR
    COMMENT 'Inserting record into the table tab1 with current timestamp'
    DO
    INSERT INTO tab1(id,createdAt,createdBy)
    VALUES('',NOW(),CURRENT_USER());

    ```
1. To view the Event Scheduler details, run the following SQL statement:
    ```sql

    SHOW EVENTS;

    ```
    The following output appears:
    ```sql

    mysql> show events;
    +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+
    | Db | Name | Definer | Time zone | Type | Execute at | Interval value | Interval field | Starts | Ends | Status | Originator | character_set_client | collation_connection | Database Collation |
    | +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+ |
    | db1 | test_event_01 | azureuser@% | SYSTEM | RECURRING | NULL | 1 | MINUTE | 2023-04-05 14:47:04 | 2023-04-05 15:47:04 | ENABLED | 3221153808 | latin1 | latin1_swedish_ci | latin1_swedish_ci |
    | +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+ |
    | 1 row in set (0.23 sec) |
    | ``` |

1. After a few minutes, query the rows from the table to begin viewing the rows inserted every minute according to the `event_scheduler` parameter that you configured:

    ```azurecli
    mysql> select * from tab1;
    +----+---------------------+-------------+
    | id | CreatedAt | CreatedBy |
    | +----+---------------------+-------------+ |
    | 1 | 2023-04-05 14:47:04 | azureuser@% |
    | 2 | 2023-04-05 14:48:04 | azureuser@% |
    | 3 | 2023-04-05 14:49:04 | azureuser@% |
    | 4 | 2023-04-05 14:50:04 | azureuser@% |
    | +----+---------------------+-------------+ |
    | 4 rows in set (0.23 sec) |
    | ``` |
| 1. After an hour, run a `select` statement on the table to view the complete result of the values inserted into table every minute for an hour (as `event_scheduler` is configured in this case): |
    ```azurecli

    mysql> select * from tab1;
    +----+---------------------+-------------+
    | id | CreatedAt | CreatedBy |
    | +----+---------------------+-------------+ |
    | 1 | 2023-04-05 14:47:04 | azureuser@% |
    | 2 | 2023-04-05 14:48:04 | azureuser@% |
    | 3 | 2023-04-05 14:49:04 | azureuser@% |
    | 4 | 2023-04-05 14:50:04 | azureuser@% |
    | 5 | 2023-04-05 14:51:04 | azureuser@% |
    | 6 | 2023-04-05 14:52:04 | azureuser@% |
    | ..< 50 lines trimmed to compact output >.. |
    | 56 | 2023-04-05 15:42:04 | azureuser@% |
    | 57 | 2023-04-05 15:43:04 | azureuser@% |
    | 58 | 2023-04-05 15:44:04 | azureuser@% |
    | 59 | 2023-04-05 15:45:04 | azureuser@% |
    | 60 | 2023-04-05 15:46:04 | azureuser@% |
    | 61 | 2023-04-05 15:47:04 | azureuser@% |
    | +----+---------------------+-------------+ |
    | 61 rows in set (0.23 sec) |
    | ``` |

#### Other scenarios

You can set up an event based on the requirements of your specific scenario. A few examples of scheduling SQL statements to run at various time intervals follow.

To run a SQL statement now and repeat one time per day with no end:

```sql
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS (TIMESTAMP(CURRENT_DATE) + INTERVAL 1 DAY + INTERVAL 1 HOUR)
COMMENT 'Comment'
DO
<your statement>;

Sql-utasítás futtatása óránként, vége nélkül:

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
DO
<your statement>;

SQL-utasítás futtatása minden nap vége nélkül:

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS str_to_date( date_format(now(), '%Y%m%d 0200'), '%Y%m%d %H%i' ) + INTERVAL 1 DAY
COMMENT 'Comment'
DO
<your statement>;

Korlátozások

Magas rendelkezésre állású kiszolgálók esetén feladatátvétel esetén lehetséges, hogy a event_scheduler kiszolgáló paramétere a következőre OFFvan állítva: . Ha ez történik, a feladatátvétel befejezésekor konfigurálja a paramétert úgy, hogy az értéket a következőre ONállítsa.

innodb_ft_user_stopword_table

innodb_ft_user_stopword_table Egy kiszolgálóparaméter a MySQL-ben, amely megadja annak a táblának a nevét, amely egyéni stopwords-eket tartalmaz az InnoDB Teljes szöveges kereséshez. A táblázatnak ugyanabban az adatbázisban kell lennie, mint a teljes szöveges indexelt táblázatnak, és az első oszlopának típusnak VARCHARkell lennie. A rugalmas Azure Database for MySQL-kiszolgálón az alapértelmezett beállítás sql_generate_invisible_primary_key=ON azt eredményezi, hogy az összes olyan tábla, amely nem rendelkezik explicit elsődleges kulccsal, automatikusan tartalmaz egy láthatatlan elsődleges kulcsot. Ez a viselkedés ütközik a következő követelményekkel innodb_ft_user_stopword_table: a láthatatlan elsődleges kulcs lesz a tábla első oszlopa, ami megakadályozza, hogy a teljes szöveges keresés során a kívánt módon működjön. A probléma megoldásához ugyanabban a munkamenetben kell beállítania sql_generate_invisible_primary_key=OFF az egyéni stopword tábla létrehozása előtt. Példa:

SET sql_generate_invisible_primary_key = OFF;
CREATE TABLE my_stopword_table (
    stopword VARCHAR(50) NOT NULL
);
INSERT INTO my_stopword_table (stopword) VALUES ('and'), ('or'), ('the');

Ez biztosítja, hogy a stopword tábla megfeleljen a MySQL követelményeinek, és lehetővé teszi az egyéni stopwords megfelelő működését.

Nem módosítható kiszolgálóparaméterek

Az Azure Portal Kiszolgálóparaméterek paneljén a módosítható és a nem módosítható kiszolgálóparaméterek is láthatók. A nem módosítható kiszolgálóparaméterek nem érhetők el. A munkamenet szintjén init_connect nem módosítható kiszolgálóparamétert az Azure Portalon vagy az Azure CLI-ben konfigurálhatja.

Azure mysql rendszerváltozók

Azure szerver neve

A azure_server_name változó megadja a rugalmas Azure Database for MySQL-kiszolgálópéldány pontos kiszolgálónevét. Ez a változó akkor hasznos, ha az alkalmazásoknak vagy szkripteknek programozott módon le kell kérniük a kiszolgáló gazdanevét, amelyhez csatlakoznak, külső konfigurációk használata nélkül, és a következő parancs mySQL-en belüli futtatásával kérhetők le.

mysql> SHOW GLOBAL VARIABLES LIKE 'azure_server_name';
+-------------------+---------+
| Variable_name     | Value   |
+-------------------+---------+
| azure_server_name | myflex  |
+-------------------+---------+

Megjegyzés: A azure_server_name rendszer következetesen visszaadja a szolgáltatáshoz való csatlakozáshoz használt eredeti kiszolgálónevet (például myflex) a HA-kompatibilis és a HA-letiltott kiszolgálók esetében is.

logikai_szerver_név

A logical_server_name változó annak a példánynak a gazdagépnevét jelöli, amelyen az Azure Database for MySQL – Rugalmas kiszolgáló fut. Ez a változó hasznos annak a gazdagépnek a azonosításához, ahol a szolgáltatás jelenleg fut, segítve a hibaelhárítást és a feladatátvételi monitorozást. Ezt a változót az alábbi parancs MySQL-ben való végrehajtásával lehet lekérni.

mysql> SHOW GLOBAL VARIABLES LIKE 'logical_server_name';
+---------------------+--------------+
| Variable_name       | Value        |
+---------------------+--------------+
| logical_server_name | myflex	     |
+---------------------+--------------+

Megjegyzés: HA-kompatibilis kiszolgáló esetén a változó az logical_server_name elsődleges kiszolgálóként működő példány állomásnevét tükrözi. Olyan kiszolgáló esetén, ahol a HA le van tiltva, a logical_server_name változó értéke megegyezik a azure_server_name változóéval, mivel csak egyetlen példány van.

Kapcsolódó tartalom

  • Last updated on