Serverparameter in Azure Database for MySQL – flexibler Server

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

Was sind Serverparameter?

Das MySQL-Modul stellt viele Serverparameter (auch als Variablen bezeichnet) bereit, die Sie zum Konfigurieren und Optimieren des Modulverhaltens verwenden können. Einige Parameter können während der Laufzeit dynamisch festgelegt werden. Andere sind statisch und erfordern einen Serverneustart, nachdem Sie sie festgelegt haben.

In Azure Database for MySQL – flexibler Server können Sie den Wert verschiedener MySQL-Serverparameter entsprechend den Anforderungen Ihrer Workload ändern, indem Sie die Anleitungen unter Konfigurieren von Serverparametern in Azure Database for MySQL – flexibler Server mithilfe des Azure-Portals und Konfigurieren von Serverparametern in Azure Database for MySQL – flexibler Server mithilfe der Azure CLI verwenden.

Konfigurierbare Serverparameter

Sie können die Konfiguration einer Instanz von Azure Database for MySQL – flexibler Server über Serverparameter verwalten. Die Serverparameter werden beim Erstellen des Servers mit Standardwerten und empfohlenen Werten konfiguriert. Auf dem Blatt Serverparameter im Azure-Portal werden sowohl änderbare als auch nicht änderbare Parameter angezeigt. Die nicht änderbaren Serverparameter sind deaktiviert.

Die Liste der unterstützten Serverparameter wächst ständig. Sie können das Azure-Portal verwenden, um die vollständige Liste der Serverparameter regelmäßig anzuzeigen und die Werte zu konfigurieren.

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 Azure Resource Manager-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, posten Sie eine Idee über Communityfeedback oder geben Ihre Stimme ab, wenn bereits Feedback gegeben wurde. So helfen Sie uns bei der Priorisierung.

In den folgenden Abschnitten werden die Grenzwerte der häufig aktualisierten Serverparameter beschrieben. Die Computeebene und die Größe (vCores) des Servers bestimmen die Grenzwerte.

lower_case_table_names

Für MySQL Version 8.0+ können Sie lower_case_table_names nur konfigurieren, wenn Sie den Server initialisieren. Weitere Informationen. Das Ändern der Einstellung lower_case_table_names nach der Initialisierung des Servers ist unzulässig. Die unterstützten Werte für MySQL Version 8.0 sind 1 und 2 in Azure Database for MySQL – Flexibler Server. Standardwert: 1.

Sie können diese Einstellungen während der Servererstellung im Portal konfigurieren, indem Sie auf der Seite "Zusätzliche Konfiguration" den gewünschten Wert unter "Serverparameter" angeben. Bei Wiederherstellungsvorgängen oder Replikatservern wird der Parameter automatisch vom Quellserver kopiert und kann nicht geändert werden.

Für MySQL Version 5.7 lautet der Standardwert lower_case_table_names in Azure Database for MySQL – flexibler Server 1. Obwohl es möglich ist, den unterstützten Wert auf 2 zu ändern, ist das Zurücksetzen von 2 zurück auf 1 nicht zulässig. Um Unterstützung beim Ändern des Standardwerts zu erhalten, öffnen Sie ein Supportticket.

innodb_tmpdir

Mit dem innodb_tmpdir-Parameter in Azure Database for MySQL – flexibler Server definieren Sie das Verzeichnis für temporäre Sortierdateien, die während ALTER TABLE-Onlinevorgängen erstellt wurden und neu erstellt werden.

Der Standardwert von innodb_tmpdir lautet /mnt/temp. Dieser Speicherort entspricht dem für jede Computegröße auf dem Server verfügbaren temporären SSD-Speicher in Gibibytes (GiB). Dieser Speicherort eignet sich ideal für Vorgänge, die keinen großen Speicherplatz benötigen.

Wenn Sie mehr Platz benötigen, können Sie innodb_tmpdir auf /app/work/tmpdir festlegen. Diese Einstellung verwendet die verfügbare Speicherkapazität Ihrer Instanz von Azure Database for MySQL – flexibler Server. Diese Einstellung kann für größere Vorgänge nützlich sein, die mehr temporären Speicher erfordern.

Beachten Sie, dass die Verwendung von /app/work/tmpdir die Leistung im Vergleich zum -Wert des /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, wobei:

• Der Standardwert /mnt/temp ist üblich.
• Das alternative Verzeichnis /app/work/tmpdir steht für die Konfiguration erhöhter temporärer Speicher zur Verfügung, wobei ein Kompromiss in der Leistung auf der Grundlage bestimmter betrieblicher Anforderungen besteht.

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). Der log_bin_trust_function_creators-Parameter ist auf flexible Server standardmäßig auf ON festgelegt.

Das Format für binäre Protokollierung ist immer ROW und für 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 zum Parameter innodb_buffer_pool_size finden Sie in der MySQL-Dokumentation.

Die Größe des physischen Speichers in der folgenden Tabelle stellt den verfügbaren Arbeitsspeicher (Random Access Memory, RAM) Ihrer Instanz von Azure Database for MySQL – flexibler Server in Gigabyte (GB) dar.

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. Der Serverparameter innodb_file_per_table steuert dieses Verhalten.

Durch Festlegen von innodb_file_per_table auf OFF werden Tabellen von InnoDB im Systemtabellenbereich erstellt. Andernfalls werden die Tabellen von InnoDB im „file-per-table“-Tabellenbereich erstellt.

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

innodb_log_file_size

Der Wert 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 eines Absturzes und der Maximierung des Durchsatzes während Spitzenvorgängen abwägen. Eine größere Protokolldatei 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 Megabytes (MB), 512 MB, 1 GB oder 2 GB. Der Parameter ist statisch und erfordert einen Neustart.

max_connections

Die Arbeitsspeichergröße des Servers bestimmt den Wert von max_connections. Die Größe des physischen Speichers in der folgenden Tabelle stellt den verfügbaren Arbeitsspeicher (Random Access Memory, RAM) Ihrer Instanz von Azure Database for MySQL – flexibler Server in Gigabyte dar.

Wenn Verbindungen den Grenzwert übersteigen, erhalten Sie möglicherweise den folgenden Fehler: „FEHLER 1040 (08004): Zu viele Verbindungen.“

Erstellen neuer Clientverbindungen in MySQL bedarf Zeit. Nachdem Sie diese Verbindungen hergestellt haben, belegen sie Datenbankressourcen, auch wenn sie im Leerlauf sind. 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 Ihnen dabei, dieses Problem zu vermeiden. Für eine optimale Erfahrung empfehlen wir, dass Sie einen Verbindungsspooler wie ProxySQL verwenden, um Verbindungen effizient zu verwalten. Weitere Informationen zum Einrichten von ProxySQL finden Sie in diesem Blogbeitrag.

innodb_strict_mode

Wenn ein Fehler wie „Zeile zu groß (> 8126)“ angezeigt wird, sollten Sie den Parameter innodb_strict_mode deaktivieren. Dieser Parameter 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. Diese Kürzung kann zu potenziellem Datenverlust führen. Es wird empfohlen, das Schema so zu ändern, dass es der Seitengrößenbeschränkung entspricht.

Sie können diesen Parameter mithilfe von init_connect auf Sitzungsebene festlegen. Weitere Informationen finden Sie unter Festlegen nicht modifizierbarer Serverparameter.

Zeitzone

Sie können die Zeitzonentabellen mit den neuesten Zeitzoneninformationen auffüllen, indem Sie die mysql.az_load_timezone gespeicherte Prozedur aus einem Tool wie der MySQL-Befehlszeile oder der MySQL Workbench aufrufen und dann die globalen Zeitzonen mithilfe des Azure-Portals oder der Azure CLI festlegen. Zeitzonen werden während der Servererstellung automatisch geladen, wodurch die Notwendigkeit für Kunden entfernt wird, die mysql.az_load_timezone gespeicherte Prozedur anschließend manuell auszuführen, um die Zeitzone zu laden.

innodb_temp_data_file_size_max

Für Azure Database for MySQL Flexible Server (nur Version 5.7) definiert innodb_temp_data_file_size_max Parameter die maximale Größe temporärer InnoDB-Tabellenbereich-Datendateien in MB. Das Festlegen des Werts auf 0 bedeutet keine Beschränkung, sodass das Wachstum bis zur vollständigen Speichergröße möglich ist. Jeder Wert ungleich Null unter 64 MB wird auf 64 MB aufgerundet, während werte über 64 MB wie angegeben angewendet werden. Dies ist eine statische Variable und erfordert einen Serverneustart, damit Änderungen wirksam werden.

binlog_expire_logs_seconds

In Azure Database for MySQL – flexibler Server gibt der binlog_expire_logs_seconds-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. Das binäre Protokoll 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 gelöscht werden.

Wenn binäre Protokolle länger beibehalten werden sollen, können Sie den Parameter binlog_expire_logs_secondskonfigurieren. Wenn binlog_expire_logs_seconds auf den Standardwert 0 festgelegt ist, wird ein binäres Protokoll gelöscht, sobald das Handle für das Binärprotokoll freigegeben wird. Wenn der Wert binlog_expire_logs_seconds größer als 0 ist, wird das binäre Protokoll nach der konfigurierten Anzahl von Sekunden gelöscht.

Azure Database for MySQL – Flexibler Server behandelt verwaltete Features wie das Löschen von Binärdateien aus Sicherungen und Lesereplikaten intern. 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 binlog_expire_logs_seconds auf einen höheren Wert festlegen, werden die binären Protokolle nicht bald genug gelöscht. Diese Verzögerung kann zu einer Erhöhung der Abrechnung für Speicher führen.

Einschränkungen

Sobald die Funktion für schnellere Protokollierung aktiviert ist, wird der Serverparameter binlog_expire_logs_seconds vollständig ignoriert, und jeder konfigurierte Wert verliert seine Wirkung. Wenn das Feature für beschleunigte Protokolle jedoch deaktiviert ist, hält der Server erneut den konfigurierten Wert von binlog_expire_logs_seconds für die Aufbewahrung binärer Protokolle ein. Dies gilt auch für Replikatserver.

Ereignisplaner

In der Azure Database for MySQL – Flexibler Server verwaltet der event_scheduler-Serverparameter das Erstellen, Planen und Ausführen von Ereignissen. Das heißt, der Parameter verwaltet Aufgaben, die gemäß einem Zeitplan von einem speziellen MySQL Event Scheduler-Thread ausgeführt werden. Wenn der event_scheduler-Parameter auf ON festgelegt ist, wird der Event Scheduler-Thread in der Ausgabe von SHOW PROCESSLIST als Daemon-Prozess aufgeführt.

Bei MySQL-Servern mit Version 5.7 wird der Serverparameter event_scheduler automatisch deaktiviert, wenn die Sicherung initiiert wird. Außerdem wird der Serverparameter event_scheduler nach erfolgreichem Abschluss der Sicherung wieder auf „EIN“ zurückgesetzt. In MySQL Version 8.0 für Azure Database for MySQL – flexibler Server ist „event_scheduler“ während Sicherungen nicht betroffen. Um einen reibungsloseren Betrieb sicherzustellen, empfiehlt es sich, Ihre MySQL 5.7-Server mithilfe eines Hauptversionsupgrades auf Version 8.0 zu aktualisieren.

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

Weitere Informationen zum Erstellen eines Ereignisses finden Sie in der folgenden Dokumentation zum Event Scheduler im MySQL-Referenzhandbuch:

• Verwenden des Event Scheduler in MySQL 5.7
• Verwenden des Event Scheduler in MySQL 8.0

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

So führen Sie eine unbegrenzte stündliche SQL-Anweisung:

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

So führen Sie eine unbegrenzte tägliche 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>;

Einschränkungen

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

innodb_ft_user_stopword_table

innodb_ft_user_stopword_table ist ein Serverparameter in MySQL, der den Namen der Tabelle angibt, die benutzerdefinierte Stoppwörter für die InnoDB-Volltextsuche enthält. Die Tabelle muss sich in derselben Datenbank wie die indizierte Volltexttabelle befinden, und die erste Spalte muss vom Typ VARCHAR sein. In „Azure Database for MySQL – Flexibler Server“ bewirkt die Standardeinstellung sql_generate_invisible_primary_key=ON, dass alle Tabellen ohne expliziten Primärschlüssel automatisch einen unsichtbaren Primärschlüssel enthalten. Dieses Verhalten steht im Konflikt mit den Anforderungen für innodb_ft_user_stopword_table, da der unsichtbare Primärschlüssel zur ersten Spalte der Tabelle wird. Dadurch wird verhindert, dass er während der Volltextsuche wie vorgesehen funktioniert. Um dieses Problem zu beheben, müssen Sie sql_generate_invisible_primary_key=OFF in derselben Sitzung festlegen, bevor Sie die benutzerdefinierte Stoppworttabelle erstellen. Beispiel:

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

Dadurch wird sichergestellt, dass die Stoppworttabelle die Anforderungen von MySQL erfüllt und benutzerdefinierte Stoppwörter ordnungsgemäß funktionieren.

Nicht änderbare Serverparameter

Auf dem Blatt Serverparameter im Azure-Portal werden sowohl änderbare als auch nicht änderbare Serverparameter angezeigt. Die nicht änderbaren Serverparameter sind deaktiviert. Sie können einen nicht modifizierbaren Serverparameter auf Sitzungsebene konfigurieren, indem Sie init_connect im Azure-Portal oder in der Azure CLI verwenden.

Azure Mysql-Systemvariablen

azure_server_name

Die azure_server_name Variable stellt den genauen Servernamen der Azure-Datenbank für MySQL - Flexible Server-Instanz bereit. Diese Variable ist nützlich, wenn Anwendungen oder Skripts den Hostnamen des Servers programmgesteuert abrufen müssen, mit dem sie verbunden sind, ohne sich auf externe Konfigurationen zu verlassen und kann durch Ausführen des folgenden Befehls in MySQL abgerufen werden.

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

Hinweis: Der ursprüngliche Servername, den Sie zum Herstellen einer Verbindung mit dem Dienst verwenden (z. B. myflex), wird von azure_server_name sowohl für HA-fähige als auch HA-deaktivierte Server konsistent zurückgegeben.

Logischer Servername

Die logical_server_name Variable stellt den Hostnamen der Instanz dar, in der Azure Database for MySQL - Flexible Server ausgeführt wird. Diese Variable ist nützlich, um den Host zu identifizieren, auf dem der Dienst derzeit ausgeführt wird, und unterstützt die Problembehandlung und Failoverüberwachung. Sie können diese Variable abrufen, indem Sie den folgenden Befehl in MySQL ausführen.

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

Hinweis: Bei einem HA-fähigen Server gibt die logical_server_name Variable den Hostnamen der Instanz wieder, die als Primärserver fungiert. Für einen Server, auf dem HA deaktiviert ist, entspricht der Wert logical_server_name der azure_server_name Variablen, da nur eine einzelne Instanz vorhanden ist.

Verwandte Inhalte

• Konfigurieren von Serverparametern in Azure Database for MySQL – flexibler Server mithilfe des Azure-Portals
• Konfigurieren von Serverparametern für Azure Database for MySQL – flexibler Server mit der Azure CLI