Serverparameters in Azure Database for MySQL - Flexibele server

Dit artikel bevat overwegingen en richtlijnen voor het configureren van serverparameters in Azure Database for MySQL - Flexible Server.

Wat zijn serverparameters?

De MySQL-engine biedt veel serverparameters (ook wel variabelen genoemd) die u kunt gebruiken om het gedrag van de engine te configureren en af te stemmen. Sommige parameters kunnen dynamisch worden ingesteld tijdens runtime. Andere zijn statisch en vereisen dat de server opnieuw wordt opgestart nadat u ze hebt ingesteld.

In Azure Database for MySQL - Flexible Server kunt u de waarde van verschillende MySQL-serverparameters wijzigen met behulp van de serverparameters configureren in Azure Database for MySQL - Flexible Server met behulp van Azure Portal en de serverparameters configureren in Azure Database for MySQL - Flexible Server met behulp van de Azure CLI om te voldoen aan de behoeften van uw workload.

Configureerbare serverparameters

U kunt de configuratie van een Flexibele Azure Database for MySQL-server beheren met behulp van serverparameters. De serverparameters worden geconfigureerd met de standaard- en aanbevolen waarden wanneer u de server maakt. In het deelvenster Serverparameters in Azure Portal worden zowel de wijzigbare als niet-aanpasbare parameters weergegeven. De niet-aanpasbare serverparameters zijn niet beschikbaar.

De lijst met ondersteunde serverparameters groeit voortdurend. U kunt Azure Portal gebruiken om periodiek de volledige lijst met serverparameters weer te geven en de waarden te configureren.

Als u een parameter voor een statische server wijzigt met behulp van de portal, moet u de server opnieuw opstarten om de wijzigingen van kracht te laten worden. Als u automatiseringsscripts gebruikt (via hulpprogramma's zoals Azure Resource Manager-sjablonen, Terraform of de Azure CLI), moet uw script een inrichting hebben om de service opnieuw te starten zodat de instellingen van kracht worden, zelfs als u de configuratie wijzigt als onderdeel van de aanmaakervaring.

Als u een niet-aanpasbare serverparameter voor uw omgeving wilt wijzigen, plaatst u een idee via feedback van de community of stemt u als de feedback al bestaat (wat ons kan helpen prioriteit te geven).

In de volgende secties worden de limieten van de vaak bijgewerkte serverparameters beschreven. De rekenlaag en de grootte (vCores) van de server bepalen de limieten.

lower_case_table_names

Voor MySQL versie 8.0+ kunt u alleen configureren lower_case_table_names wanneer u de server initialiseert. Meer informatie. Het wijzigen van de lower_case_table_names instelling nadat de server is geïnitialiseerd, is niet toegestaan. Ondersteunde waarden voor MySQL-versie 8.0 bevinden zich 1 en 2 in Azure Database for MySQL - Flexible Server. De standaardwaarde is 1.

U kunt deze instellingen configureren in de portal tijdens het maken van de server door de gewenste waarde op te geven onder Serverparameters op de pagina Aanvullende configuratie. Voor het maken van herstelbewerkingen of het maken van replicaservers wordt de parameter automatisch gekopieerd van de bronserver en kan deze niet worden gewijzigd.

Voor MySQL versie 5.7 is lower_case_table_names de standaardwaarde 1 in Azure Database for MySQL - Flexible Server. Hoewel het mogelijk is om de ondersteunde waarde 2te wijzigen in, is het terugdraaien van 2 terug naar 1 niet toegestaan. Voor hulp bij het wijzigen van de standaardwaarde maakt u een ondersteuningsticket.

innodb_tmpdir

U gebruikt de parameter innodb_tmpdir in Azure Database for MySQL - Flexible Server om de map te definiëren voor tijdelijke sorteerbestanden die zijn gemaakt tijdens onlinebewerkingen ALTER TABLE die opnieuw worden gebouwd.

De standaardwaarde innodb_tmpdir is /mnt/temp. Deze locatie komt overeen met de tijdelijke opslag (SSD) en is beschikbaar in gibibytes (GiB) met elke rekenkracht van de server. Deze locatie is ideaal voor bewerkingen waarvoor geen grote hoeveelheid ruimte nodig is.

Als u meer ruimte nodig hebt, kunt u instellen innodb_tmpdir op /app/work/tmpdir. Deze instelling maakt gebruik van de beschikbare opslagcapaciteit op uw Azure Database for MySQL Flexible Server. Deze instelling kan handig zijn voor grotere bewerkingen waarvoor meer tijdelijke opslag is vereist.

Houd er rekening mee dat het gebruik van /app/work/tmpdir resultaten resulteert in tragere prestaties in vergelijking met de standaardwaarde voor tijdelijke opslag (SSD)./mnt/temp Maak de keuze op basis van de specifieke vereisten van de bewerkingen.

De opgegeven innodb_tmpdir informatie is van toepassing op de parameters innodb_temp_tablespaces_dir, tmpdir en slave_load_tmpdir wanneer:

• De standaardwaarde /mnt/temp is gebruikelijk.
• De alternatieve map /app/work/tmpdir is beschikbaar voor het configureren van verbeterde tijdelijke opslag, met een afweging in prestaties op basis van specifieke operationele vereisten.

log_bin_trust_function_creators

In Azure Database for MySQL - Flexibele server zijn binaire logboeken altijd ingeschakeld (dat wil gezegd, log_bin is ingesteld op ON). De log_bin_trust_function_creators parameter is standaard ingesteld ON op flexibele servers.

De indeling voor binaire logboekregistratie is altijd ROWen verbindingen met de server maken altijd gebruik van binaire logboekregistratie op basis van rijen. Met binaire logboekregistratie op basis van rijen bestaan er geen beveiligingsproblemen en kunnen binaire logboekregistraties niet worden onderbroken, zodat u veilig kunt toestaan log_bin_trust_function_creators om te blijven als ON.

Als log_bin_trust_function_creators deze optie is ingesteld OFF op en u triggers probeert te maken, krijgt u mogelijk fouten die vergelijkbaar zijn met: 'U beschikt niet over de SUPER-bevoegdheid en binaire logboekregistratie is ingeschakeld (mogelijk wilt u de minder veilige log_bin_trust_function_creators variabele gebruiken).'

innodb_buffer_pool_size

Raadpleeg de innodb_buffer_pool_size voor meer informatie over de parameter.

De grootte van het fysieke geheugen in de volgende tabel vertegenwoordigt het beschikbare RAM-geheugen (random access memory), in gigabytes (GB) op uw Flexibele Azure Database for MySQL-server.

innodb_file_per_table

MySQL slaat de InnoDB-tabel op in verschillende tabelruimten op basis van de configuratie die u hebt opgegeven tijdens het maken van de tabel. De systeemtabelruimte is het opslaggebied voor de InnoDB-gegevenswoordenlijst. Een tabelruimte bestand per tabel bevat gegevens en indexen voor één InnoDB-tabel en wordt opgeslagen in het bestandssysteem in een eigen gegevensbestand. De innodb_file_per_table serverparameter bepaalt dit gedrag.

Instelling innodb_file_per_table om ervoor te OFF zorgen dat InnoDB tabellen maakt in de systeemtabelruimte. Anders maakt InnoDB tabellen in tabelruimten per tabel.

Azure Database for MySQL - Flexible Server ondersteunt maximaal 8 terabytes (TB) in één gegevensbestand. Als de database groter is dan 8 TB, moet u de tabel in de innodb_file_per_table tabelruimte maken. Als u één tabelgrootte hebt die groter is dan 8 TB, moet u de partitietabel gebruiken.

innodb_log_file_size

De waarde van innodb_log_file_size is de grootte (in bytes) van elk logboekbestand in een logboekgroep. De gecombineerde grootte van logboekbestanden (innodb_log_file_size innodb_log_files_in_group * ) mag niet groter zijn dan een maximumwaarde van iets minder dan 512 GB.

Een grotere logboekbestandsgrootte is beter voor prestaties, maar het nadeel is dat de hersteltijd na een crash hoog is. U moet de hersteltijd voor het zeldzame geval van een crash in balans laten en de doorvoer tijdens piekbewerkingen maximaliseren. Een groter logboekbestand kan ook leiden tot langere herstarttijden.

U kunt configureren innodb_log_size tot 256 megabytes (MB), 512 MB, 1 GB of 2 GB voor Azure Database for MySQL - Flexibele server. De parameter is statisch en vereist opnieuw opstarten.

maximale verbindingen

De geheugengrootte van de server bepaalt de waarde van max_connections. De grootte van het fysieke geheugen in de volgende tabel vertegenwoordigt het beschikbare RAM-geheugen , in gigabytes, op uw Flexibele Azure Database for MySQL-server.

Wanneer verbindingen de limiet overschrijden, wordt mogelijk de volgende fout weergegeven: 'ERROR 1040 (08004): Too many connections'.

Het maken van nieuwe clientverbindingen met MySQL kost tijd. Nadat u deze verbindingen tot stand hebt gebracht, nemen ze databaseresources in beslag, zelfs wanneer ze niet actief zijn. De meeste toepassingen vragen veel kortstondige verbindingen aan, waardoor deze situatie wordt samengesteld. Het resultaat is minder resources beschikbaar voor uw werkelijke workload, wat leidt tot verminderde prestaties.

Een verbindingspooler die niet-actieve verbindingen vermindert en bestaande verbindingen hergebruikt, helpt u dit probleem te voorkomen. Voor de beste ervaring raden we u aan een verbindingspooler zoals ProxySQL te gebruiken om verbindingen efficiënt te beheren. Zie dit blogbericht voor meer informatie over het instellen van ProxySQL.

innodb_strict_mode

Als u een foutmelding krijgt die vergelijkbaar is met 'Rijgrootte te groot (> 8126),' wilt u mogelijk de innodb_strict_mode serverparameter uitschakelen. Deze parameter kan niet globaal worden gewijzigd op serverniveau, omdat als rijgegevens groter zijn dan 8K, de gegevens worden afgekapt zonder een fout. Deze afkapping kan leiden tot mogelijk gegevensverlies. U wordt aangeraden het schema aan te passen aan de limiet voor het paginaformaat.

U kunt deze parameter instellen op sessieniveau met behulp van init_connect. Zie Niet-aanpasbare serverparameters instellen voor meer informatie.

tijdzone

U kunt de tijdzonetabellen vullen met de meest recente tijdzonegegevens door de mysql.az_load_timezone opgeslagen procedure aan te roepen vanuit een hulpprogramma, zoals de MySQL-opdrachtregel of MySQL Workbench, en vervolgens de globale tijdzones in te stellen met behulp van Azure Portal of de Azure CLI. Tijdzones worden automatisch geladen tijdens het maken van de server, waardoor klanten de mysql.az_load_timezone opgeslagen procedure niet meer handmatig hoeven uit te voeren om de tijdzone in te laden.

binlog_expire_logs_seconds

In Azure Database for MySQL - Flexible Server geeft de binlog_expire_logs_seconds parameter het aantal seconden op dat de service wacht voordat het binaire logboekbestand wordt verwijderd.

Het binaire logboek bevat gebeurtenissen die databasewijzigingen beschrijven, zoals bewerkingen voor het maken van tabellen of wijzigingen in tabelgegevens. Het binaire logboek bevat ook gebeurtenissen voor instructies die mogelijk wijzigingen kunnen hebben aangebracht. Het binaire logboek wordt voornamelijk gebruikt voor twee doeleinden: replicatie- en gegevensherstelbewerkingen.

Meestal worden de binaire logboeken verwijderd zodra de ingang vrij is van de service, back-up of replicaset. Als er meerdere replica's zijn, wachten de binaire logboeken tot de langzaamste replica de wijzigingen heeft gelezen voordat ze worden verwijderd.

Als u binaire logboeken langer wilt bewaren, kunt u de binlog_expire_logs_seconds parameter configureren. Als binlog_expire_logs_seconds dit is ingesteld op de standaardwaarde van 0, wordt een binair logboek verwijderd zodra de ingang wordt vrijgemaakt. Als de waarde binlog_expire_logs_seconds groter is dan 0, wordt het binaire logboek verwijderd na het geconfigureerde aantal seconden.

Azure Database for MySQL - Flexible Server verwerkt beheerde functies, zoals back-up en leesreplicaverwijdering van binaire bestanden, intern. Wanneer u de gegevens vanuit Azure Database for MySQL - Flexible Server repliceert, moet deze parameter worden ingesteld in de primaire server om te voorkomen dat binaire logboeken worden verwijderd voordat de replica wordt gelezen uit de wijzigingen in de primaire server. Als u instelt op binlog_expire_logs_seconds een hogere waarde, worden de binaire logboeken niet snel genoeg verwijderd. Deze vertraging kan leiden tot een toename van de opslagfacturering.

Beperkingen

Zodra de functie voor versnelde logboeken is ingeschakeld, wordt de binlog_expire_logs_seconds-serverparameter volledig genegeerd en heeft een geconfigureerde waarde geen effect meer. Als de functie voor versnelde logboeken echter is uitgeschakeld, voldoet de server opnieuw aan de geconfigureerde waarde van binlog_expire_logs_seconds voor het bewaren van binaire logboeken. Dit geldt ook voor replicaservers.

evenementplanner

In Azure Database for MySQL - Flexible Server beheert de event_scheduler serverparameter het maken, plannen en uitvoeren van gebeurtenissen. Dat wil gezegd, de parameter beheert taken die worden uitgevoerd volgens een planning door een speciale MySQL Event Scheduler-thread. Wanneer de event_scheduler parameter is ingesteld ONop, wordt de Event Scheduler-thread weergegeven als een daemonproces in de uitvoer van SHOW PROCESSLIST.

Voor MySQL-versie 5.7-servers wordt de serverparameter event_scheduler automatisch 'UIT' uitgeschakeld wanneer back-up wordt gestart en serverparameter event_scheduler 'AAN' wordt teruggezet nadat de back-up is voltooid. In MySQL versie 8.0 voor Azure Database for MySQL - Flexible Server blijft de event_scheduler ongewijzigd tijdens back-ups. Om soepelere bewerkingen te garanderen, is het raadzaam om uw MySQL 5.7-servers te upgraden naar versie 8.0 met behulp van een primaire versie-upgrade.

U kunt gebeurtenissen maken en plannen met behulp van de volgende SQL-syntaxis:

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

Voor meer informatie over het maken van een gebeurtenis raadpleegt u de volgende documentatie over de Event Scheduler in de MySQL-referentiehandleiding:

• Event Scheduler gebruiken in MySQL 5.7
• Event Scheduler gebruiken in MySQL 8.0

De event_scheduler-serverparameter configureren

In het volgende scenario ziet u een manier om de event_scheduler parameter te gebruiken in Azure Database for MySQL - Flexible Server.

Bekijk het volgende voorbeeld van een eenvoudige tabel om het scenario te demonstreren:

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

Een SQL-instructie elk uur zonder einde uitvoeren:

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

Elke dag een SQL-instructie uitvoeren zonder einde:

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

Beperkingen

Voor servers waarop hoge beschikbaarheid is geconfigureerd, is het mogelijk dat de event_scheduler serverparameter is ingesteld OFFop . Als dit gebeurt, configureert u wanneer de failover is voltooid, de parameter om de waarde ONin te stellen op .

innodb_ft_user_stopword_table

innodb_ft_user_stopword_table is een serverparameter in MySQL waarmee de naam van de tabel met aangepaste stopwoorden voor InnoDB Zoeken in volledige tekst wordt opgegeven. De tabel moet zich in dezelfde database bevinden als de geïndexeerde tabel met volledige tekst en de eerste kolom moet van het type VARCHARzijn. In Azure Database for MySQL - Flexible Server zorgt de standaardinstelling ervoor sql_generate_invisible_primary_key=ON dat alle tabellen zonder expliciete primaire sleutel automatisch een onzichtbare primaire sleutel bevatten. Dit gedrag is strijdig met de vereisten voor innodb_ft_user_stopword_table, omdat de onzichtbare primaire sleutel de eerste kolom van de tabel wordt, waardoor deze niet werkt zoals bedoeld tijdens zoeken in volledige tekst. U kunt dit probleem oplossen door in dezelfde sessie in te stellen sql_generate_invisible_primary_key=OFF voordat u de aangepaste stopword-tabel maakt. Voorbeeld:

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

Dit zorgt ervoor dat de stopword-tabel voldoet aan de vereisten van MySQL en dat aangepaste stopwoorden correct kunnen werken.

Niet-aanpasbare serverparameters

In het deelvenster Serverparameters in De Azure-portal worden zowel de wijzigbare als niet-aanpasbare serverparameters weergegeven. De niet-aanpasbare serverparameters zijn niet beschikbaar. U kunt een niet-configureerbare serverparameter configureren op sessieniveau met behulp van init_connect Azure Portal of de Azure CLI.

Azure mysql-systeemvariabelen

azure_server_name

De azure_server_name variabele biedt de exacte servernaam van het exemplaar van Azure Database for MySQL - Flexible Server. Deze variabele is handig wanneer toepassingen of scripts programmatisch de hostnaam van de server moeten ophalen waarmee ze zijn verbonden, zonder afhankelijk te zijn van externe configuraties en kunnen worden opgehaald door de volgende opdracht in MySQL uit te voeren.

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

Opmerking: De azure_server_name geeft consistent de oorspronkelijke servernaam terug die u gebruikt om verbinding te maken met de service (bijvoorbeeld myflex), zowel voor servers met hoge beschikbaarheid als voor servers zonder hoge beschikbaarheid.

logische_server_naam

De logical_server_name variabele vertegenwoordigt de hostnaam van het exemplaar waarop Azure Database for MySQL - Flexible Server wordt uitgevoerd. Deze variabele is handig voor het identificeren van de host waar de service momenteel wordt uitgevoerd, met hulp bij het oplossen van problemen en failoverbewaking. U kunt deze variabele ophalen door de volgende opdracht uit te voeren in MySQL.

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

Opmerking: Voor een server met hoge beschikbaarheid geeft de variabele de logical_server_name hostnaam weer van de instantie die als primaire server fungeert. Voor een server waar HOGE beschikbaarheid is uitgeschakeld, is de waarde logical_server_name gelijk aan de azure_server_name variabele omdat er slechts één exemplaar is.

Gerelateerde inhoud

• Serverparameters configureren in Azure Database for MySQL - Flexible Server met behulp van Azure Portal
• Serverparameters configureren in Azure Database for MySQL - Flexible Server met behulp van de Azure CLI