Serverparameter in Azure Database for MySQL – Flexibler Server

  • Artikel

GILT FÜR: Azure Database for MySQL – Flexible Server

Dieser Artikel enthält Überlegungen und Richtlinien zur Konfiguration von Serverparametern in Azure Database for MySQL – Flexibler Server.

Hinweis

Dieser Artikel enthält Verweise auf den Begriff Slave, einen Begriff, den Microsoft nicht mehr verwendet. Sobald der Begriff aus der Software entfernt wurde, wird er auch aus diesem Artikel entfernt.

Was sind Servervariablen?

Die MySQL-Engine bietet viele verschiedene Servervariablen/-parameter, die zur Konfiguration und Optimierung des Engine-Verhaltens verwendet werden können. Einige der Parameter können dynamisch während der Laufzeit festgelegt werden, während andere „statisch“ sind und ihre Anwendung einen Neustart des Servers erfordert.

Azure Database for MySQL – Flexibler Server bietet die Möglichkeit, den Wert verschiedener MySQL-Serverparameter unter Verwendung des Azure-Portals und der Azure-Befehlszeilenschnittstelle zu ändern, um die Anforderungen Ihrer Workload zu erfüllen.

Konfigurierbare Serverparameter

Sie können die Konfiguration von Azure Database for MySQL – Flexibler Server über Serverparameter verwalten. Die Serverparameter werden beim Erstellen des Servers mit einem Standardwert und einem empfohlenen Wert konfiguriert. Auf dem Blatt „Serverparameter“ im Azure-Portal werden sowohl änderbare als auch nicht änderbare Serverparameter angezeigt. Die nicht änderbaren Serverparameter sind ausgegraut.

Die Liste der unterstützten Serverparameter wächst ständig. Sie können die vollständige Liste im Azure-Portal auf der Registerkarte „Serverparameter“ anzeigen und die Werte der Serverparameter dort konfigurieren.

In den folgenden Abschnitten erfahren Sie mehr über die Grenzwerte der verschiedenen häufig aktualisierten Serverparameter. Die Grenzwerte werden durch den Computetarif und die Größe der virtuellen Kerne des Servers bestimmt.

Hinweis

  • Wenn Sie einen statischen Serverparameter über das Portal ändern, müssen Sie den Server neu starten, damit die Änderungen übernommen werden. Falls Sie Automatisierungsskripts verwenden (mit Tools wie ARM-Vorlagen, Terraform, Azure CLI usw.), sollte Ihr Skript einen Neustart des Dienstes vorsehen, damit die Einstellungen auch dann wirksam werden, wenn Sie die Konfigurationen im Rahmen der Erstellung ändern.
  • Wenn Sie einen nicht änderbaren Serverparameter für Ihre Umgebung ändern möchten, öffnen Sie einen UserVoice-Beitrag oder geben Ihre Stimme ab, wenn bereits Feedback gegeben wurde. So helfen Sie uns bei der Priorisierung.

lower_case_table_names

Für MySQL Version 5.7 lautet der Standardwert in Azure Database for MySQL – Flexibler Server 1. Es ist wichtig zu beachten, dass es zwar möglich ist, den unterstützten Wert in 2 zu ändern, aber das Zurücksetzen von 2 auf 1 ist nicht zulässig. Wenden Sie sich an unser Supportteam, wenn Sie Hilfe beim Ändern des Standardwerts benötigen. Für MySQL Version 8.0 und höher kann „lower_case_table_names“ nur beim Initialisieren des Servers konfiguriert werden. Weitere Informationen Das Ändern der Einstellung „lower_case_table_names“ nach der Initialisierung des Servers ist unzulässig. Für MySQL Version 8.0 lautet der Standardwert in Azure Database for MySQL – Flexibler Server 1. Die unterstützten Werte für MySQL Version 8.0 sind 1 und 2 in Azure Database for MySQL – Flexibler Server. Wenden Sie sich an unser Supportteam, wenn Sie während der Servererstellung Hilfe beim Ändern des Standardwerts benötigen.

innodb_tmpdir

Mit dem innodb_tmpdir-Parameter in Azure Database for MySQL – Flexibler Server wird das Verzeichnis für temporäre Sortierdateien definiert, die während ALTER TABLE-Onlinevorgängen erstellt wurden und neu erstellt werden. Der Standardwert von „innodb_tmpdir“ ist /mnt/temp. Dieser Speicherort entspricht dem für jede Computegröße auf dem Server verfügbaren temporären SSD-Speicher in GiB. Dieser Speicherort eignet sich ideal für Vorgänge, die keinen großen Speicherplatz benötigen. Wenn mehr Speicherplatz benötigt wird, können Sie „innodb_tmpdir“ auf /app/work/tmpdir festlegen. Damit nutzen Sie die gesamte Speicherkapazität Ihrer Instanz von Azure Database for MySQL – Flexibler Server aus. Dies kann für größere Vorgänge nützlich sein, die mehr temporären Speicher erfordern. Es ist wichtig zu beachten, dass die Verwendung von /app/work/tmpdir die Leistung im Vergleich zum temporären Standardspeicher (SSD)/mnt/temp verlangsamt. Treffen Sie Ihre Entscheidung auf der Grundlage der spezifischen Anforderungen der jeweiligen Vorgänge.

Die für innodb_tmpdir bereitgestellten Informationen gelten für die Parameter innodb_temp_tablespaces_dir, tmpdir und slave_load_tmpdir, die den gemeinsamen Standardwert /mnt/temp aufweisen. Das alternative Verzeichnis /app/work/tmpdir steht für die Konfiguration von mehr temporärem Speicher zur Verfügung, wobei je nach den Anforderungen eines Vorgangs Kompromisse bei der Leistung eingegangen werden müssen.

log_bin_trust_function_creators

In Azure Database for MySQL – Flexibler Server sind binäre Protokolle immer aktiviert (d. h., log_bin ist auf ON festgelegt). log_bin_trust_function_creators ist in flexiblen Servern standardmäßig auf ON festgelegt.

Das Format für binäre Protokollierung ist immer ROW (Zeile), und für alle Verbindungen mit dem Server wird IMMER die zeilenbasierte binäre Protokollierung verwendet. Bei der zeilenbasierten binären Protokollierung gibt es keine Sicherheitsprobleme, und die binäre Protokollierung kann nicht unterbrochen werden, sodass log_bin_trust_function_creators sicher auf ON gesetzt bleiben kann.

Wenn [log_bin_trust_function_creators] auf OFF festgelegt ist und Sie versuchen, Trigger zu erstellen, erhalten Sie möglicherweise eine Fehlermeldung wie Sie verfügen nicht über die SUPER-Berechtigung, und die binäre Protokollierung ist aktiviert (es kann ratsam sein, die weniger sichere Variable log_bin_trust_function_creators zu verwenden).

innodb_buffer_pool_size

Weitere Informationen zu diesem Parameter finden Sie in der MySQL-Dokumentation.

Tarif vCore(s) Arbeitsspeichergröße (GiB) Standardwert (Bytes) Mindestwert (Bytes) Höchstwert (Bytes)
Burstfähig (B1s) 1 1 134217728 33554432 134217728
Burstfähig (B1ms) 1 2 536870912 134217728 536870912
Burstfähig 2 4 2147483648 134217728 2147483648
Universell 2 8 5368709120 134217728 5368709120
Universell 4 16 12884901888 134217728 12884901888
Universell 8 32 25769803776 134217728 25769803776
Universell 16 64 51539607552 134217728 51539607552
Universell 32 128 103079215104 134217728 103079215104
Universell 48 192 154618822656 134217728 154618822656
Universell 64 256 206158430208 134217728 206158430208
Unternehmenskritisch 2 16 12884901888 134217728 12884901888
Unternehmenskritisch 4 32 25769803776 134217728 25769803776
Unternehmenskritisch 8 64 51539607552 134217728 51539607552
Unternehmenskritisch 16 128 103079215104 134217728 103079215104
Unternehmenskritisch 32 256 206158430208 134217728 206158430208
Unternehmenskritisch 48 384 309237645312 134217728 309237645312
Unternehmenskritisch 64 504 405874409472 134217728 405874409472

innodb_file_per_table

MySQL speichert die InnoDB-Tabelle in verschiedenen Tabellenbereichen, basierend auf der Konfiguration, die Sie während der Tabellenerstellung angegeben haben. Der Systemtabellenbereich ist der Speicherbereich für das InnoDB-Datenwörterbuch. Ein file-per-table-Tabellenbereich enthält die Daten und Indizes für eine einzelne InnoDB-Tabelle und wird im Dateisystem in einer eigenen Datendatei gespeichert. Dieses Verhalten wird vom innodb_file_per_table-Serverparameter gesteuert. Durch Festlegen von innodb_file_per_table auf OFF werden Tabellen von InnoDB im Systemtabellenbereich erstellt. Andernfalls werden die Tabellen im Tabellen-Tabellenbereich erstellt.

Azure Database for MySQL – Flexibler Server unterstützt bis zu 4 TB in einer einzelnen Datendatei. Wenn die Datenbankgröße 4 TB überschreitet, sollten Sie die Tabelle im Tabellenbereich innodb_file_per_table erstellen. Wenn eine einzelne Tabelle größer als 4 TB ist, sollten Sie die Partitionstabelle verwenden.

innodb_log_file_size

innodb_log_file_size ist die Größe in Bytes jeder Protokolldatei in einer Protokollgruppe. Die kombinierte Größe der Protokolldateien (innodb_log_file_size * innodb_log_files_in_group) darf einen Maximalwert von etwas weniger als 512 GB nicht überschreiten. Eine größere Protokolldateigröße ist für die Leistung besser, hat jedoch den Nachteil, dass die Wiederherstellungszeit nach einem Absturz hoch ist. Sie müssen zwischen der Wiederherstellungszeit im seltenen Fall einer Absturzwiederherstellung und der Maximierung des Durchsatzes während Spitzenvorgängen abwägen. Dies kann auch zu längeren Neustartzeiten führen. Sie können „innodb_log_size“ für Azure Database for MySQL – Flexibler Server mit diesen Werten konfigurieren: 256 MB, 512 MB, 1 GB oder 2 GB. Der Parameter ist statisch und erfordert einen Neustart.

Hinweis

Wenn Sie den Parameter „innodb_log_file_size“ vom Standardwert geändert haben, überprüfen Sie, ob der Wert von „show global status like“ wie „innodb_buffer_pool_pages_dirty“ dreißig Sekunden lang auf 0 bleibt, um eine Verzögerung des Neustarts zu vermeiden.

max_connections

Der Wert von max_connection wird durch die Speichergröße des Servers bestimmt.

Tarif vCore(s) Arbeitsspeichergröße (GiB) Standardwert Mindestwert Höchstwert
Burstfähig (B1s) 1 1 85 10 171
Burstfähig (B1ms) 1 2 171 10 341
Burstfähig 2 4 341 10 683
Universell 2 8 683 10 1365
Universell 4 16 1365 10 2731
Universell 8 32 2731 10 5461
Universell 16 64 5461 10 10923
Universell 32 128 10923 10 21845
Universell 48 192 16384 10 32768
Universell 64 256 21845 10 43691
Unternehmenskritisch 2 16 1365 10 2731
Unternehmenskritisch 4 32 2731 10 5461
Unternehmenskritisch 8 64 5461 10 10923
Unternehmenskritisch 16 128 10923 10 21845
Unternehmenskritisch 32 256 21845 10 43691
Unternehmenskritisch 48 384 32768 10 65536
Unternehmenskritisch 64 504 43008 10 86016

Wenn Verbindungen den Grenzwert übersteigen, erhalten Sie möglicherweise den folgenden Fehler:

FEHLER 1040 (08004): Zu viele Verbindungen

Wichtig

Für eine optimale Erfahrung empfehlen wir, dass Sie einen Verbindungspooler wie ProxySQL verwenden, um Verbindungen effizient zu verwalten.

Das Erstellen neuer Clientverbindungen mit MySQL nimmt Zeit in Anspruch, und nach der Herstellung belegen diese Verbindungen Datenbankressourcen, auch wenn Sie sich im Leerlauf befinden. Die meisten Anwendungen fordern viele kurzlebige Verbindungen an, was diese Situation erschwert. Das Ergebnis sind weniger Ressourcen, die für ihre tatsächliche Workload verfügbar sind, was zu verringerter Leistung führt. Ein Verbindungspooler, der Verbindungen im Leerlauf reduziert und vorhandene Verbindungen wiederverwendet, hilft dabei, dies zu vermeiden. Weitere Informationen zum Einrichten von ProxySQL finden Sie in unserem Blogbeitrag.

Hinweis

ProxySQL ist ein Open Source-Communitytool. Es wird von Microsoft bestmöglich unterstützt. Wenden Sie sich an den ProxySQL-Produktsupport, wenn Sie Produktionssupport mit autoritativen Hinweisen benötigen.

innodb_strict_mode

Wenn ein Fehler wie „Zeile zu groß (> 8126)“ angezeigt wird, sollten Sie den Parameter innodb_strict_mode auf OFF festlegen. Der Serverparameter innodb_strict_mode kann nicht global auf der Serverebene geändert werden, da die Daten bei Überschreitung einer Zeilendatengröße von 8.000 ohne Fehlermeldung gekürzt werden, was zu Datenverlusten führen kann. Es wird empfohlen, das Schema so zu ändern, dass es der Seitengrößenbeschränkung entspricht.

Dieser Parameter kann mithilfe von init_connect auf Sitzungsebene festgelegt werden. Informationen zum Festlegen von innodb_strict_mode auf Sitzungsebene finden Sie Nicht aufgeführte Einstellungsparameter.

Hinweis

Wenn Sie über einen Lesereplikatserver verfügen, wird die Replikation unterbrochen, wenn Sie innodb_strict_mode auf einem Quellserver auf Sitzungsebene auf OFF festlegen. Wir empfehlen, den Parameter auf „ON“ festzulegen, wenn Sie über Lesereplikate verfügen.

time_zone

Bei der ersten Bereitstellung enthält eine Instanz von Azure Database for MySQL – Flexibler Server Systemtabellen für Zeitzoneninformationen, die jedoch nicht gefüllt sind. Die Zeitzonentabellen können durch Aufrufen der gespeicherten Prozedur mysql.az_load_timezone über ein Tool wie die MySQL-Befehlszeile oder MySQL Workbench aufgefüllt werden. Informationen zum Aufrufen der gespeicherten Prozedur und zum Festlegen der globalen Zeitzonen oder Zeitzonen auf Sitzungsebene finden Sie in den Artikeln für das Azure-Portal und die Azure CLI.

binlog_expire_logs_seconds

In Azure Database for MySQL – Flexibler Server gibt dieser Parameter die Anzahl der Sekunden an, die der Dienst wartet, bevor die binäre Protokolldatei gelöscht wird.

Das binäre Protokoll enthält „Ereignisse“, die Datenbankänderungen beschreiben, z. B. Tabellenerstellungsvorgänge oder Änderungen an Tabellendaten. Es enthält auch Ereignisse für Anweisungen, die möglicherweise Änderungen vorgenommen haben. Das binäre Protokoll wird hauptsächlich für zwei Zwecke verwendet: für Replikations- und Datenwiederherstellungsvorgänge. In der Regel werden die binären Protokolle gelöscht, sobald das Handle von Dienst, Sicherung oder Replikatgruppe freigegeben wird. Wenn es mehrere Replikate gibt, warten die Binärprotokolle, bis das langsamste Replikat die Änderungen gelesen hat, bevor sie bereinigt werden. Wenn binäre Protokolle für einen längeren Zeitraum beibehalten werden sollen, können Sie den Parameter binlog_expire_logs_seconds konfigurieren. Wenn der Parameter binlog_expire_logs_seconds auf 0 (Standardwert) festgelegt ist, erfolgt die Löschung, sobald das Handle für das binäre Protokoll freigegeben wird. Wenn binlog_expire_logs_seconds > 0 ist, wird mit der Löschung gewartet, bis die konfigurierten Sekunden abgelaufen sind. Für Azure Database for MySQL – Flexibler Server werden verwaltete Features wie das Löschen von Binärdateien aus Sicherungen und Lesereplikaten intern behandelt. Wenn Sie die Daten aus Azure Database for MySQL – Flexibler Server replizieren, muss dieser Parameter am primären Speicherort festgelegt werden, um zu vermeiden, dass binäre Protokolle gelöscht werden, bevor das Replikat die Änderungen des primären Speicherorts gelesen hat. Wenn Sie den Parameter binlog_expire_logs_seconds auf einen höheren Wert festlegen, werden die binären Protokolle nicht schnell genug gelöscht und können zu einer Erhöhung der Speicherabrechnung führen.

event_scheduler

In Azure Database for MySQL – Flexibler Server verwaltet der Serverparameter event_schedule das Erstellen, Planen und Ausführen von Ereignissen, d. h. von Aufgaben, die nach einem Zeitplan ausgeführt werden. Diese Aufgaben werden in einem speziellen Ereignisplanerthread ausgeführt. Wenn der event_scheduler-Parameter aktiviert ist, wird der Ereignisplaner-Thread in der Ausgabe von SHOW PROCESSLIST als Daemon-Prozess aufgeführt. Sie können Ereignisse mit der folgenden SQL-Syntax erstellen und planen:

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

Hinweis

Weitere Informationen über die Erstellung eines Ereignisses finden Sie in der Dokumentation zu MySQL Event Scheduler:

Konfigurieren des event_scheduler-Serverparameters

Das folgende Szenario veranschaulicht eine Möglichkeit zur Verwendung des event_scheduler-Parameters in Azure Database for MySQL – Flexibler Server. Das folgende Beispiel, eine einfache Tabelle, soll das Szenario verdeutlichen:

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)

Führen Sie zum Konfigurieren des Serverparameters event_scheduler in Azure Database for MySQL – Flexibler Server die folgenden Schritte aus:

  1. Navigieren Sie im Azure-Portal zu Ihrer Instanz von Azure Database for MySQL – Flexibler Server, und wählen Sie dann unter Einstellungen die Option Serverparameter aus.

  2. Suchen Sie auf dem Blatt Serverparameter nach event_scheduler. Wählen Sie in der Dropdownliste VALUE die Option EIN und dann Speichern aus.

    Hinweis

    Die Änderung der dynamischen Serverparameterkonfiguration wird ohne Neustart bereitgestellt.

  3. Stellen Sie dann zum Erstellen eines Ereignisses eine Verbindung mit der Instanz von Azure Database for MySQL – Flexibler Server her, und führen Sie den folgenden SQL-Befehl aus:

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

  4. Um die Details des Event Schedulers anzuzeigen, führen Sie die folgende SQL-Anweisung aus:

    SHOW EVENTS;

    Die folgende Ausgabe wird angezeigt:

    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)

  5. Fragen Sie nach einigen Minuten die Zeilen aus der Tabelle ab, um die Zeilen anzuzeigen, die jede Minute gemäß dem von Ihnen konfigurierten Parameter event_scheduler eingefügt werden:

    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)

  6. Führen Sie nach einer Stunde eine Select-Anweisung für die Tabelle aus, um das vollständige Ergebnis der in die Tabelle eingefügten Werte jede Minute für eine Stunde anzuzeigen, wie event_scheduler in unserem Fall konfiguriert ist.

    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)

Andere Szenarien

Sie können ein Ereignis einrichten, das den Anforderungen Ihres spezifischen Szenarios entspricht. Es folgen einige ähnliche Beispiele für die Planung von SQL-Anweisungen, die in unterschiedlichen Zeitabständen ausgeführt werden sollen.

Führen Sie jetzt eine SQL-Anweisung aus, und lassen Sie sie einmal pro Tag unbegrenzt wiederholen

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

Unbegrenzte stündliche Ausführung einer SQL-Anweisung

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

Unbegrenzte tägliche Ausführung einer SQL-Anweisung

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

Begrenzungen

Bei Servern mit konfigurierter Hochverfügbarkeit ist es bei einem Failover möglich, dass der event_scheduler-Serverparameter auf „OFF“ festgelegt wird. Wenn dies der Fall ist, konfigurieren Sie nach Abschluss des Failovers den Parameter, um den Wert auf „ON“ festzulegen.

Nicht änderbare Serverparameter

Auf dem Blatt „Serverparameter“ im Azure-Portal werden sowohl änderbare als auch nicht änderbare Serverparameter angezeigt. Die nicht änderbaren Serverparameter sind ausgegraut. Wenn Sie einen nicht änderbaren Serverparameter auf Sitzungsebene konfigurieren möchten, erfahren Sie im Artikel Azure-Portal bzw. Azure CLI, wie Sie den Parameter auf Verbindungsebene mithilfe von init_connect festlegen.

Nächste Schritte