Parametry serveru na flexibilním serveru Azure Database for MySQL
PLATÍ PRO:
Flexibilní server Azure Database for MySQL
Tento článek obsahuje důležité informace a pokyny pro konfiguraci parametrů serveru na flexibilním serveru Azure Database for MySQL.
Poznámka:
Tento článek obsahuje odkazy na termín slave (podřízený) , což je termín, který už Microsoft nepoužívá. Když se termín odebere ze softwaru, odebereme ho z tohoto článku.
Co jsou proměnné serveru?
Modul MySQL poskytuje mnoho různých proměnných a parametrů serveru, které lze použít ke konfiguraci a ladění chování modulu. Některé parametry je možné nastavit dynamicky během běhu, zatímco jiné jsou "statické", což vyžaduje restartování serveru, aby bylo možné použít.
Flexibilní server Azure Database for MySQL zpřístupňuje možnost změnit hodnotu různých parametrů serveru MySQL pomocí webu Azure Portal a Azure CLI tak, aby odpovídaly potřebám vaší úlohy.
Konfigurovatelné parametry serveru
Konfiguraci flexibilního serveru Azure Database for MySQL můžete spravovat pomocí parametrů serveru. Parametry serveru se při vytváření serveru konfigurují s výchozí a doporučenou hodnotou. V okně parametru serveru na webu Azure Portal se zobrazují parametry upravitelného i nemodifikovatelného serveru. Nemodifikovatelné parametry serveru jsou neaktivní.
Seznam podporovaných parametrů serveru neustále roste. Pomocí karty parametry serveru na webu Azure Portal zobrazte úplný seznam a nakonfigurujte hodnoty parametrů serveru.
Další informace o limitech několika běžně aktualizovaných parametrů serveru najdete v následujících částech. Limity se určují podle úrovně výpočetních prostředků a velikosti (virtuálních jader) serveru.
Poznámka:
- Pokud upravíte parametr statického serveru pomocí portálu, je potřeba restartovat server, aby se změny projevily. Pokud používáte automatizační skripty (pomocí nástrojů, jako jsou šablony ARM, Terraform, Azure CLI atd.), měl by mít váš skript zřízení pro restartování služby, aby se nastavení projevilo, i když konfiguraci měníte jako součást prostředí pro vytváření.
- Pokud chcete upravit parametr serveru, který není upravitelný pro vaše prostředí, otevřete položku UserVoice nebo hlasujte, pokud už existuje zpětná vazba, která nám může pomoct určit prioritu.
lower_case_table_names
Pro MySQL verze 5.7 je výchozí hodnota 1 na flexibilním serveru Azure Database for MySQL. Je důležité si uvědomit, že i když je možné změnit podporovanou hodnotu na 2, návrat z 2 zpět na 1 není povolený. Požádejte náš tým podpory o pomoc při změně výchozí hodnoty. Pro MySQL verze 8.0+ lower_case_table_names lze nakonfigurovat pouze při inicializaci serveru. Další informace. Změna nastavení lower_case_table_names po inicializaci serveru je zakázána. Pro MySQL verze 8.0 je výchozí hodnota 1 na flexibilním serveru Azure Database for MySQL. Podporovaná hodnota pro MySQL verze 8.0 je 1 a 2 na flexibilním serveru Azure Database for MySQL. Požádejte náš tým podpory o pomoc při změně výchozí hodnoty během vytváření serveru.
innodb_tmpdir
Parametr innodb_tmpdir na flexibilním serveru Azure Database for MySQL slouží k definování adresáře pro dočasné řazení souborů vytvořených během online operací ALTER TABLE, které se znovu sestaví. Výchozí hodnota innodb_tmpdir je /mnt/temp. Toto umístění odpovídá dočasnému úložišti SSD, které je dostupné v GiB s velikostí výpočetních prostředků jednotlivých serverů. Toto umístění je ideální pro operace, které nevyžadují velké množství místa.
Pokud potřebujete více místa, můžete nastavit innodb_tmpdir na /app/work/tmpdirhodnotu . To využívá vaše úložiště, kapacitu dostupnou na flexibilním serveru Azure Database for MySQL. To může být užitečné pro větší operace, které vyžadují větší dočasné úložiště.
Je důležité si uvědomit, že využití /app/work/tmpdir vede k nižšímu výkonu oproti výchozímu dočasnému úložišti (SSD)./mnt/temp Volba by měla být založena na konkrétních požadavcích operací.
Informace zadané pro parametry innodb_temp_tablespaces_dir, tmpdir a slave_load_tmpdir, kde je výchozí hodnota /mnt/temp společná, a alternativní adresář /app/work/tmpdir je k dispozici pro konfiguraci zvýšeného dočasného úložiště s kompromisem v výkonu na základě specifických provozních požadavků. innodb_tmpdir
log_bin_trust_function_creators
Na flexibilním serveru Azure Database for MySQL jsou binární protokoly vždy povolené (to znamená log_bin , že je nastavené na ZAPNUTO). log_bin_trust_function_creators je ve výchozím nastavení na flexibilních serverech nastavená na zapnuto.
Binární formát protokolování je vždy ŘÁDEK a všechna připojení k serveru VŽDY používají binární protokolování založené na řádcích. U binárního protokolování založeného na řádcích neexistují problémy se zabezpečením a binární protokolování nemůže přerušit, takže můžete bezpečně povolit log_bin_trust_function_creators zůstat zapnuto.
Pokud je možnost [log_bin_trust_function_creators] vypnutá, pokud se pokusíte vytvořit triggery, mohou se zobrazit chyby podobné tomu, že nemáte oprávnění SUPER a je povolené binární protokolování (můžete chtít použít méně bezpečnou log_bin_trust_function_creators proměnnou).
innodb_buffer_pool_size
Další informace o tomto parametru najdete v dokumentaci k MySQL.
| Cenová úroveň | Virtuální jádra | Velikost paměti (GiB) | Výchozí hodnota (bajty) | Minimální hodnota (bajty) | Maximální hodnota (bajty) |
|---|---|---|---|---|---|
| Nárazové (B1s) | 1 | 1 | 134217728 | 33554432 | 134217728 |
| Nárazové (B1ms) | 1 | 2 | 536870912 | 134217728 | 536870912 |
| Se zvládáním nárazových špiček | 2 | 4 | 2147483648 | 134217728 | 2147483648 |
| Pro obecné účely | 2 | 8 | 5368709120 | 134217728 | 5368709120 |
| Pro obecné účely | 4 | 16 | 12884901888 | 134217728 | 12884901888 |
| Pro obecné účely | 8 | 32 | 25769803776 | 134217728 | 25769803776 |
| Pro obecné účely | 16 | 64 | 51539607552 | 134217728 | 51539607552 |
| Pro obecné účely | 32 | 128 | 103079215104 | 134217728 | 103079215104 |
| Pro obecné účely | 48 | 192 | 154618822656 | 134217728 | 154618822656 |
| Pro obecné účely | 64 | 256 | 206158430208 | 134217728 | 206158430208 |
| Pro důležité obchodní informace | 2 | 16 | 12884901888 | 134217728 | 12884901888 |
| Pro důležité obchodní informace | 4 | 32 | 25769803776 | 134217728 | 25769803776 |
| Pro důležité obchodní informace | 8 | 64 | 51539607552 | 134217728 | 51539607552 |
| Pro důležité obchodní informace | 16 | 128 | 103079215104 | 134217728 | 103079215104 |
| Pro důležité obchodní informace | 32 | 256 | 206158430208 | 134217728 | 206158430208 |
| Pro důležité obchodní informace | 48 | 384 | 309237645312 | 134217728 | 309237645312 |
| Pro důležité obchodní informace | 64 | 504 | 405874409472 | 134217728 | 405874409472 |
innodb_file_per_table
MySQL ukládá tabulku InnoDB do různých tabulkových prostorů na základě konfigurace, kterou jste zadali při vytváření tabulky. Systémový tabulkový prostor je oblast úložiště pro slovník dat InnoDB. Tablespace pro jednotlivé tabulky obsahuje data a indexy pro jednu tabulku InnoDB a je uložena v systému souborů ve vlastním datovém souboru. Toto chování je řízeno parametrem innodb_file_per_table serveru. Nastavení innodb_file_per_table , které OFF způsobí, že InnoDB vytvoří tabulky v systémovém tabulkovém prostoru. V opačném případě InnoDB vytvoří tabulky v tabulkových prostorech pro jednotlivé tabulky.
Flexibilní server Azure Database for MySQL podporuje v jednom datovém souboru maximálně 4 TB. Pokud je databáze větší než 4 TB, vytvořte tabulku v tabulkovém prostoru innodb_file_per_table. Pokud má velikost přesahující 4 TB jen jedna tabulka, použijte tabulku oddílů.
innodb_log_file_size
innodb_log_file_size je velikost v bajtech každého souboru protokolu ve skupině protokolů. Kombinovaná velikost souborů protokolu (innodb_log_file_size innodb_log_files_in_group * ) nemůže překročit maximální hodnotu, která je o něco menší než 512 GB). Větší velikost souboru protokolu je lepší pro výkon, ale má nevýhodu, že doba obnovení po chybovém ukončení je vysoká. Potřebujete vyrovnávat dobu obnovení ve výjimečných událostech zotavení po havárii a maximalizovat propustnost během operací ve špičce. To může také způsobit delší dobu restartování. Pro libovolný z těchto hodnot můžete nakonfigurovat innodb_log_size – 256 MB, 512 MB, 1 GB nebo 2 GB pro flexibilní server Azure Database for MySQL. Tento parametr je statický a vyžaduje restartování.
Poznámka:
Pokud jste změnili parametr innodb_log_file_size z výchozího nastavení, zkontrolujte, jestli hodnota "zobrazit globální stav, jako je innodb_buffer_pool_pages_dirty", zůstane na 0 po dobu 30 sekund, abyste se vyhnuli zpoždění restartování.
max_connections
Hodnota max_connection je určena velikostí paměti serveru.
| Cenová úroveň | Virtuální jádra | Velikost paměti (GiB) | Výchozí hodnota | Minimální hodnota | Maximální hodnota |
|---|---|---|---|---|---|
| Nárazové (B1s) | 1 | 1 | 85 | 10 | 171 |
| Nárazové (B1ms) | 1 | 2 | 171 | 10 | 341 |
| Se zvládáním nárazových špiček | 2 | 4 | 341 | 10 | 683 |
| Pro obecné účely | 2 | 8 | 683 | 10 | 1365 |
| Pro obecné účely | 4 | 16 | 1365 | 10 | 2731 |
| Pro obecné účely | 8 | 32 | 2731 | 10 | 5461 |
| Pro obecné účely | 16 | 64 | 5461 | 10 | 10923 |
| Pro obecné účely | 32 | 128 | 10923 | 10 | 21845 |
| Pro obecné účely | 48 | 192 | 16384 | 10 | 32768 |
| Pro obecné účely | 64 | 256 | 21845 | 10 | 43691 |
| Pro důležité obchodní informace | 2 | 16 | 1365 | 10 | 2731 |
| Pro důležité obchodní informace | 4 | 32 | 2731 | 10 | 5461 |
| Pro důležité obchodní informace | 8 | 64 | 5461 | 10 | 10923 |
| Pro důležité obchodní informace | 16 | 128 | 10923 | 10 | 21845 |
| Pro důležité obchodní informace | 32 | 256 | 21845 | 10 | 43691 |
| Pro důležité obchodní informace | 48 | 384 | 32768 | 10 | 65536 |
| Pro důležité obchodní informace | 64 | 504 | 43008 | 10 | 86016 |
Pokud připojení překročí limit, může se zobrazit následující chyba:
CHYBA 1040 (08004): Příliš mnoho připojení
Důležité
Pro zajištění co nejlepších zkušeností doporučujeme použít nástroj pro sdružování připojení, jako je ProxySQL, k efektivní správě připojení.
Vytváření nových klientských připojení k MySQL trvá dlouho a po vytvoření tato připojení zabírají databázové prostředky, i když jsou nečinná. Většina aplikací vyžaduje mnoho krátkodobých připojení, která tuto situaci sloučí. Výsledkem je méně prostředků dostupných pro vaši skutečnou úlohu, což vede ke snížení výkonu. Fond připojení, který snižuje nečinná připojení a opětovně používá existující připojení, pomáhá tomu zabránit. Informace o nastavení ProxySQL najdete v našem blogovém příspěvku.
Poznámka:
ProxySQL je opensourcový komunitní nástroj. Společnost Microsoft ji podporuje na základě maximálního úsilí. Pokud chcete získat podporu produkčního prostředí s autoritativními pokyny, můžete vyhodnotit a kontaktovat podporu produktů ProxySQL.
innodb_strict_mode
Pokud se zobrazí chyba podobná "Velikost řádku je příliš velká (> 8126)", možná budete chtít vypnout parametr innodb_strict_mode. Parametr serveru innodb_strict_mode nejde globálně změnit na úrovni serveru, protože pokud je velikost dat řádku větší než 8 tisíc, data se zkrátí bez chyby, což může vést k potenciální ztrátě dat. Doporučujeme upravit schéma tak, aby odpovídalo limitu velikosti stránky.
Tento parametr lze nastavit na úrovni relace pomocí init_connect. Pokud chcete nastavit innodb_strict_mode na úrovni relace, přečtěte si informace o nastavení parametru, který tu není uvedený.
Poznámka:
Pokud máte server repliky pro čtení, nastavení innodb_strict_mode na vypnuto na úrovni relace na zdrojovém serveru přeruší replikaci. Pokud máte repliky pro čtení, doporučujeme ponechat parametr nastavený na ZAPNUTO.
time_zone
Po počátečním nasazení instance flexibilního serveru Azure Database for MySQL obsahuje systémové tabulky pro informace o časovém pásmu, ale tyto tabulky se nezaplní. Tabulky časových pásem je možné naplnit voláním mysql.az_load_timezone uložené procedury z nástroje, jako je příkazový řádek MySQL nebo MySQL Workbench. Informace o volání uložené procedury a nastavení globálních časových pásem nebo časových pásem na úrovni relace najdete na webu Azure Portal nebo v článcích Azure CLI .
binlog_expire_logs_seconds
Na flexibilním serveru Azure Database for MySQL tento parametr určuje počet sekund, po které služba čeká před vymazáním souboru binárního protokolu.
Binární protokol obsahuje "události", které popisují změny databáze, jako jsou operace vytváření tabulek nebo změny dat tabulky. Obsahuje také události pro příkazy, které mohly potenciálně provést změny. Binární protokol se používá hlavně pro dva účely, replikaci a operace obnovení dat. Binární protokoly se obvykle vymažou, jakmile popisovač není dostupný ze služby, zálohování nebo sady replik. Pokud existuje více replik, binární protokoly čekají, až nejpomalejší replika přečte změny, než se vyprázdní. Pokud chcete binární protokoly uchovávat delší dobu, můžete nakonfigurovat parametr binlog_expire_logs_seconds. Pokud je binlog_expire_logs_seconds nastavená na 0, což je výchozí hodnota, vymaže se jakmile popisovač binárního protokolu uvolní. Pokud binlog_expire_logs_seconds > 0, pak by čekal na sekundy nakonfigurované před vyprázdněním. U flexibilního serveru Azure Database for MySQL se spravované funkce, jako je zálohování a vymazání repliky pro čtení binárních souborů, zpracovávají interně. Když replikujete data z flexibilního serveru Azure Database for MySQL, je potřeba tento parametr nastavit v primárním umístění, aby se zabránilo vymazání binárních protokolů před tím, než replika načte změny z primárního serveru. Pokud nastavíte binlog_expire_logs_seconds na vyšší hodnotu, binární protokoly se brzy nevyprázdní a můžou vést ke zvýšení fakturace úložiště.
event_scheduler
Na flexibilním serveru event_schedule Azure Database for MySQL spravuje parametr serveru vytváření, plánování a spouštění událostí, tj. úlohy, které se spouští podle plánu, a spouští se speciálním vláknem plánovače událostí. event_scheduler Pokud je parametr nastaven na HODNOTU ON, je vlákno plánovače událostí uvedeno jako proces démon ve výstupu SHOW PROCESSLIST. Události můžete vytvářet a plánovat pomocí následující syntaxe SQL:
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>;
Poznámka:
Další informace o vytvoření události najdete v dokumentaci k Plánovači událostí MySQL zde:
Konfigurace parametru serveru event_scheduler
Následující scénář ukazuje jeden ze způsobů použití parametru na flexibilním event_scheduler serveru Azure Database for MySQL. Pro předvedení scénáře vezměte v úvahu následující příklad– jednoduchou tabulku:
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)
Pokud chcete nakonfigurovat parametr serveru na flexibilním event_scheduler serveru Azure Database for MySQL, proveďte následující kroky:
Na webu Azure Portal přejděte do instance flexibilního serveru Azure Database for MySQL a v části Nastavení vyberte Parametry serveru.
V okně Parametry serveru vyhledejte
event_schedulerv rozevíracím seznamu HODNOTA možnost ZAPNUTO a pak vyberte Uložit.Poznámka:
Změna konfigurace parametru dynamického serveru se nasadí bez restartování.
Pak vytvořte událost, připojte se k instanci flexibilního serveru Azure Database for MySQL a spusťte následující příkaz 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());Pokud chcete zobrazit podrobnosti plánovače událostí, spusťte následující příkaz SQL:
SHOW EVENTS;Objeví se následující výstup:
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)Po několika minutách zadejte dotaz na řádky z tabulky a začněte zobrazovat řádky vložené každou minutu podle parametru
event_scheduler, který jste nakonfigurovali: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)Po hodině spusťte příkaz Select v tabulce, abyste zobrazili úplný výsledek hodnot vložených do tabulky každou minutu po hodinu, protože
event_schedulerje v našem případě nakonfigurovaný.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)
Další scénáře
Událost můžete nastavit na základě požadavků konkrétního scénáře. Následuje několik podobných příkladů plánování příkazů SQL tak, aby běžely v různých časových intervalech.
Teď spusťte příkaz SQL a opakujte jeden čas za den bez konce.
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS (TIMESTAMP(CURRENT_DATE) + INTERVAL 1 DAY + INTERVAL 1 HOUR)
COMMENT 'Comment'
DO
<your statement>;
Spuštění příkazu SQL každou hodinu bez konce
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
DO
<your statement>;
Spuštění příkazu SQL každý den bez konce
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>;
Omezení
U serverů s nakonfigurovanou vysokou dostupností je možné, že event_scheduler když dojde k převzetí služeb při selhání, parametr serveru bude nastaven na HODNOTU VYPNUTO. Pokud k tomu dojde, po dokončení převzetí služeb při selhání nakonfigurujte parametr tak, aby nastavil hodnotu ON.< a1/>.
Neupravitelné parametry serveru
V okně parametru serveru na webu Azure Portal se zobrazují parametry upravitelného i neupravitelného serveru. Nemodifikovatelné parametry serveru jsou neaktivní. Pokud chcete nakonfigurovat parametr nemodifikovatelného serveru na úrovni relace, projděte si web Azure Portal nebo článek Azure CLI , kde najdete informace o nastavení parametru na úrovni připojení pomocí init_connect.