Condividi tramite

Parametri del server in 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 i parametri del server?

Il motore MySQL fornisce molti parametri server (chiamati anche variabili) che è possibile usare per configurare e ottimizzare il comportamento del motore. È possibile impostare alcuni parametri in modo dinamico durante il runtime. Altri sono statici e richiedono un riavvio del server dopo averli impostati.

In Database di Azure per MySQL - Server flessibile è possibile modificare il valore di vari parametri del server MySQL usando Configurare parametri del server in Database di Azure per MySQL - Server flessibile tramite il portale di Azure e Configurare i parametri del server in Database di Azure per MySQL - Server flessibile tramite l'interfaccia della riga di comando di Azure per soddisfare le esigenze del carico di lavoro.

Elenco di parametri del server configurabili

È possibile gestire la configurazione di Database di Azure per MySQL - Server flessibile mediante i parametri del server. I parametri del server vengono configurati con i valori predefiniti e consigliati in fase di creazione del server. Il riquadro Parametri del server nel portale di Azure mostra sia i parametri modificabili che quelli non modificabili. I parametri del server non modificabili non sono disponibili.

L'elenco di parametri del server supportati è in continua crescita. È possibile usare il portale di Azure per visualizzare periodicamente l'elenco completo dei parametri del server e configurare i valori.

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 (tramite strumenti come i modelli di Azure Resource Manager, Terraform o l'interfaccia della riga di comando di Azure), lo script deve avere un provisioning per riavviare il servizio per rendere effettive le impostazioni, anche se si modifica la configurazione come parte dell'esperienza di creazione.

Se si vuole modificare un parametro del server non modificabile per l'ambiente in uso, pubblicare un'idea tramite il feedback della community o votare se il feedback esiste già (il che può essere utile per definire la priorità).

Le sezioni seguenti descrivono i limiti dei parametri del server comunemente aggiornati. Il livello di calcolo e le dimensioni (vCore) del server determinano i limiti.

lower_case_table_names

Per MySQL versione 5.7, il valore predefinito di lower_case_table_names è 1 in Database di Azure per MySQL - Server flessibile. Anche se è possibile modificare il valore supportato in 2, il ripristino da 2 a 1 non è consentito. Per assistenza nella modifica del valore predefinito, creare un ticket di supporto.

Per MySQL versione 8.0+ è possibile configurare lower_case_table_names solo quando si inizializza il server. Altre informazioni. La modifica dell'impostazione lower_case_table_names dopo l'inizializzazione del server non è consentita.

I valori supportati per MySQL versione 8.0 sono 1 e 2 in Database di Azure per MySQL - Server flessibile. Il valore predefinito è 1. Per assistenza nella modifica del valore predefinito durante la creazione del server, creare un ticket di supporto.

innodb_tmpdir

Si utilizza il parametro innodb_tmpdir in Database di Azure per MySQL - Server flessibile per definire la directory per i file di ordinamento temporanei creati durante le operazioni di ricompilazione di ALTER TABLE online.

Il valore predefinito di innodb_tmpdir è /mnt/temp. Questo percorso corrisponde all'archiviazione temporanea (SSD) ed è disponibile in gibibyte (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. Questa impostazione utilizza la capacità di archiviazione disponibile in Database di Azure per MySQL - Server flessibile. Questa impostazione può essere utile per operazioni di dimensioni maggiori che richiedono più spazio di archiviazione temporaneo.

Tenere presente che l'uso di /app/work/tmpdir comporta prestazioni più lente rispetto al valore predefinito dell'archiviazione temporanea (SSD)/mnt/temp. Effettuare la scelta 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 dove:

  • Il valore predefinito /mnt/temp è comune.
  • La directory alternativa /app/work/tmpdir è disponibile per la configurazione di un'archiviazione temporanea aumentata, con un compromesso nelle prestazioni 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). Il parametro log_bin_trust_function_creators è impostato su ON per impostazione predefinita nei server flessibili.

Il formato di registrazione binaria è sempre ROW e 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 che log_bin_trust_function_creators rimanga ON.

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 la registrazione binaria è abilitata (si potrebbe voler usare la variabile log_bin_trust_function_creators meno sicura )".

innodb_buffer_pool_size

Per informazioni sul parametro innodb_buffer_pool_size, vedere la documentazione di MySQL.

Le dimensioni della memoria fisica nella tabella seguente rappresentano la memoria ad accesso casuale (RAM) disponibile, espressa in gigabyte (GB), in Database di Azure per MySQL - Server flessibile.

Dimensioni di calcolo vCore Dimensioni della memoria fisica (GB) Valore predefinito (byte) Valore minimo (byte) Valore massimo (byte)
Possibilità di burst
Standard_B1s 1 1 134217728 33554432 268435456
Standard_B1ms 1 2 536870912 134217728 1073741824
Standard_B2s 2 4 2147483648 134217728 2147483648
Standard_B2ms 2 8 4294967296 134217728 5368709120
Standard_B4ms 4 16 12884901888 134217728 12884901888
Standard_B8ms 8 32 25769803776 134217728 25769803776
Standard_B12ms 12 48 51539607552 134217728 32212254720
Standard_B16ms 16 64 2147483648 134217728 51539607552
Standard_B20ms 20 80 64424509440 134217728 64424509440
Utilizzo generico
Standard_D2ads_v5 2 8 4294967296 134217728 5368709120
Standard_D2ds_v4 2 8 4294967296 134217728 5368709120
Standard_D4ads_v5 4 16 12884901888 134217728 12884901888
Standard_D4ds_v4 4 16 12884901888 134217728 12884901888
Standard_D8ads_v5 8 32 25769803776 134217728 25769803776
Standard_D8ds_v4 8 32 25769803776 134217728 25769803776
Standard_D16ads_v5 16 64 51539607552 134217728 51539607552
Standard_D16ds_v4 16 64 51539607552 134217728 51539607552
Standard_D32ads_v5 32 128 103079215104 134217728 103079215104
Standard_D32ds_v4 32 128 103079215104 134217728 103079215104
Standard_D48ads_v5 48 192 154618822656 134217728 154618822656
Standard_D48ds_v4 48 192 154618822656 134217728 154618822656
Standard_D64ads_v5 64 256 206158430208 134217728 206158430208
Standard_D64ds_v4 64 256 206158430208 134217728 206158430208
Business Critical
Standard_E2ds_v4 2 16 12884901888 134217728 12884901888
Standard_E2ads_v5, Standard_E2ds_v5 2 16 12884901888 134217728 12884901888
Standard_E4ds_v4 4 32 25769803776 134217728 25769803776
Standard_E4ads_v5, Standard_E4ds_v5 4 32 25769803776 134217728 25769803776
Standard_E8ds_v4 8 64 51539607552 134217728 51539607552
Standard_E8ads_v5, Standard_E8ds_v5 8 64 51539607552 134217728 51539607552
Standard_E16ds_v4 16 128 103079215104 134217728 103079215104
Standard_E16ads_v5, Standard_E16ds_v5 16 128 103079215104 134217728 103079215104
Standard_E20ds_v4 20 160 128849018880 134217728 128849018880
Standard_E20ads_v5, Standard_E20ds_v5 20 160 128849018880 134217728 128849018880
Standard_E32ds_v4 32 256 206158430208 134217728 206158430208
Standard_E32ads_v5, Standard_E32ds_v5 32 256 206158430208 134217728 206158430208
Standard_E48ds_v4 48 384 309237645312 134217728 309237645312
Standard_E48ads_v5, Standard_E48ds_v5 48 384 309237645312 134217728 309237645312
Standard_E64ds_v4 64 504 405874409472 134217728 405874409472
Standard_E64ads_v5 , Standard_E64ds_v5 64 512 412316860416 134217728 412316860416
Standard_E80ids_v4 80 504 405874409472 134217728 405874409472
Standard_E96ds_v5 96 672 541165879296 134217728 541165879296

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. Il parametro del server innodb_file_per_table controlla questo comportamento.

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 al massimo 8 terabyte (TB) in un unico file di dati. Se le dimensioni del database sono maggiori di 8 TB, è necessario creare la tabella nello spazio di tabella innodb_file_per_table. Se si dispone di una singola tabella di dimensioni superiori a 8 TB, è necessario usare la tabella di partizione.

innodb_log_file_size

Il valore di 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 ha lo svantaggio che il tempo di ripristino dopo un arresto anomalo è elevato. È necessario bilanciare il tempo di ripristino, nel raro caso di un arresto anomalo del sistema rispetto alla massima velocità effettiva durante le operazioni di picco. Una dimensione del file di log più grande può comportare tempi di riavvio più lunghi.

È possibile configurare innodb_log_size su 256 megabyte (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 dal valore predefinito, verificare se il valore di show global status like 'innodb_buffer_pool_pages_dirty' rimane 0 per 30 secondi per evitare il ritardo del riavvio.

connessioni_massime

Le dimensioni della memoria del server determinano il valore di max_connections. Le dimensioni della memoria fisica nella tabella seguente rappresentano la RAM disponibile, espressa in gigabyte, in Database di Azure per MySQL - Server flessibile.

Dimensioni di calcolo vCore Dimensioni della memoria fisica (GB) Valore predefinito Valore minimo Valore massimo
Possibilità di burst
Standard_B1s 1 1 85 10 171
Standard_B1ms 1 2 171 10 341
Standard_B2s 2 4 341 10 683
Standard_B2ms 2 4 683 10 1365
Standard_B4ms 4 16 1365 10 2731
Standard_B8ms 8 32 2731 10 5461
Standard_B12ms 12 48 4097 10 8193
Standard_B16ms 16 64 5461 10 10923
Standard_B20ms 20 80 6827 10 13653
Utilizzo generico
Standard_D2ads_v5 2 8 683 10 1365
Standard_D2ds_v4 2 8 683 10 1365
Standard_D4ads_v5 4 16 1365 10 2731
Standard_D4ds_v4 4 16 1365 10 2731
Standard_D8ads_v5 8 32 2731 10 5461
Standard_D8ds_v4 8 32 2731 10 5461
Standard_D16ads_v5 16 64 5461 10 10923
Standard_D16ds_v4 16 64 5461 10 10923
Standard_D32ads_v5 32 128 10923 10 21845
Standard_D32ds_v4 32 128 10923 10 21845
Standard_D48ads_v5 48 192 16384 10 32768
Standard_D48ds_v4 48 192 16384 10 32768
Standard_D64ads_v5 64 256 21845 10 43691
Standard_D64ds_v4 64 256 21845 10 43691
Business Critical
Standard_E2ds_v4 2 16 1365 10 2731
Standard_E2ads_v5, Standard_E2ds_v5 2 16 1365 10 2731
Standard_E4ds_v4 4 32 2731 10 5461
Standard_E4ads_v5, Standard_E4ds_v5 4 32 2731 10 5461
Standard_E8ds_v4 8 64 5461 10 10923
Standard_E8ads_v5, Standard_E8ds_v5 8 64 5461 10 10923
Standard_E16ds_v4 16 128 10923 10 21845
Standard_E16ads_v5, Standard_E16ds_v5 16 128 10923 10 21845
Standard_E20ds_v4 20 160 13653 10 27306
Standard_E20ads_v5, Standard_E20ds_v5 20 160 13653 10 27306
Standard_E32ds_v4 32 256 21845 10 43691
Standard_E32ads_v5, Standard_E32ds_v5 32 256 21845 10 43691
Standard_E48ds_v4 48 384 32768 10 65536
Standard_E48ads_v5, Standard_E48ds_v5 48 384 32768 10 65536
Standard_E64ds_v4 64 504 43008 10 86016
Standard_E64ads_v5, Standard_E64ds_v5 64 512 43691 10 87383
Standard_E80ids_v4 80 504 43008 10 86016
Standard_E96ds_v5 96 672 50000 10 100000

Quando le connessioni superano il limite, è possibile che venga visualizzato l'errore seguente: "ERRORE 1040 (08004): Troppe connessioni".

La creazione di nuove connessioni client a MySQL richiede tempo. Una volta stabilite, queste connessioni occupano risorse di database, anche quando sono 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 pool di connessioni che riduce le connessioni inattive e riutilizza le connessioni esistenti consente di evitare tale problema. Per un'esperienza ottimale, è consigliabile usare un pool di connessioni come ProxySQL per gestire in modo efficiente le connessioni. Per informazioni sulla configurazione di ProxySQL, vedere questo post di blog.

Nota

ProxySQL è uno strumento della community open source. Microsoft lo supporta nel modo migliore. Per ottenere supporto per la produzione con indicazioni autorevoli, contattare l'Assistenza clienti del prodotto ProxySQL.

innodb_strict_mode

Se viene visualizzato un errore simile a "Dimensioni della riga troppo grandi (> 8126)," potrebbe essere necessario disattivare il parametro del server innodb_strict_mode. Questo parametro non può essere modificato globalmente a livello di server perché se le dimensioni dei dati delle righe sono maggiori di 8K, i dati vengono troncati senza errori. Questo troncamento può causare una potenziale perdita di dati. È consigliabile modificare lo schema in modo da adattare il limite di dimensioni della pagina.

È possibile impostare questo parametro a livello di sessione usando init_connect. Per altre informazioni, vedere Impostazione di parametri server non modificabili.

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. È consigliabile mantenere il parametro impostato su ON se sono presenti repliche in lettura.

fuso orario

Durante la distribuzione iniziale, un'istanza di Database di Azure per MySQL - Server flessibile include tabelle di sistema per le informazioni sul fuso orario, ma queste non vengono popolate. È possibile popolare le tabelle di fuso orario chiamando la stored procedure mysql.az_load_timezone da uno strumento come la riga di comando di MySQL o MySQL Workbench. È anche possibile chiamare la stored procedure e impostare i fusi orari globali o a livello di sessione usando il portale di Azure o l'interfaccia della riga di comando di Azure.

binlog_expire_logs_seconds

In Database di Azure per MySQL - Server flessibile, il parametro binlog_expire_logs_seconds 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 avrebbero potuto apportare modifiche. Il log binario viene usato principalmente per due scopi, le operazioni di replica e di 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 di essere eliminate.

Se si desidera rendere persistenti i log binari per una durata più lunga, è possibile configurare il parametro binlog_expire_logs_seconds. Se binlog_expire_logs_seconds è impostato sul valore predefinito di 0, un log binario viene eliminato non appena l'handle viene liberato. Se il valore di binlog_expire_logs_seconds è maggiore di 0, il log binario viene eliminato dopo il numero di secondi configurato.

Database di Azure per MySQL - Server flessibile gestisce internamente funzionalità gestite come il backup e l'eliminazione delle repliche in lettura dei file binari. Quando si esegue la replica dei dati in Database di Azure per MySQL - Server flessibile, questo parametro deve essere impostato in primario per evitare di eliminare i log binari prima che la replica legga dalle modifiche nel primario. Se si imposta binlog_expire_logs_seconds su un valore superiore, i log binari non verranno eliminati abbastanza presto. Questo ritardo può causare un aumento della fatturazione dell'archiviazione.

pianificatore di eventi

In Database di Azure per MySQL - Server flessibile, il parametro del server event_scheduler gestisce la creazione, la pianificazione e l'esecuzione di eventi. Ciò significa, che il parametro gestisce le attività eseguite in base a una pianificazione da un thread speciale dell'Utilità di pianificazione eventi MySQL. Quando il parametro event_scheduler è impostato su ON, il thread dell'Utilità di pianificazione eventi viene elencato come processo daemon nell'output di SHOW PROCESSLIST.

Per i server MySQL versione 5.7, il parametro del server event_scheduler viene automaticamente disattivato quando viene avviato il backup e il parametro del server event_scheduler viene riattivato dopo il completamento del backup. In MySQL versione 8.0 per Database di Azure per MySQL - Server flessibile, il event_scheduler rimane invariato durante i backup. Per garantire operazioni più fluide, è consigliabile aggiornare i server MySQL 5.7 alla versione 8.0 usando un aggiornamento della versione principale.

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

Per altre informazioni sulla creazione di un evento, vedere la documentazione seguente sull'Utilità di pianificazione eventi nel manuale di riferimento di MySQL:

Configurare il parametro del server event_scheduler

Lo scenario seguente illustra un modo per usare il parametro event_scheduler in Database di Azure per MySQL - Server flessibile.

Per illustrare lo scenario, si consideri l'esempio seguente di 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) |
| ``` |
| 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>;

Per eseguire un'istruzione SQL ogni ora senza fine:

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

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

Limitazioni

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

innodb_ft_user_stopword_table

innodb_ft_user_stopword_table è un parametro del server in MySQL che specifica il nome della tabella contenente parole non significative personalizzate per la Ricerca full-text in InnoDB. La tabella deve trovarsi nello stesso database della tabella indicizzata full-text e la prima colonna deve essere di tipo VARCHAR. In Database di Azure per MySQL - Server flessibile, l'impostazione predefinita di sql_generate_invisible_primary_key=ON fa sì che tutte le tabelle senza una chiave primaria esplicita includano automaticamente una chiave primaria invisibile. Questo comportamento è in conflitto con i requisiti per innodb_ft_user_stopword_table, poiché la chiave primaria invisibile diventa la prima colonna della tabella, impedendone il funzionamento previsto durante la Ricerca full-text. Per risolvere questo problema, è necessario impostare sql_generate_invisible_primary_key=OFF nella stessa sessione prima di creare la tabella delle parole non significative personalizzate. Ad esempio:

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

In questo modo, la tabella delle parole non significative soddisfa i requisiti di MySQL e consente il corretto funzionamento delle parole non significative personalizzate.

Parametri del server non modificabili

Il riquadro Parametri del server nel portale di Azure mostra sia i parametri server modificabili che quelli non modificabili. I parametri del server non modificabili non sono disponibili. È possibile configurare un parametro server non modificabile a livello di sessione usando init_connect nel portale di Azure o nell'interfaccia della riga di comando di Azure.

Variabili di sistema di Azure mysql

azure_server_name

La variabile azure_server_name fornisce il nome esatto del server per l'istanza "Server Flessibile" di Database di Azure per MySQL. Questa variabile è utile quando le applicazioni o gli script devono recuperare a livello di codice il nome host del server a cui sono connessi, senza basarsi su configurazioni esterne e possono essere recuperati eseguendo il comando seguente all'interno di MySQL.

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

Nota: azure_server_name restituisce in modo coerente il nome del server originale usato per connettersi al servizio (ad esempio, myflex) sia per il server con disponibilità elevata abilitata sia per quello con disponibilità elevata disabilitata.

logical_server_name

La logical_server_name variabile rappresenta il nome host dell'istanza in cui è in esecuzione il server flessibile di Database di Azure per MySQL. Questa variabile è utile per identificare l'host in cui è attualmente in esecuzione il servizio, agevolando la risoluzione dei problemi e il monitoraggio del failover. È possibile recuperare questa variabile eseguendo il comando seguente all'interno di MySQL.

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

Nota: per un server abilitato per la disponibilità elevata, la logical_server_name variabile riflette il nome host dell'istanza che funge da server primario. Per un server in cui la disponibilità elevata è disabilitata, il valore di logical_server_name è uguale alla variabile azure_server_name poiché è presente una sola istanza.

Contenuti correlati