Sdílet prostřednictvím

Parametry serveru na flexibilním serveru Azure Database for MySQL

  • Článek

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, který už Microsoft nepoužívá. Když se termín odebere ze softwaru, odebereme ho z tohoto článku.

Co jsou parametry serveru?

Modul MySQL poskytuje mnoho parametrů serveru (označovaných také jako proměnné), které můžete použít ke konfiguraci a ladění chování modulu. Některé parametry je možné během běhu nastavit dynamicky. Ostatní jsou statické a po nastavení vyžadují restartování serveru.

Na flexibilním serveru Azure Database for MySQL můžete změnit hodnotu různých parametrů serveru MySQL pomocí parametrů serveru Konfigurace ve službě Azure Database for MySQL – Flexibilní server pomocí webu Azure Portal a konfigurace parametrů serveru ve službě Azure Database for MySQL pomocí 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ími a doporučenými hodnotami. Podokno Parametry serveru na webu Azure Portal zobrazuje upravitelné i neupravitelné parametry. Parametry serveru, které nelze upravit, nejsou k dispozici.

Seznam podporovaných parametrů serveru neustále roste. Azure Portal můžete použít k pravidelnému zobrazení úplného seznamu parametrů serveru a konfiguraci hodnot.

Pokud pomocí portálu upravíte parametr statického serveru, je potřeba restartovat server, aby se změny projevily. Pokud používáte automatizační skripty (prostřednictvím nástrojů, jako jsou šablony Azure Resource Manageru, Terraform nebo Azure CLI), měl by mít váš skript zřízení pro restartování služby, aby se nastavení projevilo, i když konfiguraci měníte v rámci prostředí pro vytváření.

Pokud chcete upravit parametr serveru, který není možné upravit pro vaše prostředí, zveřet nápad prostřednictvím zpětné vazby komunity nebo hlasovat, pokud už existuje zpětná vazba (což nám může pomoct určit prioritu).

Následující části popisují limity běžně aktualizovaných parametrů serveru. Úroveň výpočetních prostředků a velikost (virtuální jádra) serveru určují limity.

lower_case_table_names

Pro MySQL verze 5.7 je 1 výchozí hodnota na flexibilním lower_case_table_names serveru Azure Database for MySQL. I když je možné změnit podporovanou hodnotu na 2, návrat zpět 2 zpět 1 není povolený. Pokud potřebujete pomoc se změnou výchozí hodnoty, vytvořte lístek podpory.

Pro MySQL verze 8.0 nebo novější můžete nakonfigurovat lower_case_table_names pouze v případě, že inicializujete server. Další informace. lower_case_table_names Změna nastavení po inicializaci serveru je zakázána.

Podporované hodnoty pro MySQL verze 8.0 jsou a 2 jsou 1 na flexibilním serveru Azure Database for MySQL. Výchozí hodnota je 1. Pokud potřebujete pomoc se změnou výchozí hodnoty při vytváření serveru, vytvořte lístek podpory.

innodb_tmpdir

Pomocí parametru innodb_tmpdir na flexibilním serveru Azure Database for MySQL definujete adresář pro dočasné řazení souborů vytvořených během online ALTER TABLE operací, které znovu sestaví.

Výchozí hodnota atributu innodb_tmpdir je /mnt/temp. Toto umístění odpovídá dočasnému úložišti (SSD) a je dostupné v gibibajtech (GiB) s každou velikostí výpočetních prostředků serveru. 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 . Toto nastavení využívá dostupnou kapacitu úložiště na flexibilním serveru Azure Database for MySQL. Toto nastavení může být užitečné pro větší operace, které vyžadují větší dočasné úložiště.

Mějte na paměti, že použití /app/work/tmpdir vede k nižšímu výkonu v porovnání s výchozí hodnotou dočasného úložiště (SSD). /mnt/temp Na základě konkrétních požadavků operací vyberte.

Uvedené informace innodb_tmpdir se vztahují na parametry innodb_temp_tablespaces_dir, tmpdir a slave_load_tmpdir kde:

  • Výchozí hodnota /mnt/temp je společná.
  • 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ě konkrétních provozních požadavků.

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 jsou nastavené na ON). Parametr log_bin_trust_function_creators je ve výchozím nastavení nastavený ON na flexibilních serverech.

Binární formát protokolování je vždy ROWa 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 jako ON.

Pokud log_bin_trust_function_creators je nastavená možnost OFF a pokusíte se vytvořit triggery, můžou se zobrazit chyby podobné: 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

Informace o parametru innodb_buffer_pool_size najdete v dokumentaci k MySQL.

Velikost fyzické paměti v následující tabulce představuje dostupnou paměť s náhodným přístupem (RAM) v gigabajtech (GB) na flexibilním serveru Azure Database for MySQL.

Cenová úroveň virtuálních jader Velikost fyzické paměti (GB) Výchozí hodnota (bajty) Minimální hodnota (bajty) Maximální hodnota (bajty)
Nárazové (B1s) 1 1 134217728 33554432 268435456
Nárazové (B1ms) 1 2 536870912 134217728 1073741824
Nárazové (B2s) 2 4 2147483648 134217728 2147483648
Nárazové (B2ms) 2 8 4294967296 134217728 5368709120
Se zvládáním nárazových špiček 4 16 12884901888 134217728 12884901888
Se zvládáním nárazových špiček 8 32 25769803776 134217728 25769803776
Se zvládáním nárazových špiček 12 48 51539607552 134217728 51539607552
Se zvládáním nárazových špiček 16 64 2147483648 134217728 2147483648
Se zvládáním nárazových špiček 20 80 64424509440 134217728 64424509440
Pro obecné účely 2 8 4294967296 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 20 160 128849018880 134217728 128849018880
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žená v systému souborů ve vlastním datovém souboru. Toto chování řídí parametr serveru innodb_file_per_table .

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 maximálně 8 terabajtů (TB) v jednom datovém souboru. Pokud je velikost databáze větší než 8 TB, měli byste tabulku vytvořit v tabulkovém innodb_file_per_table prostoru. Pokud máte jednu tabulku větší než 8 TB, měli byste použít tabulku oddílů.

innodb_log_file_size

Hodnota 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 nevýhodou je, že doba obnovení po chybovém ukončení je vysoká. Potřebujete vyvážit čas obnovení pro vzácnou událost chybového ukončení a maximalizaci propustnosti během operací ve špičce. Větší velikost souboru protokolu může také způsobit delší dobu restartování.

Pro flexibilní server Azure Database for MySQL můžete nakonfigurovat innodb_log_size 256 megabajtů (MB), 512 MB, 1 GB nebo 2 GB. Tento parametr je statický a vyžaduje restartování.

Poznámka:

Pokud jste změnili innodb_log_file_size parametr z výchozího nastavení, zkontrolujte, jestli hodnota show global status like 'innodb_buffer_pool_pages_dirty' zůstane 0 po dobu 30 sekund, abyste se vyhnuli zpoždění restartování.

max_connections

Velikost paměti serveru určuje hodnotu max_connections. Velikost fyzické paměti v následující tabulce představuje dostupnou paměť RAM v gigabajtech na flexibilním serveru Azure Database for MySQL.

Cenová úroveň virtuálních jader Velikost fyzické paměti (GB) Default value Min. hodnota Max. hodnota
Nárazové (B1s) 1 1 85 10 171
Nárazové (B1ms) 1 2 171 10 341
Nárazové (B2s) 2 4 341 10 683
Nárazové (B2ms) 2 4 683 10 1365
Se zvládáním nárazových špiček 4 16 1365 10 2731
Se zvládáním nárazových špiček 8 32 2731 10 5461
Se zvládáním nárazových špiček 12 48 4097 10 8193
Se zvládáním nárazových špiček 16 64 5461 10 10923
Se zvládáním nárazových špiček 20 80 6827 10 13653
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 20 160 13653 10 27306
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í.

Vytváření nových klientských připojení k MySQL nějakou dobu trvá. Po navázání těchto 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í, vám pomůže vyhnout se tomuto problému. Pro zajištění co nejlepšího prostředí doporučujeme použít nástroj pro sdružování připojení, jako je ProxySQL, k efektivní správě připojení. Další informace o nastavení ProxySQL najdete v tomto blogovém příspěvku.

Poznámka:

ProxySQL je opensourcový komunitní nástroj. Microsoft ho podporuje na základě nejlepšího úsilí. Pokud chcete získat podporu produkčního prostředí s autoritativními pokyny, obraťte se na podporu produktu ProxySQL.

innodb_strict_mode

Pokud se zobrazí chyba podobná "Příliš velká velikost řádku (> 8126)," možná budete chtít vypnout innodb_strict_mode parametr serveru. Tento parametr nejde globálně upravit na úrovni serveru, protože pokud je velikost dat řádků větší než 8 tisíc, data se zkrátí bez chyby. Toto zkrácení 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 můžete nastavit na úrovni relace pomocí .init_connect Další informace naleznete v tématu Nastavení neupravitelných parametrů serveru.

Poznámka:

Pokud máte server repliky pro čtení, nastavení innodb_strict_mode OFF na úrovni relace na zdrojovém serveru replikaci přeruší. Doporučujeme ponechat parametr nastavený na ON , pokud máte repliky pro čtení.

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 můžete naplnit voláním mysql.az_load_timezone uložené procedury z nástroje, jako je příkazový řádek MySQL nebo MySQL Workbench. Uloženou proceduru můžete také volat a nastavit globální časové pásmo nebo časové pásmo na úrovni relace pomocí webu Azure Portal nebo Azure CLI.

binlog_expire_logs_seconds

Na flexibilním serveru binlog_expire_logs_seconds Azure Database for MySQL určuje parametr počet sekund, po které služba čeká před odstraně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. Binární protokol obsahuje také události pro příkazy, které by mohly provádět změny. Binární protokol se používá hlavně pro dva účely: operace replikace a obnovení dat.

Binární protokoly se obvykle odstraní, jakmile je popisovač volný ze služby, zálohování nebo sady replik. Pokud existuje více replik, binární protokoly čekají, až nejpomalejší replika před odstraněním přečte změny.

Pokud chcete binární protokoly uchovávat delší dobu, můžete parametr nakonfigurovat binlog_expire_logs_seconds . Pokud binlog_expire_logs_seconds je nastavena na výchozí hodnotu 0, binární protokol se odstraní ihned po uvolnění popisovače. Pokud je hodnota binlog_expire_logs_seconds větší než 0, binární protokol se odstraní po nakonfigurovaného počtu sekund.

Flexibilní server Azure Database for MySQL zpracovává spravované funkce, jako je zálohování a odstraňování replik pro čtení binárních souborů 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 odstranění binárních protokolů, než replika načte změny v primárním serveru. Pokud nastavíte binlog_expire_logs_seconds vyšší hodnotu, binární protokoly se brzy neodstraní. Toto zpoždění může vést ke zvýšení fakturace úložiště.

event_scheduler

Na flexibilním event_scheduler serveru Azure Database for MySQL spravuje parametr serveru vytváření, plánování a spouštění událostí. To znamená, že parametr spravuje úlohy, které se spouští podle plánu pomocí speciálního vlákna Plánovače událostí MySQL. event_scheduler Pokud je parametr nastaven na ON, je vlákno plánovače událostí uvedeno jako proces démon ve výstupu .SHOW PROCESSLIST

U serverů MySQL verze 5.7 se parametr event_scheduler serveru po úspěšném dokončení zálohování automaticky vypne a parametr event_scheduler serveru se po úspěšném dokončení zálohování znovu zapne. Na flexibilním serveru MySQL verze 8.0 pro Flexibilní server Azure Database for MySQL zůstává event_scheduler během zálohování nedotčené. Pokud chcete zajistit plynulejší provoz, doporučujeme upgradovat servery MySQL 5.7 na verzi 8.0 pomocí upgradu hlavní verze.

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>;

Další informace o vytvoření události najdete v následující dokumentaci k plánovači událostí v referenční příručce MySQL:

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 zvažte následující příklad jednoduché tabulky:

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>;

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 vysokou dostupností nakonfigurovanou, když dojde k převzetí služeb při selhání, je možné, že event_scheduler je parametr serveru nastavený na OFFhodnotu . Pokud k tomu dojde, po dokončení převzetí služeb při selhání nakonfigurujte parametr tak, aby nastavil hodnotu na ON.

Neupravitelné parametry serveru

Podokno Parametry serveru na webu Azure Portal zobrazuje upravitelné i neupravitelné parametry serveru. Parametry serveru, které nelze upravit, nejsou k dispozici. Parametr nemodifikovatelného serveru můžete nakonfigurovat na úrovni relace pomocí init_connect webu Azure Portal nebo Azure CLI.

Související obsah