Share via

Parametri del server in Database di Azure per MySQL - Server flessibile

  • Articolo

SI APPLICA A: Database di Azure per MySQL - Server flessibile

Questo articolo fornisce considerazioni e linee guida per la configurazione dei parametri del server in Database di Azure per MySQL server flessibile.

Nota

Questo articolo contiene riferimenti al termine slave, che Microsoft non usa più. Quando il termine verrà rimosso dal software, verrà rimosso anche dall'articolo.

Che cosa sono le variabili del server?

Il motore MySQL fornisce molte variabili/parametri del server diversi che possono essere usati per configurare e ottimizzare il comportamento del motore. Alcuni parametri possono essere impostati in modo dinamico durante il runtime, mentre altri sono "statici", che richiedono un riavvio del server per l'applicazione.

Database di Azure per MySQL server flessibile espone la possibilità di modificare il valore di vari parametri del server MySQL usando il portale di Azure e l'interfaccia della riga di comando di Azure in base alle esigenze del carico di lavoro.

Parametri del server configurabili

È possibile gestire Database di Azure per MySQL configurazione flessibile del server usando i parametri del server. I parametri del server vengono configurati con il valore predefinito e consigliato quando si crea il server. Il pannello dei parametri del server nel portale di Azure mostra sia i parametri modificabili che non modificabili del server. I parametri del server non modificabili sono disattivati.

L'elenco di parametri del server supportati è in continua crescita. Usare la scheda parametri del server nella portale di Azure per visualizzare l'elenco completo e configurare i valori dei parametri del server.

Per altre informazioni sui limiti dei diversi parametri del server comunemente aggiornati, vedere le sezioni seguenti. I limiti sono determinati dal livello di calcolo e dalle dimensioni (vCore) del server.

Nota

  • Se si modifica un parametro del server statico usando il portale, è necessario riavviare il server per rendere effettive le modifiche. Se si usano script di automazione (usando strumenti come i modelli arm, Terraform, l'interfaccia della riga di comando di Azure e così via), lo script deve disporre di un provisioning per riavviare il servizio per rendere effettive le impostazioni anche se si modificano le configurazioni come parte dell'esperienza di creazione.
  • Se si vuole modificare un parametro del server non modificabile per l'ambiente in uso, aprire un elemento UserVoice o votare se il feedback esiste già, che può essere utile per definire la priorità.

lower_case_table_names

Per MySQL versione 5.7, il valore predefinito è 1 nel server flessibile Database di Azure per MySQL. È importante notare che, sebbene sia possibile modificare il valore supportato su 2, il ripristino da 2 a 1 non è consentito. Per assistenza nella modifica del valore predefinito, contattare il team di supporto. Per MySQL versione 8.0+ lower_case_table_names può essere configurato solo durante l'inizializzazione del server. Altre informazioni. La modifica dell'impostazione lower_case_table_names dopo l'inizializzazione del server non è consentita. Per MySQL versione 8.0, il valore predefinito è 1 in Database di Azure per MySQL server flessibile. Il valore supportato per MySQL versione 8.0 è 1 e 2 in Database di Azure per MySQL server flessibile. Per assistenza nella modifica del valore predefinito durante la creazione del server, contattare il team di supporto.

innodb_tmpdir

Il parametro innodb_tmpdir in Database di Azure per MySQL Server flessibile viene usato per definire la directory per i file di ordinamento temporanei creati durante le operazioni ALTER TABLE online che ricompilano. Il valore predefinito di innodb_tmpdir è /mnt/temp. Questo percorso corrisponde all'unità SSD di archiviazione temporanea, disponibile in GiB con ogni dimensione di calcolo del server. Questa posizione è ideale per le operazioni che non richiedono una grande quantità di spazio. Se è necessario più spazio, è possibile impostare innodb_tmpdir su /app/work/tmpdir. In questo modo si usa lo spazio di archiviazione, la capacità disponibile nel server flessibile Database di Azure per MySQL. Ciò può essere utile per operazioni di dimensioni maggiori che richiedono più spazio di archiviazione temporaneo. È importante notare che l'uso /app/work/tmpdir dei risultati risulta più lento rispetto all'archiviazione temporanea predefinita (SSD)./mnt/temp La scelta deve essere effettuata in base ai requisiti specifici delle operazioni.

Le informazioni fornite per innodb_tmpdir sono applicabili ai parametri innodb_temp_tablespaces_dir, tmpdir e slave_load_tmpdir in cui il valore /mnt/temp predefinito è comune e la directory /app/work/tmpdir alternativa è disponibile per configurare un'archiviazione temporanea maggiore, con un compromesso in base a requisiti operativi specifici.

log_bin_trust_function_creators

In Database di Azure per MySQL server flessibile, i log binari sono sempre abilitati( ovvero, log_bin è impostato su ON). log_bin_trust_function_creators è impostato su ON per impostazione predefinita nei server flessibili.

Il formato di registrazione binaria è sempre ROW e tutte le connessioni al server usano sempre la registrazione binaria basata su righe. Con la registrazione binaria basata su righe, i problemi di sicurezza non esistono e la registrazione binaria non può interrompersi, quindi è possibile consentire in modo sicuro di log_bin_trust_function_creators rimanere attivo.

Se [log_bin_trust_function_creators] è impostato su OFF, se si tenta di creare trigger, è possibile che si verifichino errori simili a non si dispone del privilegio SUPER e che la registrazione binaria sia abilitata (si potrebbe voler usare la variabile meno sicura log_bin_trust_function_creators ) .

innodb_buffer_pool_size

Per altre informazioni su questo parametro, esaminare la documentazione di MySQL.

Piano tariffario vCore Dimensioni memoria (GiB) Valore predefinito (byte) Valore minimo (byte) Valore massimo (byte)
Burstable (B1s) 1 1 134217728 33554432 134217728
Burstable (B1ms) 1 2 536870912 134217728 536870912
Con possibilità di burst 2 4 2147483648 134217728 2147483648
Utilizzo generico 2 8 5368709120 134217728 5368709120
Utilizzo generico 4 16 12884901888 134217728 12884901888
Utilizzo generico 8 32 25769803776 134217728 25769803776
Utilizzo generico 16 64 51539607552 134217728 51539607552
Utilizzo generico 32 128 103079215104 134217728 103079215104
Utilizzo generico 48 192 154618822656 134217728 154618822656
Utilizzo generico 64 256 206158430208 134217728 206158430208
Business Critical 2 16 12884901888 134217728 12884901888
Business Critical 4 32 25769803776 134217728 25769803776
Business Critical 8 64 51539607552 134217728 51539607552
Business Critical 16 128 103079215104 134217728 103079215104
Business Critical 32 256 206158430208 134217728 206158430208
Business Critical 48 384 309237645312 134217728 309237645312
Business Critical 64 504 405874409472 134217728 405874409472

innodb_file_per_table

MySQL archivia la tabella InnoDB in spazi di tabella diversi in base alla configurazione specificata durante la creazione della tabella. Lo spazio di tabella del sistema è l'area di archiviazione per il dizionario dei dati InnoDB. Uno spazio di tabella di un file per tabella contiene dati e indici per una sola tabella InnoDB e viene archiviato nel file system del file di dati in uso. Questo comportamento è controllato dal parametro del server innodb_file_per_table. Impostando innodb_file_per_table su OFF InnoDB crea tabelle nello spazio di tabella del sistema. Altrimenti, InnoDB crea tabelle in spazi di tabella di un file per tabella.

Database di Azure per MySQL server flessibile supporta un numero massimo di 4 TB in un singolo file di dati. Se le dimensioni del database sono maggiori di 4 TB, è necessario creare la tabella nello spazio di tabella innodb_file_per_table. Se si dispone di una singola tabella di dimensioni superiori a 4 TB, è necessario usare la tabella di partizione.

innodb_log_file_size

innodb_log_file_size è la dimensione in byte di ogni file di log in un gruppo di log. Le dimensioni combinate dei file di log (innodb_log_file_size innodb_log_files_in_group * ) non possono superare un valore massimo leggermente inferiore a 512 GB. Una dimensione del file di log più grande è migliore per le prestazioni, ma presenta uno svantaggio che il tempo di ripristino dopo un arresto anomalo è elevato. È necessario bilanciare il tempo di ripristino nel raro caso di un ripristino di arresto anomalo del sistema rispetto alla massima velocità effettiva durante le operazioni di picco. Questi possono anche comportare tempi di riavvio più lunghi. È possibile configurare innodb_log_size su uno di questi valori: 256 MB, 512 MB, 1 GB o 2 GB per Database di Azure per MySQL server flessibile. Il parametro è statico e richiede un riavvio.

Nota

Se il parametro innodb_log_file_size è stato modificato per impostazione predefinita, controllare se il valore "mostra lo stato globale come "innodb_buffer_pool_pages_dirty" rimane a 0 per 30 secondi per evitare il ritardo di riavvio.

max_connections

Il valore di max_connection è determinato dalle dimensioni della memoria del server.

Piano tariffario vCore Dimensioni memoria (GiB) Valore predefinito: Valore minimo Valore massimo
Burstable (B1s) 1 1 85 10 171
Burstable (B1ms) 1 2 171 10 341
Con possibilità di burst 2 4 341 10 683
Utilizzo generico 2 8 683 10 1365
Utilizzo generico 4 16 1365 10 2731
Utilizzo generico 8 32 2731 10 5461
Utilizzo generico 16 64 5461 10 10923
Utilizzo generico 32 128 10923 10 21845
Utilizzo generico 48 192 16384 10 32768
Utilizzo generico 64 256 21845 10 43691
Business Critical 2 16 1365 10 2731
Business Critical 4 32 2731 10 5461
Business Critical 8 64 5461 10 10923
Business Critical 16 128 10923 10 21845
Business Critical 32 256 21845 10 43691
Business Critical 48 384 32768 10 65536
Business Critical 64 504 43008 10 86016

Quando le connessioni superano il limite, è possibile che venga visualizzato l'errore seguente:

ERROR 1040 (08004): Too many connections (ERRORE 1040 (08004): numero eccessivo di connessioni)

Importante

Per un'esperienza ottimale, è consigliabile usare un pool di connessioni come ProxySQL per gestire in modo efficiente le connessioni.

La creazione di nuove connessioni client a MySQL richiede tempo e una volta stabilite, queste connessioni occupano risorse del database, anche se inattive. La maggior parte delle applicazioni richiede molte connessioni di breve durata, che generano questa situazione. Di conseguenza sarà disponibile un minor numero di risorse per il carico di lavoro effettivo e le prestazioni saranno ridotte. Un pooler di connessioni che riduce le connessioni inattive e riutilizza le connessioni esistenti consente di evitare questo problema. Per informazioni sulla configurazione di ProxySQL, visitare il post di blog di Microsoft.

Nota

ProxySQL è uno strumento della community open source. È supportato da Microsoft su base ottimale. Per ottenere supporto per la produzione con indicazioni autorevoli, è possibile valutare e contattare il supporto del prodotto ProxySQL.

innodb_strict_mode

Se viene visualizzato un errore simile a "Dimensioni di riga troppo grandi (> 8126)", è possibile disattivare il parametro innodb_strict_mode. Il parametro del server innodb_strict_mode non può essere modificato a livello globale a livello di server perché se le dimensioni dei dati delle righe sono superiori a 8k, i dati vengono troncati senza errori, che possono causare potenziali perdite di dati. È consigliabile modificare lo schema in modo da adattare il limite di dimensioni della pagina.

Questo parametro può essere impostato a livello di sessione usando init_connect. Per impostare innodb_strict_mode a livello di sessione, fare riferimento all'impostazione del parametro non elencato.

Nota

Se si dispone di un server di replica in lettura, l'impostazione di innodb_strict_mode su OFF a livello di sessione in un server di origine interromperà la replica. Se sono presenti repliche di lettura, è consigliabile mantenere il parametro impostato su ON.

time_zone

Durante la distribuzione iniziale, un'istanza del server flessibile Database di Azure per MySQL include tabelle di sistema per informazioni sul fuso orario, ma queste tabelle non vengono popolate. Per popolare le tabelle di fuso orario, è possibile chiamare la stored procedure mysql.az_load_timezone da uno strumento come la riga di comando di MySQL o MySQL Workbench. Fare riferimento agli articoli sul portale di Azure o l'interfaccia della riga di comando di Azure per le modalità in cui è possibile chiamare la stored procedure e impostare i fusi orari a livello globale o di sessione.

binlog_expire_logs_seconds

In Database di Azure per MySQL server flessibile questo parametro specifica il numero di secondi di attesa del servizio prima di eliminare il file di log binario.

Il log binario contiene "eventi" che descrivono le modifiche del database, ad esempio le operazioni di creazione di tabelle o le modifiche apportate ai dati della tabella. Contiene anche eventi per le istruzioni che potenzialmente potrebbero aver apportato modifiche. Il log binario viene usato principalmente per due scopi, le operazioni di replica e ripristino dei dati. In genere, i log binari vengono eliminati non appena l'handle è libero dal servizio, dal backup o dal set di repliche. Se sono presenti più repliche, i log binari attendono che la replica più lenta legga le modifiche prima dell'eliminazione. Se si desidera rendere persistenti i log binari per un periodo di tempo maggiore, è possibile configurare il parametro binlog_expire_logs_seconds. Se il binlog_expire_logs_seconds è impostato su 0, ovvero il valore predefinito, elimina non appena viene liberato l'handle nel log binario. Se binlog_expire_logs_seconds > 0, attenderà fino ai secondi configurati prima di eliminare. Per Database di Azure per MySQL server flessibile, le funzionalità gestite come il backup e l'eliminazione delle repliche in lettura dei file binari vengono gestite internamente. Quando si esegue la replica dei dati da Database di Azure per MySQL server flessibile, questo parametro deve essere impostato in primario per evitare l'eliminazione dei log binari prima che la replica legga dalle modifiche dal database primario. Se si imposta il binlog_expire_logs_seconds su un valore superiore, i log binari non verranno eliminati abbastanza presto e potrebbero comportare un aumento della fatturazione dell'archiviazione.

event_scheduler

In Database di Azure per MySQL server flessibile, il event_schedule parametro server gestisce la creazione, la pianificazione e l'esecuzione di eventi, ovvero le attività eseguite in base a una pianificazione e vengono eseguite da un thread speciale dell'utilità di pianificazione eventi. Quando il event_scheduler parametro è impostato su ON, il thread dell'utilità di pianificazione eventi viene elencato come processo daemon nell'output di SHOW PROCESSLIST. È possibile creare e pianificare eventi usando la sintassi SQL seguente:

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

Nota

Per altre informazioni sulla creazione di un evento, vedere la documentazione dell'Utilità di pianificazione eventi MySQL qui:

Configurazione del parametro del server event_scheduler

Lo scenario seguente illustra un modo per usare il event_scheduler parametro in Database di Azure per MySQL server flessibile. Per illustrare lo scenario, si consideri l'esempio seguente, una tabella semplice:

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)

Per configurare il parametro del event_scheduler server in Database di Azure per MySQL server flessibile, seguire questa procedura:

  1. Nella portale di Azure passare all'istanza del server flessibile Database di Azure per MySQL e quindi in Impostazioni selezionare Parametri server.

  2. Nel pannello Parametri del server cercare event_scheduler, nell'elenco a discesa VALORE selezionare ON e quindi selezionare Salva.

    Nota

    La modifica della configurazione dei parametri del server dinamico verrà distribuita senza riavviare.

  3. Quindi per creare un evento, connettersi all'istanza del server flessibile Database di Azure per MySQL ed eseguire il comando SQL seguente:

    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. Per visualizzare i dettagli dell'utilità di pianificazione eventi, eseguire l'istruzione SQL seguente:

    SHOW EVENTS;

    Viene visualizzato l'output seguente:

    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. Dopo alcuni minuti, eseguire una query sulle righe dalla tabella per iniziare a visualizzare le righe inserite ogni minuto in base al event_scheduler parametro configurato:

    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. Dopo un'ora, eseguire un'istruzione Select nella tabella per visualizzare il risultato completo dei valori inseriti nella tabella ogni minuto per un'ora, perché in questo caso viene configurato .event_scheduler

    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)

Altri scenari

È possibile configurare un evento in base ai requisiti dello scenario specifico. Di seguito sono riportati alcuni esempi simili di pianificazione delle istruzioni SQL da eseguire a intervalli di tempo diversi.

Eseguire un'istruzione SQL ora e ripetere una volta al giorno senza fine

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

Eseguire un'istruzione SQL ogni ora senza fine

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

Eseguire un'istruzione SQL ogni giorno senza fine

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

Limiti

Per i server con disponibilità elevata configurata, quando si verifica il failover, è possibile che il parametro del event_scheduler server sia impostato su "OFF". In questo caso, al termine del failover, configurare il parametro per impostare il valore su 'ON'.

Parametri del server non modificabili

Il pannello dei parametri del server nel portale di Azure mostra sia i parametri modificabili che non modificabili del server. I parametri del server non modificabili sono disattivati. Per configurare un parametro server non modificabile a livello di sessione, vedere l'articolo portale di Azure o l'interfaccia della riga di comando di Azure per impostare il parametro a livello di connessione usando init_connect.

Passaggi successivi