Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Riferimento Amazon Aurora MySQL Questo riferimento include informazioni sui parametri Aurora MySQL, le variabili di stato e le estensioni SQL generali o le differenze rispetto al motore del database MySQL della community. **Topics** + [Parametri di configurazione Aurora MySQL](AuroraMySQL.Reference.ParameterGroups.md) + [Variabili di stato globali di Aurora MySQL](AuroraMySQL.Reference.GlobalStatusVars.md) + [Eventi di attesa Aurora MySQL](AuroraMySQL.Reference.Waitevents.md) + [Stati del thread Aurora MySQL](AuroraMySQL.Reference.thread-states.md) + [Livelli di isolamento di Aurora MySQL](AuroraMySQL.Reference.IsolationLevels.md) + [Suggerimenti di Aurora MySQL](AuroraMySQL.Reference.Hints.md) + [Informazioni di riferimento sulle stored procedure Aurora MySQL](AuroraMySQL.Reference.StoredProcs.md) + [Tabelle information\$1schema specifiche di Aurora MySQL](AuroraMySQL.Reference.ISTables.md) # Parametri di configurazione Aurora MySQL La gestione del cluster di database di Amazon Aurora MySQL è uguale a quella di altre istanze database Amazon RDS, ovvero utilizza i parametri di un gruppo di parametri database. La differenza tra Amazon Aurora e gli altri motori di database consiste nel fatto che un cluster di database contiene più istanze database. Di conseguenza, alcuni dei parametri utilizzati per gestire il cluster di database Aurora MySQL si applicano all'intero cluster. Altri parametri si applicano solo a una particolare istanza database del cluster di database. Per gestire i parametri a livello di cluster, utilizza i gruppi di parametri del cluster di database. Per gestire i parametri a livello di istanza, utilizza i gruppi di parametri di database. Ogni istanza database in un cluster di database Aurora MySQL è compatibile con il motore del database MySQL. Tuttavia, si applicano alcuni dei parametri del motore del database MySQL a livello di cluster e si gestiscono questi parametri utilizzando i gruppi di parametri del cluster di DB. Non è possibile trovare parametri a livello di cluster nel gruppo di parametri DB per un'istanza in un cluster di database Aurora. Un elenco di parametri a livello di cluster è disponibile più avanti in questo argomento. È possibile gestire sia i parametri a livello di cluster che quelli a livello di istanza con la Console di gestione AWS, la AWS CLI o l'API di Amazon RDS. Sono disponibili comandi separati per la gestione dei parametri a livello di cluster e a livello di istanza. Ad esempio, puoi usare il comando CLI [modify-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html) per gestire i parametri a livello di cluster in un gruppo di parametri del cluster di database. È possibile usare il comando CLI [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) per gestire i parametri a livello di istanza in un gruppo di parametri DB per un'istanza database in un cluster di database. Puoi visualizzare i parametri a livello di cluster e quelli a livello di istanza nella console oppure tramite l'interfaccia CLI o l'API RDS. Ad esempio, puoi usare il comando AWS CLI [describe-db-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-parameters.html) per visualizzare i parametri a livello di cluster in un gruppo di parametri del cluster di database. È possibile usare il comando CLI [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) per visualizzare i parametri a livello di istanza in un gruppo di parametri DB per un'istanza database in un cluster di database. **Nota** Ogni [gruppo di parametri predefinito](USER_WorkingWithParamGroups.md) contiene i valori predefiniti per tutti i parametri del gruppo. Se il parametro ha come valore "engine default", consulta la documentazione MySQL o PostgreSQL specifica per la versione per il valore predefinito effettivo. Salvo diversa indicazione, i parametri elencati nelle tabelle seguenti sono validi per Aurora MySQL versione 2 e 3. Per ulteriori informazioni sui gruppi di parametri database, consulta [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md). Per regole e restrizioni per i cluster Aurora Serverless v1, consulta [Gruppi di parametri per Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.parameter-groups). **Topics** + [Parametri a livello di cluster](#AuroraMySQL.Reference.Parameters.Cluster) + [Parametri a livello di istanza](#AuroraMySQL.Reference.Parameters.Instance) + [I parametri MySQL seguenti non si applicano ad Aurora MySQL](#AuroraMySQL.Reference.Parameters.Inapplicable) ## Parametri a livello di cluster La tabella seguente mostra tutti i parametri che si applicano all'intero cluster di database Aurora MySQL. | Nome del parametro | Modificabili | Note | | --- | --- | --- | | `aurora_binlog_read_buffer_size` | Sì | Colpisce solo i cluster che utilizzano la replica binary log (binlog). Per informazioni sulla replica binlog, vedere [Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)](AuroraMySQL.Replication.MySQL.md). Rimosso da Aurora MySQL versione 3. | | `aurora_binlog_replication_max_yield_seconds` | Sì | Colpisce solo i cluster che utilizzano la replica binary log (binlog). Per informazioni sulla replica binlog, vedere [Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)](AuroraMySQL.Replication.MySQL.md). | | `aurora_binlog_replication_sec_index_parallel_workers` | Sì | Imposta il numero totale di thread paralleli disponibili per l’applicazione delle modifiche agli indici secondari durante la replica delle transazioni per tabelle di grandi dimensioni con più indici secondari. Per impostazione predefinita, il parametro è impostato su `0` (disabilitato). Questo parametro è disponibile in Aurora MySQL versione 306 e successive. Per ulteriori informazioni, consulta [Ottimizzazione della replica dei log binari per Aurora MySQL](binlog-optimization.md). | | `aurora_binlog_use_large_read_buffer` | Sì | Colpisce solo i cluster che utilizzano la replica binary log (binlog). Per informazioni sulla replica binlog, vedere [Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)](AuroraMySQL.Replication.MySQL.md). Rimosso da Aurora MySQL versione 3. | | `aurora_disable_hash_join` | Sì | Imposta questo parametro su `ON` per disabilitare l'ottimizzazione dell'hash join in Aurora MySQL versione 2.09 o successiva. Non è supportato per la versione 3. Per ulteriori informazioni, consulta [Query parallela per Amazon Aurora MySQL](aurora-mysql-parallel-query.md). | | `aurora_enable_replica_log_compression` | Sì | Per ulteriori informazioni, consulta [Considerazioni sulle prestazioni per la replica Amazon Aurora MySQL](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Performance). Non si applica ai cluster che fanno parte di un database globale Aurora. Rimosso da Aurora MySQL versione 3. | | `aurora_enable_repl_bin_log_filtering` | Sì | Per ulteriori informazioni, consulta [Considerazioni sulle prestazioni per la replica Amazon Aurora MySQL](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Performance). Non si applica ai cluster che fanno parte di un database globale Aurora. Rimosso da Aurora MySQL versione 3. | | `aurora_enable_staggered_replica_restart` | Sì | Questa impostazione è disponibile in Aurora MySQL versione 3, ma non viene utilizzata. | | `aurora_enable_zdr` | Sì | Questa impostazione è attivata per impostazione predefinita in Aurora MySQL 2.10 e versioni successive. | | `aurora_in_memory_relaylog` | Sì | Imposta la modalità di log di inoltro in memoria. È possibile utilizzare questa funzionalità sulle repliche binlog per migliorare le prestazioni di replica dei log binari. Per disattivare questa funzionalità, imposta il parametro su OFF. Per attivare questa funzionalità, imposta il parametro su ON. | | `aurora_enhanced_binlog` | Sì | Impostare il valore di questo parametro su 1 per attivare il file di log binario avanzato in Aurora MySQL versione 3.03.1 e successive. Per ulteriori informazioni, consulta [Configurazione del file di log binario avanzato per Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). | | `aurora_full_double_precision_in_json` | Sì | Imposta il valore di questo parametro per consentire l’analisi dei numeri in virgola mobile nei documenti JSON con la massima precisione. | | `aurora_jemalloc_background_thread` | Sì | Utilizza questo parametro per abilitare un thread in background per eseguire operazioni di manutenzione della memoria. I valori consentiti sono `0` (disabilitato) e `1` (abilitato). Il valore predefinito è `0`. Questo parametro si applica solo ad Aurora MySQL 3.05 e versioni successive. | | `aurora_jemalloc_dirty_decay_ms` | Sì | Utilizza questo parametro per conservare la memoria liberata per un determinato periodo di tempo (in millisecondi). La conservazione della memoria consente un riutilizzo più rapido. I valori consentiti sono `0`–`18446744073709551615`. Il valore predefinito è `10000` (10 secondi). È possibile utilizzare un ritardo più breve per evitare problemi di esaurimento della memoria, a scapito di prestazioni più lente. Questo parametro si applica solo ad Aurora MySQL 3.05 e versioni successive. | | `aurora_jemalloc_tcache_enabled` | Sì | Utilizza questo parametro per generare piccole richieste di memoria (fino a 32 KiB) in una cache locale del thread, bypassando le arene di memoria. I valori consentiti sono `0` (disabilitato) e `1` (abilitato). Il valore predefinito è `1`. Questo parametro si applica solo ad Aurora MySQL 3.05 e versioni successive. | | `aurora_load_from_s3_role` | Sì | Per ulteriori informazioni, consulta [Caricamento dei dati in un cluster DB Amazon Aurora MySQL da file di testo in un bucket Amazon S3](AuroraMySQL.Integrating.LoadFromS3.md). Attualmente non disponibile in Aurora MySQL versione 3. Utilizza `aws_default_s3_role`. | | `aurora_mask_password_hashes_type` | Sì | Questa impostazione è attivata per impostazione predefinita in Aurora MySQL 2.11 e versioni successive. Usa questa impostazione per mascherare gli hash delle password di Aurora MySQL nei log delle query lente e di audit. I valori consentiti sono `0` e `1` (impostazione predefinita). Se è impostata su `1`, le password vengono registrate come ``. Se è impostata su `0`, le password vengono registrate come valori hash (`#`). | | `aurora_select_into_s3_role` | Sì | Per ulteriori informazioni, consulta [Salvataggio dei dati da un cluster DB Amazon Aurora MySQL nei file di testo in un bucket Amazon S3](AuroraMySQL.Integrating.SaveIntoS3.md). Attualmente non disponibile in Aurora MySQL versione 3. Utilizza `aws_default_s3_role`. | | `authentication_kerberos_caseins_cmp` | Sì | Controlla il confronto dei nomi utente senza distinzione tra maiuscole e minuscole per il plugin `authentication_kerberos`. Impostalo su `true` per il confronto senza distinzione tra maiuscole e minuscole. Per impostazione predefinita, viene utilizzato il confronto con distinzione tra maiuscole e minuscole (`false`). Per ulteriori informazioni, consulta [Utilizzo dell'autenticazione Kerberos per Aurora MySQL](aurora-mysql-kerberos.md). Questo parametro è disponibile in Aurora MySQL versione 3.03 e versioni successive. | | `auto_increment_increment` | Sì | Nessuno | | `auto_increment_offset` | Sì | Nessuno | | `aws_default_lambda_role` | Sì | Per ulteriori informazioni, consulta [Chiamare una funzione Lambda da un cluster DB Amazon Aurora MySQL](AuroraMySQL.Integrating.Lambda.md). | | `aws_default_s3_role` | Sì | Viene utilizzato quando si richiama l'istruzione `LOAD DATA FROM S3`, `LOAD XML FROM S3` o `SELECT INTO OUTFILE S3` dal cluster DB. In Aurora MySQL versione 2, il ruolo IAM specificato in questo parametro viene utilizzato se un ruolo IAM non è specificato per `aurora_load_from_s3_role` o `aurora_select_into_s3_role` per l'istruzione appropriata. In Aurora MySQL versione 3, il ruolo IAM specificato per questo parametro è sempre utilizzato. Per ulteriori informazioni, consulta [Associazione di un ruolo IAM a un cluster DB Amazon Aurora MySQL](AuroraMySQL.Integrating.Authorizing.IAM.AddRoleToDBCluster.md). | | `binlog_backup` | Sì | Impostare il valore di questo parametro su 0 per attivare il file di log binario avanzato in Aurora MySQL versione 3.03.1 e successive. È possibile disattivare questo parametro solo in caso di utilizzo di un file di log binario avanzato. Per ulteriori informazioni, consulta [Configurazione del file di log binario avanzato per Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). | | `binlog_checksum` | Sì | La AWS CLI e l'API RDS segnalano un valore di `None` se questo parametro non è impostato. In tal caso, Aurora MySQL utilizza il valore predefinito del motore, ossia `CRC32`. Questo è diverso dall'impostazione esplicita di `NONE`, che disattiva il checksum. | | `binlog-do-db` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `binlog_format` | Sì | Per ulteriori informazioni, consulta [Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)](AuroraMySQL.Replication.MySQL.md). | | `binlog_group_commit_sync_delay` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `binlog_group_commit_sync_no_delay_count` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `binlog-ignore-db` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `binlog_replication_globaldb` | Sì | Impostare il valore di questo parametro su 0 per attivare il file di log binario avanzato in Aurora MySQL versione 3.03.1 e successive. È possibile disattivare questo parametro solo in caso di utilizzo di un file di log binario avanzato. Per ulteriori informazioni, consulta [Configurazione del file di log binario avanzato per Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). | | `binlog_row_image` | No | Nessuno | | `binlog_row_metadata` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `binlog_row_value_options` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `binlog_rows_query_log_events` | Sì | Nessuno | | `binlog_transaction_compression` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `binlog_transaction_compression_level_zstd` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `binlog_transaction_dependency_history_size` | Sì | Questo parametro imposta un limite massimo al numero di hash di riga che vengono conservati in memoria e utilizzati per cercare la transazione dell'ultima modifica di una determinata riga. Una volta raggiunto questo numero di hash, la cronologia viene rimossa. Questo parametro si applica ad Aurora MySQL versione 2.12 e successive e versione 3. | | `binlog_transaction_dependency_tracking` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `character-set-client-handshake` | Sì | Nessuno | | `character_set_client` | Sì | Nessuno | | `character_set_connection` | Sì | Nessuno | | `character_set_database` | Sì | Il set di caratteri utilizzato dal database predefinito. Il valore predefinito è `utf8mb4`. | | `character_set_filesystem` | Sì | Nessuno | | `character_set_results` | Sì | Nessuno | | `character_set_server` | Sì | Nessuno | | `collation_connection` | Sì | Nessuno | | `collation_server` | Sì | Nessuno | | `completion_type` | Sì | Nessuno | | `default_storage_engine` | No | I cluster Aurora MySQL utilizzano il motore di storage InnoDB per tutti i dati. | | `enforce_gtid_consistency` | A volte | Modificabile in Aurora MySQL versione 2 e successive. | | `event_scheduler` | Sì | Indica lo stato dell'utilità di pianificazione eventi. Modificabile solo a livello di cluster in Aurora MySQL versione 3. | | `gtid-mode` | A volte | Modificabile in Aurora MySQL versione 2 e successive. | | `information_schema_stats_expiry` | Sì | Il numero di secondi dopo il quale il server del database MySQL recupera i dati dal motore di archiviazione e sostituisce i dati nella cache. I valori consentiti sono `0`–`31536000`. Questo parametro si applica ad Aurora MySQL versione 3. | | `init_connect` | Sì | Il comando che deve essere eseguito dal server per ogni client che si connette. Utilizza le virgolette doppie (") per le impostazioni per evitare errori di connessione, ad esempio: 
SET optimizer_switch="hash_join=off"
In Aurora MySQL versione 3, questo parametro non si applica agli utenti che dispongono del privilegio `CONNECTION_ADMIN`, incluso l'utente master Aurora. Per ulteriori informazioni, consulta [Privilegio basato sui ruoli](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). | | `innodb_adaptive_hash_index` | Sì | È possibile modificare questo parametro a livello di cluster database in Aurora MySQL versioni 2 e 3. L'indice adattivo Hash non è supportato nelle istanze database di lettura. | | `innodb_aurora_instant_alter_column_allowed` | Sì | Controlla se l'algoritmo `INSTANT` può essere utilizzato per operazioni `ALTER COLUMN` a livello globale. I valori validi consentiti sono i seguenti: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Per ulteriori informazioni, consulta la pagina relativa alle [operazioni sulle colonne](https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html#online-ddl-column-operations) nella documentazione di MySQL. Questo parametro si applica solo ad Aurora MySQL 3.05 e versioni successive. | | `innodb_autoinc_lock_mode` | Sì | Nessuno | | `innodb_checksums` | No | Rimosso da Aurora MySQL versione 3. | | `innodb_cmp_per_index_enabled` | Sì | Nessuno | | `innodb_commit_concurrency` | Sì | Nessuno | | `innodb_data_home_dir` | No | Aurora MySQL utilizza istanze gestite in cui non si accede direttamente al filesystem. | | `innodb_deadlock_detect` | Sì | Questa opzione viene utilizzata per disabilitare il rilevamento del deadlock in Aurora MySQL versione 2.11 e successive e versione 3. Sui sistemi ad alta simultaneità, il rilevamento del deadlock può causare un rallentamento quando numerosi thread attendono lo stesso blocco. Per ulteriori informazioni su questo parametro, consulta la documentazione di MySQL. | | `innodb_default_row_format` | Sì | Questo parametro definisce il formato di riga predefinito per le tabelle InnoDB (incluse le tabelle temporanee InnoDB create dall'utente). Si applica ad Aurora MySQL versioni 2 e 3. Il valore può essere `DYNAMIC`, `COMPACT` o `REDUNDANT.` | | `innodb_file_per_table` | Sì | Questo parametro influisce sul modo in cui è organizzata l'archiviazione della tabella. Per ulteriori informazioni, consulta [Dimensionamento dello storage](Aurora.Managing.Performance.md#Aurora.Managing.Performance.StorageScaling). | | `innodb_flush_log_at_trx_commit` | Sì | È fortemente consigliato utilizzare il valore predefinito `1`. In Aurora MySQL versione 3, prima di poter impostare questo parametro su un valore diverso da `1`, è necessario impostare il valore di `innodb_trx_commit_allow_data_loss` su `1`. Per ulteriori informazioni, consulta [Configurazione della frequenza di svuotamento del buffer dei registri](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush). | | `innodb_ft_max_token_size` | Sì | Nessuno | | `innodb_ft_min_token_size` | Sì | Nessuno | | `innodb_ft_num_word_optimize` | Sì | Nessuno | | `innodb_ft_sort_pll_degree` | Sì | Nessuno | | `innodb_online_alter_log_max_size` | Sì | Nessuno | | `innodb_optimize_fulltext_only` | Sì | Nessuno | | `innodb_page_size` | No | Nessuno | | `innodb_print_all_deadlocks` | Sì | Quando è attivo, registra le informazioni su tutti i deadlock di InnoDB nel log degli errori di Aurora MySQL. Per ulteriori informazioni, consulta [Contenimento e risoluzione dei problemi di deadlock di Aurora MySQL](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks). | | `innodb_purge_batch_size` | Sì | Nessuno | | `innodb_purge_threads` | Sì | Nessuno | | `innodb_rollback_on_timeout` | Sì | Nessuno | | `innodb_rollback_segments` | Sì | Nessuno | | `innodb_spin_wait_delay` | Sì | Nessuno | | `innodb_strict_mode` | Sì | Nessuno | | `innodb_support_xa` | Sì | Rimosso da Aurora MySQL versione 3. | | `innodb_sync_array_size` | Sì | Nessuno | | `innodb_sync_spin_loops` | Sì | Nessuno | | `innodb_stats_include_delete_marked` | Sì | Quando questo parametro è abilitato, InnoDB include i record contrassegnati per l'eliminazione durante il calcolo delle statistiche di ottimizzazione persistenti. Questo parametro si applica ad Aurora MySQL versione 2.12 e successive e versione 3. | | `innodb_table_locks` | Sì | Nessuno | | `innodb_trx_commit_allow_data_loss` | Sì | In Aurora MySQL versione 3, imposta il valore di questo parametro su `1` in modo da poter modificare il valore di `innodb_flush_log_at_trx_commit`. Il valore predefinito di `innodb_trx_commit_allow_data_loss` è `0`. Per ulteriori informazioni, consulta [Configurazione della frequenza di svuotamento del buffer dei registri](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush). | | `innodb_undo_directory` | No | Aurora MySQL utilizza istanze gestite in cui non si accede direttamente al filesystem. | | `internal_tmp_disk_storage_engine` | Sì | Controlla quale motore di archiviazione in memoria viene utilizzato per le tabelle temporanee interne. I valori consentiti sono `INNODB` e `MYISAM`. Questo parametro si applica ad Aurora MySQL versione 2. | | `internal_tmp_mem_storage_engine` | Sì | Controlla quale motore di archiviazione in memoria viene utilizzato per le tabelle temporanee interne. I valori consentiti sono `MEMORY` e `TempTable`. Questo parametro si applica ad Aurora MySQL versione 3. | | `key_buffer_size` | Sì | Cache per chiave per tabelle MyISAM. Per ulteriori informazioni, consultare [keycache->cache\$1lock mutex](AuroraMySQL.Reference.Waitevents.md#key-cache.cache-lock). | | `lc_time_names` | Sì | Nessuno | | `log_error_suppression_list` | Sì | Specifica un elenco di codici di errore che non sono registrati nel log degli errori di MySQL. In questo modo è possibile ignorare determinate condizioni di errore non critiche per mantenere puliti i log degli errori. Per ulteriori informazioni, consulta la sezione relativa a [log\$1error\$1suppression\$1list](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list) nella documentazione di MySQL. Questo parametro si applica ad Aurora MySQL versione 3.03 e successive. | | `low_priority_updates` | Sì | Le operazioni `INSERT`, `UPDATE`, `DELETE` e `LOCK TABLE WRITE` attendono fino a quando non ci sono più operazioni `SELECT` in sospeso. Questo parametro ha effetto solo sui motori di archiviazione che utilizzano solo il blocco a livello di tabella (MyISAM, MEMORY, MERGE). Questo parametro si applica ad Aurora MySQL versione 3. | | `lower_case_table_names` | Sì (Aurora MySQL versione 2) Solo al momento della creazione del cluster (Aurora MySQL versione 3) | In Aurora MySQL versione 2.10 e successive 2.x, assicurati di riavviare tutte le istanze di lettura dopo aver modificato questa impostazione e riavviato l'istanza di scrittura. Per informazioni dettagliate, consultare [Riavvio di un cluster Aurora con disponibilità di lettura](aurora-mysql-survivable-replicas.md). In Aurora MySQL versione 3, il valore di questo parametro viene impostato in modo permanente al momento della creazione del cluster. Se si utilizza un valore non predefinito per questa opzione, impostare il gruppo di parametri personalizzati Aurora MySQL versione 3 prima dell'aggiornamento e specificare il gruppo di parametri durante l'operazione di ripristino dello snapshot che crea il cluster versione 3. Con un database globale Aurora basato su Aurora MySQL, non puoi eseguire un aggiornamento locale da Aurora MySQL versione 2 alla versione 3 se il parametro `lower_case_table_names` è attivato. Per ulteriori informazioni sui metodi disponibili all'uso, consulta [Aggiornamenti di una versione principale](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major). | | `master-info-repository` | Sì | Rimosso da Aurora MySQL versione 3. | | `master_verify_checksum` | Sì | Aurora MySQL versione 2. Utilizza `source_verify_checksum` in Aurora MySQL versione 3. | | `max_delayed_threads` | Sì | Imposta il numero massimo di thread per gestire le istruzioni `INSERT DELAYED`. Questo parametro si applica ad Aurora MySQL versione 3. | | `max_error_count` | Sì | Il numero massimo di messaggi di errore, avviso e note da archiviare per la visualizzazione. Questo parametro si applica ad Aurora MySQL versione 3. | | `max_execution_time` | Sì | Il timeout per l’esecuzione delle istruzioni `SELECT`, in millisecondi. I valori possono essere compresi tra `0` e `18446744073709551615`. Se il parametro è impostato su `0`, non è previsto alcun timeout. Per ulteriori informazioni, consulta la sezione dedicata a [max\$1execution\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_execution_time) nella documentazione di MySQL. | | `min_examined_row_limit` | Sì | Utilizza questo parametro per impedire la registrazione delle query che esaminano un numero di righe inferiore a quello specificato. | | `partial_revokes` | No | Questo parametro si applica ad Aurora MySQL versione 3. | | `preload_buffer_size` | Sì | La dimensione del buffer allocato durante il precaricamento degli indici. Questo parametro si applica ad Aurora MySQL versione 3. | | `query_cache_type` | Sì | Rimosso da Aurora MySQL versione 3. | | `read_only` | Sì | Quando questo parametro è attivato, il server non consente aggiornamenti tranne quelli eseguiti dai thread di replica. I valori validi per Aurora MySQL versione 2 sono i seguenti: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) I valori validi per Aurora MySQL versione 3 sono i seguenti: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) In Aurora MySQL versione 3, questo parametro non si applica agli utenti che dispongono del privilegio `CONNECTION_ADMIN`, incluso l'utente master Aurora. Per ulteriori informazioni, consulta [Privilegio basato sui ruoli](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). | | `relay-log-space-limit` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `replica_parallel_type` | Sì | Questo parametro consente l'esecuzione parallela sulla replica di tutti i thread di cui non è stato eseguito il commit già in fase di preparazione, senza violare la coerenza. Si applica ad Aurora MySQL versione 3. In Aurora MySQL versione 3.03.\$1 e versioni precedenti, il valore predefinito è DATABASE. In Aurora MySQL versione 3.04 e versioni successive, il valore predefinito è LOGICAL\$1CLOCK. | | `replica_preserve_commit_order` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `replica_transaction_retries` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `replica_type_conversions` | Sì | Questo parametro determina il tipo di conversione utilizzato nelle repliche. I valori consentiti sono `ALL_LOSSY`, `ALL_NON_LOSSY`, `ALL_SIGNED` e `ALL_UNSIGNED`. Per ulteriori informazioni, consulta l'argomento relativo alla [replica con definizioni di tabelle diverse per origine e replica](https://dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html) nella documentazione di MySQL. Questo parametro si applica ad Aurora MySQL versione 3. | | `replicate-do-db` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `replicate-do-table` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `replicate-ignore-db` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `replicate-ignore-table` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `replicate-wild-do-table` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `replicate-wild-ignore-table` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `require_secure_transport` | Sì | Questo parametro si applica ad Aurora MySQL versione 2 e 3. Per ulteriori informazioni, consulta [Connessioni TLS a cluster di database Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL). | | `rpl_read_size` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `server_audit_cw_upload` | No | Questo parametro è obsoleto in Aurora MySQL. Utilizza `server_audit_logs_upload`. Per ulteriori informazioni, consulta [Pubblicazione di log Amazon Aurora MySQL in Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). | | `server_audit_events` | Sì | Per ulteriori informazioni, consulta [Utilizzo dell'audit avanzato con un cluster di database Amazon Aurora MySQL](AuroraMySQL.Auditing.md). | | `server_audit_excl_users` | Sì | Per ulteriori informazioni, consulta [Utilizzo dell'audit avanzato con un cluster di database Amazon Aurora MySQL](AuroraMySQL.Auditing.md). | | `server_audit_incl_users` | Sì | Per ulteriori informazioni, consulta [Utilizzo dell'audit avanzato con un cluster di database Amazon Aurora MySQL](AuroraMySQL.Auditing.md). | | `server_audit_logging` | Sì | Per istruzioni sul caricamento dei log su Amazon CloudWatch Logs, consulta [Pubblicazione di log Amazon Aurora MySQL in Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). | | `server_audit_logs_upload` | Sì | È possibile pubblicare i log di audit su CloudWatch Logs abilitando l’auditing avanzato e impostando questo parametro su `1`. Il valore predefinito per il parametro `server_audit_logs_upload` è `0`. Per ulteriori informazioni, consulta [Pubblicazione di log Amazon Aurora MySQL in Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). | | `server_id` | No | Nessuno | | `skip-character-set-client-handshake` | Sì | Nessuno | | `skip_name_resolve` | No | Nessuno | | `slave-skip-errors` | Sì | Si applica solo ai cluster Aurora MySQL versione 2, con compatibilità MySQL 5.7. | | `source_verify_checksum` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `sync_frm` | Sì | Rimosso da Aurora MySQL versione 3. | | `thread_cache_size` | Sì | Il numero di thread da memorizzare nella cache. Questo parametro si applica ad Aurora MySQL versioni 2 e 3. | | `time_zone` | Sì | Per impostazione predefinita, il fuso orario di un cluster di database Aurora è in formato UTC (Universal Time Coordinated). Tuttavia, puoi impostare il fuso orario delle istanze del cluster DB sul fuso orario locale dell'applicazione. Per ulteriori informazioni, consulta [Fuso orario locale per i cluster DB Amazon Aurora](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.LocalTimeZone). | | `tls_version` | Sì | Per ulteriori informazioni, consulta [Versioni TLS per Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL.TLS_Version). | ## Parametri a livello di istanza La tabella seguente mostra tutti i parametri che si applicano a una specifica istanza database di un cluster di database Aurora MySQL. | Nome del parametro | Modificabili | Note | | --- | --- | --- | | `activate_all_roles_on_login` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `allow-suspicious-udfs` | No | Nessuno | | `aurora_disable_hash_join` | Sì | Imposta questo parametro su `ON` per disabilitare l'ottimizzazione dell'hash join in Aurora MySQL versione 2.09 o successiva. Non è supportato per la versione 3. Per ulteriori informazioni, consulta [Query parallela per Amazon Aurora MySQL](aurora-mysql-parallel-query.md). | | `aurora_lab_mode` | Sì | Per ulteriori informazioni, consulta [Modalità di laboratorio per Amazon Aurora MySQL](AuroraMySQL.Updates.LabMode.md). Rimosso da Aurora MySQL versione 3. | | `aurora_oom_response` | Sì | Questo parametro è supportato per Aurora MySQL versione 2 e 3. Per ulteriori informazioni, consulta [Risoluzione dei problemi di memoria insufficiente per i database Aurora MySQL](AuroraMySQLOOM.md). | | `aurora_parallel_query` | Sì | Imposta su `ON` per abilitare la query parallela in Aurora MySQL versione 2.09 o successive. Il vecchio parametro `aurora_pq` non viene utilizzato in queste versioni. Per ulteriori informazioni, consulta [Query parallela per Amazon Aurora MySQL](aurora-mysql-parallel-query.md). | | `aurora_pq` | Sì | Imposta su `OFF` per disattivare la query parallela per istanze database specifiche nelle versioni di Aurora MySQL precedenti alla 2.09. Nella versione 2.09 o successive, attiva e disattiva la query parallela con `aurora_parallel_query`. Per ulteriori informazioni, consulta [Query parallela per Amazon Aurora MySQL](aurora-mysql-parallel-query.md). | | `aurora_read_replica_read_committed` | Sì | Abilita il livello di isolamento `READ COMMITTED` per le repliche Aurora e modifica il comportamento di isolamento per ridurre il ritardo di rimozione durante le query a esecuzione prolungata. Abilita questa impostazione solo sei informato sulle modifiche al comportamento e su come influiscono sui risultati della query. Ad esempio, questa impostazione utilizza un isolamento meno rigoroso rispetto all'impostazione predefinita di MySQL. Quando è abilitata, le query a esecuzione prolungata potrebbero visualizzare più di una copia della stessa riga perché Aurora riorganizza i dati della tabella mentre la query è in esecuzione. Per ulteriori informazioni, consulta [Livelli di isolamento di Aurora MySQL](AuroraMySQL.Reference.IsolationLevels.md). | | `aurora_tmptable_enable_per_table_limit` | Sì | Determina se il parametro `tmp_table_size` controlla le dimensioni massime delle tabelle temporanee in memoria create dal motore di storage `TempTable` in Aurora MySQL versione 3.04 e successive. Per ulteriori informazioni, consulta [Limitazione delle dimensioni delle tabelle temporanee interne in memoria](ams3-temptable-behavior.md#ams3-temptable-behavior-limit). | | `aurora_use_vector_instructions` | Sì | Quando questo parametro è abilitato, Aurora MySQL utilizza istruzioni di elaborazione vettoriale ottimizzate fornite dalle moderne CPU per migliorare le prestazioni sui carichi di lavoro che fanno un uso intensivo di I/O. Questa impostazione è abilitata per impostazione predefinita in Aurora MySQL 3.05 e versioni successive. | | `autocommit` | Sì | Nessuno | | `automatic_sp_privileges` | Sì | Nessuno | | `back_log` | Sì | Nessuno | | `basedir` | No | Aurora MySQL utilizza istanze gestite in cui non si accede direttamente al filesystem. | | `binlog_cache_size` | Sì | Nessuno | | `binlog_max_flush_queue_time` | Sì | Nessuno | | `binlog_order_commits` | Sì | Nessuno | | `binlog_stmt_cache_size` | Sì | Nessuno | | `binlog_transaction_compression` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `binlog_transaction_compression_level_zstd` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `bulk_insert_buffer_size` | Sì | Nessuno | | `concurrent_insert` | Sì | Nessuno | | `connect_timeout` | Sì | Nessuno | | `core-file` | No | Aurora MySQL utilizza istanze gestite in cui non si accede direttamente al filesystem. | | `datadir` | No | Aurora MySQL utilizza istanze gestite in cui non si accede direttamente al filesystem. | | `default_authentication_plugin` | No | Questo parametro si applica ad Aurora MySQL versione 3. | | `default_time_zone` | No | Nessuno | | `default_tmp_storage_engine` | Sì | Il motore di archiviazione predefinito per le tabelle temporanee. | | `default_week_format` | Sì | Nessuno | | `delay_key_write` | Sì | Nessuno | | `delayed_insert_limit` | Sì | Nessuno | | `delayed_insert_timeout` | Sì | Nessuno | | `delayed_queue_size` | Sì | Nessuno | | `div_precision_increment` | Sì | Nessuno | | `end_markers_in_json` | Sì | Nessuno | | `eq_range_index_dive_limit` | Sì | Nessuno | | `event_scheduler` | A volte | Indica lo stato dell'utilità di pianificazione eventi. Modificabile solo a livello di cluster in Aurora MySQL versione 3. | | `explicit_defaults_for_timestamp` | Sì | Nessuno | | `flush` | No | Nessuno | | `flush_time` | Sì | Nessuno | | `ft_boolean_syntax` | No | Nessuno | | `ft_max_word_len` | Sì | Nessuno | | `ft_min_word_len` | Sì | Nessuno | | `ft_query_expansion_limit` | Sì | Nessuno | | `ft_stopword_file` | Sì | Nessuno | | `general_log` | Sì | Per istruzioni sul caricamento dei log su CloudWatch Logs, consulta [Pubblicazione di log Amazon Aurora MySQL in Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). | | `general_log_file` | No | Aurora MySQL utilizza istanze gestite in cui non si accede direttamente al filesystem. | | `group_concat_max_len` | Sì | Nessuno | | `host_cache_size` | Sì | Nessuno | | `init_connect` | Sì | Il comando che deve essere eseguito dal server per ogni client che si connette. Utilizza le virgolette doppie (") per le impostazioni per evitare errori di connessione, ad esempio: 
SET optimizer_switch="hash_join=off"
In Aurora MySQL versione 3, questo parametro non si applica agli utenti che dispongono del privilegio `CONNECTION_ADMIN`, incluso l'utente master di Aurora. Per ulteriori informazioni, consulta [Privilegio basato sui ruoli](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). | | `innodb_adaptive_hash_index` | Sì | È possibile modificare questo parametro a livello di istanza database in Aurora MySQL versione 2. È modificabile solo a livello di cluster database in Aurora MySQL versione 3. L'indice adattivo Hash non è supportato nelle istanze database di lettura. | | `innodb_adaptive_max_sleep_delay` | Sì | La modifica di questo parametro non ha alcun effetto, perché `innodb_thread_concurrency` è sempre 0 per Aurora. | | `innodb_aurora_max_partitions_for_range` | Sì | In alcuni casi in cui le statistiche persistenti non sono disponibili, è possibile utilizzare questo parametro per migliorare le prestazioni delle stime del numero di righe sulle tabelle partizionate. È possibile impostarlo su un valore compreso tra 0 e 8192, ovvero il valore determina il numero di partizioni da controllare durante la stima del numero di righe. Il valore predefinito è 0, che stima l'utilizzo di tutte le partizioni, coerente con il comportamento predefinito di MySQL. Questo parametro è disponibile per Aurora MySQL versione 3.03.1 e versioni successive. | | `innodb_autoextend_increment` | Sì | Nessuno | | `innodb_buffer_pool_dump_at_shutdown` | No | Nessuno | | `innodb_buffer_pool_dump_now` | No | Nessuno | | `innodb_buffer_pool_filename` | No | Nessuno | | `innodb_buffer_pool_load_abort` | No | Nessuno | | `innodb_buffer_pool_load_at_startup` | No | Nessuno | | `innodb_buffer_pool_load_now` | No | Nessuno | | `innodb_buffer_pool_size` | Sì | Il valore predefinito è rappresentato da una formula. Per informazioni dettagliate su come viene calcolato il valore `DBInstanceClassMemory` nella formula, vedi [Variabili di formula dei parametri database](USER_ParamValuesRef.md#USER_FormulaVariables). | | `innodb_change_buffer_max_size` | No | Aurora MySQL non utilizza affatto il buffer di modifica InnoDB. | | `innodb_compression_failure_threshold_pct` | Sì | Nessuno | | `innodb_compression_level` | Sì | Nessuno | | `innodb_compression_pad_pct_max` | Sì | Nessuno | | `innodb_concurrency_tickets` | Sì | La modifica di questo parametro non ha alcun effetto, perché `innodb_thread_concurrency` è sempre 0 per Aurora. | | `innodb_deadlock_detect` | Sì | Questa opzione viene utilizzata per disabilitare il rilevamento del deadlock in Aurora MySQL versione 2.11 e successive e versione 3. Sui sistemi ad alta simultaneità, il rilevamento del deadlock può causare un rallentamento quando numerosi thread attendono lo stesso blocco. Per ulteriori informazioni su questo parametro, consulta la documentazione di MySQL. | | `innodb_file_format` | Sì | Rimosso da Aurora MySQL versione 3. | | `innodb_flushing_avg_loops` | No | Nessuno | | `innodb_force_load_corrupted` | No | Nessuno | | `innodb_ft_aux_table` | Sì | Nessuno | | `innodb_ft_cache_size` | Sì | Nessuno | | `innodb_ft_enable_stopword` | Sì | Nessuno | | `innodb_ft_server_stopword_table` | Sì | Nessuno | | `innodb_ft_user_stopword_table` | Sì | Nessuno | | `innodb_large_prefix` | Sì | Rimosso da Aurora MySQL versione 3. | | `innodb_lock_wait_timeout` | Sì | Nessuno | | `innodb_log_compressed_pages` | No | Nessuno | | `innodb_lru_scan_depth` | Sì | Nessuno | | `innodb_max_purge_lag` | Sì | Nessuno | | `innodb_max_purge_lag_delay` | Sì | Nessuno | | `innodb_monitor_disable` | Sì | Nessuno | | `innodb_monitor_enable` | Sì | Nessuno | | `innodb_monitor_reset` | Sì | Nessuno | | `innodb_monitor_reset_all` | Sì | Nessuno | | `innodb_old_blocks_pct` | Sì | Nessuno | | `innodb_old_blocks_time` | Sì | Nessuno | | `innodb_open_files` | Sì | Nessuno | | `innodb_print_all_deadlocks` | Sì | Quando è attivo, registra le informazioni su tutti i deadlock di InnoDB nel log degli errori di Aurora MySQL. Per ulteriori informazioni, consulta [Contenimento e risoluzione dei problemi di deadlock di Aurora MySQL](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks). | | `innodb_random_read_ahead` | Sì | Nessuno | | `innodb_read_ahead_threshold` | Sì | Nessuno | | `innodb_read_io_threads` | No | Nessuno | | `innodb_read_only` | No | Aurora MySQL gestisce lo stato di sola lettura e lo stato di lettura/scrittura delle istanze database in base al tipo di cluster. Ad esempio, un cluster in provisioning ha un'istanza database di lettura/scrittura (l'*istanza primaria*) e tutte le altre istanze nel cluster sono di sola lettura (le repliche Aurora). | | `innodb_replication_delay` | Sì | Nessuno | | `innodb_sort_buffer_size` | Sì | Nessuno | | `innodb_stats_auto_recalc` | Sì | Nessuno | | `innodb_stats_method` | Sì | Nessuno | | `innodb_stats_on_metadata` | Sì | Nessuno | | `innodb_stats_persistent` | Sì | Nessuno | | `innodb_stats_persistent_sample_pages` | Sì | Nessuno | | `innodb_stats_transient_sample_pages` | Sì | Nessuno | | `innodb_thread_concurrency` | No | Nessuno | | `innodb_thread_sleep_delay` | Sì | La modifica di questo parametro non ha alcun effetto, perché `innodb_thread_concurrency` è sempre 0 per Aurora. | | `interactive_timeout` | Sì | Aurora valuta il valore minimo di `interactive_timeout` e `wait_timeout`. Quindi usa quel minimo come timeout per terminare tutte le sessioni inattive, sia interattive sia non interattive. | | `internal_tmp_disk_storage_engine` | Sì | Controlla quale motore di archiviazione in memoria viene utilizzato per le tabelle temporanee interne. I valori consentiti sono `INNODB` e `MYISAM`. Questo parametro si applica ad Aurora MySQL versione 2. | | `internal_tmp_mem_storage_engine` | A volte | Controlla quale motore di archiviazione in memoria viene utilizzato per le tabelle temporanee interne. I valori consentiti per le istanze database di scrittura sono `MEMORY` e `TempTable`. Per le istanze database di lettura questo parametro è impostato su `TempTable` e non può essere modificato. Questo parametro si applica ad Aurora MySQL versione 3. | | `join_buffer_size` | Sì | Nessuno | | `keep_files_on_create` | Sì | Nessuno | | `key_buffer_size` | Sì | Cache per chiave per tabelle MyISAM. Per ulteriori informazioni, consultare [keycache->cache\$1lock mutex](AuroraMySQL.Reference.Waitevents.md#key-cache.cache-lock). | | `key_cache_age_threshold` | Sì | Nessuno | | `key_cache_block_size` | Sì | Nessuno | | `key_cache_division_limit` | Sì | Nessuno | | `local_infile` | Sì | Nessuno | | `lock_wait_timeout` | Sì | Nessuno | | `log-bin` | No | L'impostazione di `binlog_format` su `STATEMENT`, `MIXED` o `ROW` imposta automaticamente `log-bin` su `ON`. L'impostazione di `binlog_format` su `OFF` imposta automaticamente `log-bin` su `OFF`. Per ulteriori informazioni, consulta [Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)](AuroraMySQL.Replication.MySQL.md). | | `log_bin_trust_function_creators` | Sì | Nessuno | | `log_bin_use_v1_row_events` | Sì | Rimosso da Aurora MySQL versione 3. | | `log_error` | No | Nessuno | | `log_error_suppression_list` | Sì | Specifica un elenco di codici di errore che non sono registrati nel log degli errori di MySQL. In questo modo è possibile ignorare determinate condizioni di errore non critiche per mantenere puliti i log degli errori. Per ulteriori informazioni, consulta la sezione relativa a [log\$1error\$1suppression\$1list](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list) nella documentazione di MySQL. Questo parametro si applica ad Aurora MySQL versione 3.03 e successive. | | `log_output` | Sì | Nessuno | | `log_queries_not_using_indexes` | Sì | Nessuno | | `log_slave_updates` | No | Aurora MySQL versione 2. Utilizza `log_replica_updates` in Aurora MySQL versione 3. | | `log_replica_updates` | No | Aurora MySQL versione 3 | | `log_throttle_queries_not_using_indexes` | Sì | Nessuno | | `log_warnings` | Sì | Rimosso da Aurora MySQL versione 3. | | `long_query_time` | Sì | Nessuno | | `low_priority_updates` | Sì | Le operazioni `INSERT`, `UPDATE`, `DELETE` e `LOCK TABLE WRITE` attendono fino a quando non ci sono più operazioni `SELECT` in sospeso. Questo parametro ha effetto solo sui motori di archiviazione che utilizzano solo il blocco a livello di tabella (MyISAM, MEMORY, MERGE). Questo parametro si applica ad Aurora MySQL versione 3. | | `max_allowed_packet` | Sì | Nessuno | | `max_binlog_cache_size` | Sì | Nessuno | | `max_binlog_size` | No | Nessuno | | `max_binlog_stmt_cache_size` | Sì | Nessuno | | `max_connect_errors` | Sì | Nessuno | | `max_connections` | Sì | Il valore predefinito è rappresentato da una formula. Per informazioni dettagliate su come viene calcolato il valore `DBInstanceClassMemory` nella formula, vedi [Variabili di formula dei parametri database](USER_ParamValuesRef.md#USER_FormulaVariables). Per i valori predefiniti a seconda della classe di istanza, vedi [Numero massimo di connessioni a un'istanza database Aurora MySQL](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.MaxConnections). | | `max_delayed_threads` | Sì | Imposta il numero massimo di thread per gestire le istruzioni `INSERT DELAYED`. Questo parametro si applica ad Aurora MySQL versione 3. | | `max_error_count` | Sì | Il numero massimo di messaggi di errore, avviso e note da archiviare per la visualizzazione. Questo parametro si applica ad Aurora MySQL versione 3. | | `max_execution_time` | Sì | Il timeout per l’esecuzione delle istruzioni `SELECT`, in millisecondi. I valori possono essere compresi tra `0` e `18446744073709551615`. Se il parametro è impostato su `0`, non è previsto alcun timeout. Per ulteriori informazioni, consulta la sezione dedicata a [max\$1execution\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_execution_time) nella documentazione di MySQL. | | `max_heap_table_size` | Sì | Nessuno | | `max_insert_delayed_threads` | Sì | Nessuno | | `max_join_size` | Sì | Nessuno | | `max_length_for_sort_data` | Sì | Rimosso da Aurora MySQL versione 3. | | `max_prepared_stmt_count` | Sì | Nessuno | | `max_seeks_for_key` | Sì | Nessuno | | `max_sort_length` | Sì | Nessuno | | `max_sp_recursion_depth` | Sì | Nessuno | | `max_tmp_tables` | Sì | Rimosso da Aurora MySQL versione 3. | | `max_user_connections` | Sì | Nessuno | | `max_write_lock_count` | Sì | Nessuno | | `metadata_locks_cache_size` | Sì | Rimosso da Aurora MySQL versione 3. | | `min_examined_row_limit` | Sì | Utilizza questo parametro per impedire la registrazione delle query che esaminano un numero di righe inferiore a quello specificato. Questo parametro si applica ad Aurora MySQL versione 3. | | `myisam_data_pointer_size` | Sì | Nessuno | | `myisam_max_sort_file_size` | Sì | Nessuno | | `myisam_mmap_size` | Sì | Nessuno | | `myisam_sort_buffer_size` | Sì | Nessuno | | `myisam_stats_method` | Sì | Nessuno | | `myisam_use_mmap` | Sì | Nessuno | | `net_buffer_length` | Sì | Nessuno | | `net_read_timeout` | Sì | Nessuno | | `net_retry_count` | Sì | Nessuno | | `net_write_timeout` | Sì | Nessuno | | `old-style-user-limits` | Sì | Nessuno | | `old_passwords` | Sì | Rimosso da Aurora MySQL versione 3. | | `optimizer_prune_level` | Sì | Nessuno | | `optimizer_search_depth` | Sì | Nessuno | | `optimizer_switch` | Sì | Per informazioni sulle funzionalità Aurora MySQL che utilizzano questa opzione, consulta [Best practice con Amazon Aurora MySQL](AuroraMySQL.BestPractices.md). | | `optimizer_trace` | Sì | Nessuno | | `optimizer_trace_features` | Sì | Nessuno | | `optimizer_trace_limit` | Sì | Nessuno | | `optimizer_trace_max_mem_size` | Sì | Nessuno | | `optimizer_trace_offset` | Sì | Nessuno | | `performance-schema-consumer-events-waits-current` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance-schema-consumer-events-waits-current`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance-schema-instrument` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance-schema-instrument`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema` | Sì | Se la colonna **Origine** è impostata su `Modified`, significa che il servizio Approfondimenti sulle prestazioni gestisce lo schema delle prestazioni. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_accounts_size` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_accounts_size`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_global_instrumentation` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_consumer_global_instrumentation`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_thread_instrumentation` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_consumer_thread_instrumentation`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_stages_current` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_consumer_events_stages_current`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_stages_history` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_consumer_events_stages_history`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_stages_history_long` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_consumer_events_stages_history_long`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_statements_current` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_consumer_events_statements_current`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_statements_history` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_consumer_events_statements_history`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_statements_history_long` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_consumer_events_statements_history_long`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_waits_history` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_consumer_events_waits_history`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_waits_history_long` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_consumer_events_waits_history_long`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_statements_digest` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_consumer_statements_digest`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_digests_size` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_digests_size`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_stages_history_long_size` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_events_stages_history_long_size`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_stages_history_size` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_events_stages_history_size`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_statements_history_long_size` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_events_statements_history_long_size`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_statements_history_size` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_events_statements_history_size`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_transactions_history_long_size` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_events_transactions_history_long_size`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_transactions_history_size` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_events_transactions_history_size`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_waits_history_long_size` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_events_waits_history_long_size`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_waits_history_size` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_events_waits_history_size`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_hosts_size` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_hosts_size`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_cond_classes` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_cond_classes`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_cond_instances` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_cond_instances`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_digest_length` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_digest_length`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_file_classes` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_file_classes`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_file_handles` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_file_handles`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_file_instances` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_file_instances`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_index_stat` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_index_stat`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_memory_classes` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_memory_classes`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_metadata_locks` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_metadata_locks`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_mutex_classes` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_mutex_classes`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_mutex_instances` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_mutex_instances`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_prepared_statements_instances` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_prepared_statements_instances`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_program_instances` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_program_instances`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_rwlock_classes` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_rwlock_classes`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_rwlock_instances` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_rwlock_instances`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_socket_classes` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_socket_classes`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_socket_instances` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_socket_instances`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_sql_text_length` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_sql_text_length`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_stage_classes` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_stage_classes`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_statement_classes` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_statement_classes`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_statement_stack` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_statement_stack`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_table_handles` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_table_handles`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_table_instances` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_table_instances`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_table_lock_stat` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_table_lock_stat`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_thread_classes` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_thread_classes`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_thread_instances` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_max_thread_instances`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_session_connect_attrs_size` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_session_connect_attrs_size`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_setup_actors_size` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_setup_actors_size`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_setup_objects_size` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_setup_objects_size`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_show_processlist` | Sì | Questo parametro determina quale implementazione SHOW PROCESSLIST utilizzare: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html)Questo parametro si applica ad Aurora MySQL versione 2.12 e successive e versione 3. Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_show_processlist`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_users_size` | Sì | Se la colonna **Origine** per il parametro `performance_schema` è impostata su `Modified`, significa che lo schema delle prestazioni utilizza il parametro `performance_schema_users_size`. Per ulteriori informazioni sull’abilitazione dello schema delle prestazioni, consulta [Determinazione della gestione dello schema delle prestazioni da parte di Performance Insights](USER_PerfInsights.EnableMySQL.determining-status.md). | | `pid_file` | No | Nessuno | | `plugin_dir` | No | Aurora MySQL utilizza istanze gestite in cui non si accede direttamente al filesystem. | | `port` | No | Aurora MySQL gestisce le proprietà della connessione e applica impostazioni coerenti per tutte le istanze database in un cluster. | | `preload_buffer_size` | Sì | La dimensione del buffer allocato durante il precaricamento degli indici. Questo parametro si applica ad Aurora MySQL versione 3. | | `profiling_history_size` | Sì | Nessuno | | `query_alloc_block_size` | Sì | Nessuno | | `query_cache_limit` | Sì | Rimosso da Aurora MySQL versione 3. | | `query_cache_min_res_unit` | Sì | Rimosso da Aurora MySQL versione 3. | | `query_cache_size` | Sì | Il valore predefinito è rappresentato da una formula. Per informazioni dettagliate su come viene calcolato il valore `DBInstanceClassMemory` nella formula, vedi [Variabili di formula dei parametri database](USER_ParamValuesRef.md#USER_FormulaVariables). Rimosso da Aurora MySQL versione 3. | | `query_cache_type` | Sì | Rimosso da Aurora MySQL versione 3. | | `query_cache_wlock_invalidate` | Sì | Rimosso da Aurora MySQL versione 3. | | `query_prealloc_size` | Sì | Nessuno | | `range_alloc_block_size` | Sì | Nessuno | | `read_buffer_size` | Sì | Nessuno | | `read_only` | Sì | Quando questo parametro è attivato, il server non consente aggiornamenti tranne quelli eseguiti dai thread di replica. I valori validi per Aurora MySQL versione 2 sono i seguenti: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Ti consigliamo di utilizzare il gruppo di parametri del cluster di database in Aurora MySQL versione 2 per garantire che il parametro `read_only` venga applicato alle nuove istanze di scrittura in caso di failover. Le istanze di lettura sono sempre di sola lettura, perché Aurora MySQL imposta `innodb_read_only` su `1` su tutte le letture. Pertanto, `read_only` è ridondante sulle istanze di lettura. È stato rimosso a livello di istanza da Aurora MySQL versione 3. | | `read_rnd_buffer_size` | Sì | Nessuno | | `relay-log` | No | Nessuno | | `relay_log_info_repository` | Sì | Rimosso da Aurora MySQL versione 3. | | `relay_log_recovery` | No | Nessuno | | `replica_checkpoint_group` | Sì | Aurora MySQL versione 3 | | `replica_checkpoint_period` | Sì | Aurora MySQL versione 3 | | `replica_parallel_workers` | Sì | Aurora MySQL versione 3 | | `replica_pending_jobs_size_max` | Sì | Aurora MySQL versione 3 | | `replica_skip_errors` | Sì | Aurora MySQL versione 3 | | `replica_sql_verify_checksum` | Sì | Aurora MySQL versione 3 | | `safe-user-create` | Sì | Nessuno | | `secure_auth` | Sì | Questo parametro è sempre attivato in Aurora MySQL versione 2. Il tentativo di disattivarlo genera un errore. Rimosso da Aurora MySQL versione 3. | | `secure_file_priv` | No | Aurora MySQL utilizza istanze gestite in cui non si accede direttamente al filesystem. | | `show_create_table_verbosity` | Sì | Abilitando questa variabile, [SHOW\$1CREATE\$1TABLE](https://dev.mysql.com/doc/refman/5.7/en/show-create-table.html) visualizza `ROW_FORMAT` a prescindere che si tratti del formato predefinito. Questo parametro si applica ad Aurora MySQL versione 2.12 e successive e versione 3. | | `skip-slave-start` | No | Nessuno | | `skip_external_locking` | No | Nessuno | | `skip_show_database` | Sì | Nessuno | | `slave_checkpoint_group` | Sì | Aurora MySQL versione 2. Utilizza `replica_checkpoint_group` in Aurora MySQL versione 3. | | `slave_checkpoint_period` | Sì | Aurora MySQL versione 2. Utilizza `replica_checkpoint_period` in Aurora MySQL versione 3. | | `slave_parallel_workers` | Sì | Aurora MySQL versione 2. Utilizza `replica_parallel_workers` in Aurora MySQL versione 3. | | `slave_pending_jobs_size_max` | Sì | Aurora MySQL versione 2. Utilizza `replica_pending_jobs_size_max` in Aurora MySQL versione 3. | | `slave_sql_verify_checksum` | Sì | Aurora MySQL versione 2. Utilizza `replica_sql_verify_checksum` in Aurora MySQL versione 3. | | `slow_launch_time` | Sì | Nessuno | | `slow_query_log` | Sì | Per istruzioni sul caricamento dei log su CloudWatch Logs, consulta [Pubblicazione di log Amazon Aurora MySQL in Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). | | `slow_query_log_file` | No | Aurora MySQL utilizza istanze gestite in cui non si accede direttamente al filesystem. | | `socket` | No | Nessuno | | `sort_buffer_size` | Sì | Nessuno | | `sql_mode` | Sì | Nessuno | | `sql_select_limit` | Sì | Nessuno | | `stored_program_cache` | Sì | Nessuno | | `sync_binlog` | No | Nessuno | | `sync_master_info` | Sì | Nessuno | | `sync_source_info` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. | | `sync_relay_log` | Sì | Rimosso da Aurora MySQL versione 3. | | `sync_relay_log_info` | Sì | Nessuno | | `sysdate-is-now` | Sì | Nessuno | | `table_cache_element_entry_ttl` | No | Nessuno | | `table_definition_cache` | Sì | Il valore predefinito è rappresentato da una formula. Per informazioni dettagliate su come viene calcolato il valore `DBInstanceClassMemory` nella formula, vedi [Variabili di formula dei parametri database](USER_ParamValuesRef.md#USER_FormulaVariables). | | `table_open_cache` | Sì | Il valore predefinito è rappresentato da una formula. Per informazioni dettagliate su come viene calcolato il valore `DBInstanceClassMemory` nella formula, vedi [Variabili di formula dei parametri database](USER_ParamValuesRef.md#USER_FormulaVariables). | | `table_open_cache_instances` | Sì | Nessuno | | `temp-pool` | Sì | Rimosso da Aurora MySQL versione 3. | | `temptable_max_mmap` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. Per informazioni dettagliate, consultare [Nuovo comportamento della tabella temporanea in Aurora MySQL versione 3](ams3-temptable-behavior.md). | | `temptable_max_ram` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. Per informazioni dettagliate, consultare [Nuovo comportamento della tabella temporanea in Aurora MySQL versione 3](ams3-temptable-behavior.md). | | `temptable_use_mmap` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. Per informazioni dettagliate, consultare [Nuovo comportamento della tabella temporanea in Aurora MySQL versione 3](ams3-temptable-behavior.md). | | `thread_cache_size` | Sì | Il numero di thread da memorizzare nella cache. Questo parametro si applica ad Aurora MySQL versioni 2 e 3. | | `thread_handling` | No | Nessuno | | `thread_stack` | Sì | Nessuno | | `timed_mutexes` | Sì | Nessuno | | `tmp_table_size` | Sì | Definisce le dimensioni massime delle tabelle temporanee in memoria create dal motore di storage `MEMORY` in Aurora MySQL versione 3. In Aurora MySQL versione 3.04 e successive, definisce le dimensioni massime delle tabelle temporanee in memoria create dal motore di storage `TempTable` quando `aurora_tmptable_enable_per_table_limit` è `ON`. Per ulteriori informazioni, consulta [Limitazione delle dimensioni delle tabelle temporanee interne in memoria](ams3-temptable-behavior.md#ams3-temptable-behavior-limit). | | `tmpdir` | No | Aurora MySQL utilizza istanze gestite in cui non si accede direttamente al filesystem. | | `transaction_alloc_block_size` | Sì | Nessuno | | `transaction_isolation` | Sì | Questo parametro si applica ad Aurora MySQL versione 3. Sostituisce `tx_isolation`. | | `transaction_prealloc_size` | Sì | Nessuno | | `tx_isolation` | Sì | Rimosso da Aurora MySQL versione 3. È sostituito da `transaction_isolation`. | | `updatable_views_with_limit` | Sì | Nessuno | | `validate-password` | No | Nessuno | | `validate_password_dictionary_file` | No | Nessuno | | `validate_password_length` | No | Nessuno | | `validate_password_mixed_case_count` | No | Nessuno | | `validate_password_number_count` | No | Nessuno | | `validate_password_policy` | No | Nessuno | | `validate_password_special_char_count` | No | Nessuno | | `wait_timeout` | Sì | Aurora valuta il valore minimo di `interactive_timeout` e `wait_timeout`. Quindi usa quel minimo come timeout per terminare tutte le sessioni inattive, sia interattive sia non interattive. | ## I parametri MySQL seguenti non si applicano ad Aurora MySQL A causa delle differenze tra l'architettura di Aurora MySQL e quella di MySQL, alcuni parametri e variabili di stato MySQL non si applicano ad Aurora MySQL. I parametri MySQL seguenti non si applicano ad Aurora MySQL. L'elenco non è completo. + `activate_all_roles_on_login`: questo parametro non si applica ad Aurora MySQL versione 2. E' disponibile in Aurora MySQL versione 3. + `big_tables` + `bind_address` + `character_sets_dir` + `innodb_adaptive_flushing` + `innodb_adaptive_flushing_lwm` + `innodb_buffer_pool_chunk_size` + `innodb_buffer_pool_instances` + `innodb_change_buffering` + `innodb_checksum_algorithm` + `innodb_data_file_path` + `innodb_dedicated_server` + `innodb_doublewrite` + `innodb_flush_log_at_timeout`: questo parametro non si applica ad Aurora MySQL. Per ulteriori informazioni, consulta [Configurazione della frequenza di svuotamento del buffer dei registri](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush). + `innodb_flush_method` + `innodb_flush_neighbors` + `innodb_io_capacity` + `innodb_io_capacity_max` + `innodb_log_buffer_size` + `innodb_log_file_size` + `innodb_log_files_in_group` + `innodb_log_spin_cpu_abs_lwm` + `innodb_log_spin_cpu_pct_hwm` + `innodb_log_writer_threads` + `innodb_max_dirty_pages_pct` + `innodb_numa_interleave` + `innodb_page_size` + `innodb_redo_log_capacity` + `innodb_redo_log_encrypt` + `innodb_undo_log_encrypt` + `innodb_undo_log_truncate` + `innodb_undo_logs` + `innodb_undo_tablespaces` + `innodb_use_native_aio` + `innodb_write_io_threads` # Variabili di stato globali di Aurora MySQL Aurora MySQL include variabili di stato fornite da Community MySQL e variabili che sono specifiche di Aurora. È possibile esaminare queste variabili per scoprire cosa succede all’interno del motore di database. Per ulteriori informazioni sulle variabili di stato in Community MySQL, consulta [Server Status Variables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html) nella documentazione di Community MySQL 8.0. È possibile individuare i valori correnti delle variabili di stato globali di Aurora MySQL utilizzando un'istruzione come la seguente: ``` show global status like '%aurora%'; ``` **Nota** Il valore delle variabili di stato globali viene cancellato al riavvio del motore di database. Nella tabella seguente vengono descritte le variabili di stato globali utilizzate da Aurora MySQL. | Nome | Description | | --- | --- | | `AuroraDb_commits` | Il numero totale di commit dall'ultimo riavvio. | | `AuroraDb_commit_latency` | La latenza del commit aggregata dall'ultimo riavvio. | | `AuroraDb_ddl_stmt_duration` | La latenza DDL aggregata dall'ultimo riavvio. | | `AuroraDb_select_stmt_duration` | La latenza dell'istruzione `SELECT` aggregata dall'ultimo riavvio. | | `AuroraDb_insert_stmt_duration` | La latenza dell'istruzione `INSERT` aggregata dall'ultimo riavvio. | | `AuroraDb_update_stmt_duration` | La latenza dell'istruzione `UPDATE` aggregata dall'ultimo riavvio. | | `AuroraDb_delete_stmt_duration` | La latenza dell'istruzione `DELETE` aggregata dall'ultimo riavvio. | | `Aurora_binlog_io_cache_allocated` | Il numero di byte allocati alla cache I/O binlog. | | `Aurora_binlog_io_cache_read_requests` | Il numero di richieste di lettura effettuate alla cache binlog. I/O | | `Aurora_binlog_io_cache_reads` | Il numero di richieste di lettura che sono state servite dalla cache binlog I/O . | | `Aurora_enhanced_binlog` | Indica se il binlog avanzato è abilitato o disabilitato per questa istanza database. Per ulteriori informazioni, consulta [Configurazione del file di log binario avanzato per Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). | | `Aurora_external_connection_count` | Il numero di connessioni database all'istanza database, ad esclusione delle connessioni al servizio RDS utilizzate per i controlli dell'integrità del database. | | `Aurora_fast_insert_cache_hits` | Un contatore che viene incrementato quando il cursore memorizzato nella cache viene recuperato e verificato. Per ulteriori informazioni sulla cache di inserimento rapido, consulta [Miglioramenti alle prestazioni di Amazon Aurora MySQL](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance). | | `Aurora_fast_insert_cache_misses` | Un contatore che viene incrementato quando il cursore memorizzato nella cache non è più valido e Aurora esegue un attraversamento di indice normale. Per ulteriori informazioni sulla cache di inserimento rapido, consulta [Miglioramenti alle prestazioni di Amazon Aurora MySQL](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance). | | `Aurora_fts_cache_memory_used` | La quantità di memoria in byte utilizzata dal sistema di ricerca full-text InnoDB. Questa variabile si applica ad Aurora MySQL versione 3.07 e successive. | | `Aurora_fwd_master_dml_stmt_count` | Il numero totale di istruzioni DML inoltrate a questa istanza database di scrittura. Questa variabile si applica ad Aurora MySQL versione 2. | | `Aurora_fwd_master_dml_stmt_duration` | La durata totale delle istruzioni DML inoltrate a questa istanza database di scrittura. Questa variabile si applica ad Aurora MySQL versione 2. | | `Aurora_fwd_master_errors_rpc_timeout` | Il numero di volte in cui non è stato possibile stabilire una connessione inoltrata sull'istanza di scrittura. | | `Aurora_fwd_master_errors_session_limit` | Il numero di query inoltrate che vengono rifiutate a causa di `session full` sull'istanza di scrittura. | | `Aurora_fwd_master_errors_session_timeout` | Il numero di volte in cui una sessione di inoltro viene terminata a causa di un timeout sull'istanza di scrittura. | | `Aurora_fwd_master_open_sessions` | Il numero di sessioni inoltrate sull'istanza database di scrittura. Questa variabile si applica ad Aurora MySQL versione 2. | | `Aurora_fwd_master_select_stmt_count` | Il numero totale di istruzioni `SELECT` inoltrate a questa istanza database di scrittura. Questa variabile si applica ad Aurora MySQL versione 2. | | `Aurora_fwd_master_select_stmt_duration` | La durata totale delle istruzioni `SELECT` inoltrate a questa istanza database di scrittura. Questa variabile si applica ad Aurora MySQL versione 2. | | `Aurora_fwd_writer_dml_stmt_count` | Il numero totale di istruzioni DML inoltrate a questa istanza database di scrittura. Questa variabile si applica ad Aurora MySQL versione 3. | | `Aurora_fwd_writer_dml_stmt_duration` | La durata totale delle istruzioni DML inoltrate a questa istanza database di scrittura. Questa variabile si applica ad Aurora MySQL versione 3. | | `Aurora_fwd_writer_errors_rpc_timeout` | Il numero di volte in cui non è stato possibile stabilire una connessione inoltrata sull'istanza di scrittura. | | `Aurora_fwd_writer_errors_session_limit` | Il numero di query inoltrate che vengono rifiutate a causa di `session full` sull'istanza di scrittura. | | `Aurora_fwd_writer_errors_session_timeout` | Il numero di volte in cui una sessione di inoltro viene terminata a causa di un timeout sull'istanza di scrittura. | | `Aurora_fwd_writer_open_sessions` | Il numero di sessioni inoltrate sull'istanza database di scrittura. Questa variabile si applica ad Aurora MySQL versione 3. | | `Aurora_fwd_writer_select_stmt_count` | Il numero totale di istruzioni `SELECT` inoltrate a questa istanza database di scrittura. Questa variabile si applica ad Aurora MySQL versione 3. | | `Aurora_fwd_writer_select_stmt_duration` | La durata totale delle istruzioni `SELECT` inoltrate a questa istanza database di scrittura. Questa variabile si applica ad Aurora MySQL versione 3. | | `Aurora_lockmgr_buffer_pool_memory_used` | La quantità di memoria del pool di buffer in byte utilizzata dalla gestione dei blocchi Aurora MySQL. | | `Aurora_lockmgr_memory_used` | La quantità di memoria in byte utilizzata dalla gestione dei blocchi Aurora MySQL. | | `Aurora_ml_actual_request_cnt` | Le richieste aggregate contano tra Aurora SQLmakes My e i servizi di machine learning Aurora per tutte le query eseguite dagli utenti dell'istanza DB. Per ulteriori informazioni, consulta [Utilizzo di machine learning di Amazon Aurora con Aurora MySQL](mysql-ml.md). | | `Aurora_ml_actual_response_cnt` | Il conteggio delle risposte aggregate che Aurora MySQL riceve dai servizi di machine learning di Aurora per tutte le query eseguite dagli utenti dell'istanza database. Per ulteriori informazioni, consulta [Utilizzo di machine learning di Amazon Aurora con Aurora MySQL](mysql-ml.md). | | `Aurora_ml_cache_hit_cnt` | Il conteggio degli hit della cache interna aggregata che Aurora MySQL riceve dai servizi di machine learning di Aurora per tutte le query eseguite dagli utenti dell'istanza database. Per ulteriori informazioni, consulta [Utilizzo di machine learning di Amazon Aurora con Aurora MySQL](mysql-ml.md). | | `Aurora_ml_logical_request_cnt` | Il numero di richieste logiche valutate dall'istanza database per essere inviate ai servizi di machine learning di Aurora dall'ultimo ripristino dello stato. A seconda del fatto che sia stato utilizzato il batching, questo valore può essere superiore a `Aurora_ml_actual_request_cnt`. Per ulteriori informazioni, consulta [Utilizzo di machine learning di Amazon Aurora con Aurora MySQL](mysql-ml.md). | | `Aurora_ml_logical_response_cnt` | Il conteggio delle risposte aggregate che Aurora MySQL riceve dai servizi di machine learning di Aurora per tutte le query eseguite dagli utenti dell'istanza database. Per ulteriori informazioni, consulta [Utilizzo di machine learning di Amazon Aurora con Aurora MySQL](mysql-ml.md). | | `Aurora_ml_retry_request_cnt` | Il numero di richieste ripetute inviate dall'istanza database ai servizi di machine learning di Aurora dall'ultimo ripristino dello stato. Per ulteriori informazioni, consulta [Utilizzo di machine learning di Amazon Aurora con Aurora MySQL](mysql-ml.md). | | `Aurora_ml_single_request_cnt` | Il conteggio aggregato delle funzioni di machine learning di Aurora valutate in modalità non batch per tutte le query eseguite dagli utenti dell'istanza database. Per ulteriori informazioni, consulta [Utilizzo di machine learning di Amazon Aurora con Aurora MySQL](mysql-ml.md). | | `aurora_oom_avoidance_recovery_state` | Indica se il ripristino da prevenzione di Aurora out-of-memory (OOM) è nello `INACTIVE` stato `ACTIVE` o per questa istanza DB. Questa variabile si applica ad Aurora MySQL versione 3.06.0 e successive. | | `aurora_oom_reserved_mem_enter_kb` | Rappresenta la soglia per il passaggio allo stato `RESERVED` nel meccanismo di gestione dei problemi di esaurimento della memoria di Aurora. Quando la memoria disponibile sul server scende al di sotto di questa soglia, il valore di `aurora_oom_status` passa a `RESERVED`, a indicare che il server si sta avvicinando a un livello critico di utilizzo della memoria. Questa variabile si applica ad Aurora MySQL versione 3.06.0 e successive. | | `aurora_oom_reserved_mem_exit_kb` | Rappresenta la soglia per l’uscita dallo stato `RESERVED` nel meccanismo di gestione dei problemi di esaurimento della memoria di Aurora. Quando la memoria disponibile sul server supera questa soglia, `aurora_oom_status` ritorna a `NORMAL`, a indicare che il server è tornato a uno stato più stabile con risorse di memoria sufficienti. Questa variabile si applica ad Aurora MySQL versione 3.06.0 e successive. | | `aurora_oom_status` | Rappresenta lo stato corrente dell’istanza database relativo all’eventuale esaurimento della memoria. Quando il valore è `NORMAL`, significa che le risorse di memoria sono sufficienti. Se il valore passa a `RESERVED`, significa che la memoria disponibile sul server è insufficiente. Vengono intraprese delle azioni in base alla configurazione del parametro `aurora_oom_response`. Per ulteriori informazioni, consulta [Risoluzione dei problemi di memoria insufficiente per i database Aurora MySQL](AuroraMySQLOOM.md). Questa variabile si applica ad Aurora MySQL versione 3.06.0 e successive. | | `Aurora_pq_bytes_returned` | Il numero di byte per le strutture di dati tuple trasmesse al nodo head nel corso delle query in parallelo. Dividi questo valore per 16.384 per compararlo a `Aurora_pq_pages_pushed_down`. | | `Aurora_pq_max_concurrent_requests` | Il numero massimo di sessioni di query in parallelo eseguibili simultaneamente su questa istanza database Aurora. Si tratta di un numero fisso che dipende dalla classe dell'istanza AWS DB. | | `Aurora_pq_pages_pushed_down` | Il numero di pagine di dati (ognuna con una dimensione fissa di 16 KiB) per le quali una query in parallelo ha evitato una trasmissione di rete al nodo head. | | `Aurora_pq_request_attempted` | Il numero di sessioni di query in parallelo necessarie. Questo valore può rappresentare più di una sessione per query, a seconda dei costrutti SQL come sottoquery e join. | | `Aurora_pq_request_executed` | Il numero di sessioni di query in parallelo riuscite. | | `Aurora_pq_request_failed` | Il numero di sessioni di query in parallelo che hanno restituito un errore al client. In alcuni casi, una richiesta di query in parallelo può non riuscire, ad esempio a causa di un problema nel livello di storage. In questi casi, viene eseguito un nuovo tentativo per la parte di query non riuscita utilizzando il meccanismo di query non in parallelo. Se anche il nuovo tentativo non riesce, viene restituito un errore al client e questo contatore viene incrementato. | | `Aurora_pq_request_in_progress` | Il numero di sessioni di query in parallelo attualmente in corso. Questo numero si applica all'istanza database Aurora a cui sei connesso e non all'intero cluster di database Aurora. Per determinare se un'istanza database è prossima al relativo limite di simultaneità, compara questo valore a `Aurora_pq_max_concurrent_requests`. | | `Aurora_pq_request_not_chosen` | Il numero di volte che una query in parallelo non è stata scelta per una query. Questo valore è la somma di vari altri contatori più granulari. Un'istruzione `EXPLAIN` può incrementare questo contatore anche se la query non viene effettivamente eseguita. | | `Aurora_pq_request_not_chosen_below_min_rows` | Il numero di volte che una query in parallelo non è stata scelta a causa del numero di righe nella tabella. Un'istruzione `EXPLAIN` può incrementare questo contatore anche se la query non viene effettivamente eseguita. | | `Aurora_pq_request_not_chosen_column_bit` | Numero di richieste di query parallele che utilizzano il percorso di elaborazione delle query non parallele a causa di un tipo di dati non supportato nell'elenco delle colonne proiettate. | | `Aurora_pq_request_not_chosen_column_geometry` | Numero di richieste di query parallele che utilizzano il percorso di elaborazione delle query non parallele perché la tabella contiene colonne con il tipo di `GEOMETRY` dati. Per informazioni sulle versioni di Aurora MySQL che rimuovono questa limitazione, consulta [Aggiornare cluster di query paralleli a Aurora MySQL versione 3](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2). | | `Aurora_pq_request_not_chosen_column_lob` | Numero di richieste di query parallele che utilizzano il percorso di elaborazione delle query non parallele perché la tabella contiene colonne con un tipo di dati `LOB` o colonne `VARCHAR` memorizzate esternamente a causa della lunghezza dichiarata. Per informazioni sulle versioni di Aurora MySQL che rimuovono questa limitazione, consulta [Aggiornare cluster di query paralleli a Aurora MySQL versione 3](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2). | | `Aurora_pq_request_not_chosen_column_virtual` | Numero di richieste di query parallele che utilizzano il percorso di elaborazione delle query non parallele perché la tabella contiene una colonna virtuale. | | `Aurora_pq_request_not_chosen_custom_charset` | Numero di richieste di query parallele che utilizzano il percorso di elaborazione delle query non parallele perché la tabella dispone di colonne con un set di caratteri personalizzato. | | `Aurora_pq_request_not_chosen_fast_ddl` | Il numero di richieste di query parallele che utilizzano il percorso di elaborazione delle query non parallele perché la tabella è attualmente in fase di modifica da un'istruzione `ALTER` DDL veloce. | | `Aurora_pq_request_not_chosen_few_pages_outside_buffer_pool` | Il numero di volte che una query in parallelo non è stata scelta anche se meno del 95% dei dati della tabella era già nel pool di buffer, in quanto non c'erano dati non memorizzati nel buffer sufficienti per giustificare l'utilizzo della funzione di query in parallelo. | | `Aurora_pq_request_not_chosen_full_text_index` | Numero di richieste di query parallele che utilizzano il percorso di elaborazione delle query non parallele perché la tabella dispone di indici full-text. | | `Aurora_pq_request_not_chosen_high_buffer_pool_pct` | Il numero di volte che una query in parallelo non è stata scelta in quanto un'elevata percentuale di dati di tabella (attualmente maggiore del 95%) era già nel pool di buffer. In questi casi, l'ottimizzatore determina che la lettura dei dati del pool di buffer è più efficace. Un'istruzione `EXPLAIN` può incrementare questo contatore anche se la query non viene effettivamente eseguita. | | `Aurora_pq_request_not_chosen_index_hint` | Numero di richieste di query parallele che utilizzano il percorso di elaborazione delle query non parallele perché la query include un hint di indice. | | `Aurora_pq_request_not_chosen_innodb_table_format` | Il numero di richieste di query parallele che utilizzano il percorso di elaborazione delle query non parallele perché la tabella utilizza un formato di riga InnoDB non supportato. La query parallela Aurora si applica solo ai formati di riga `COMPACT`, `REDUNDANT` e `DYNAMIC`. | | `Aurora_pq_request_not_chosen_long_trx` | Il numero di richieste di query in parallelo che hanno utilizzato il percorso di elaborazione di query non in parallelo in seguito all'avvio della query in una transazione di lunga durata. Un'istruzione `EXPLAIN` può incrementare questo contatore anche se la query non viene effettivamente eseguita. | | `Aurora_pq_request_not_chosen_no_where_clause` | Numero di richieste di query parallele che utilizzano il percorso di elaborazione delle query non parallele perché la query non include alcuna clausola `WHERE`. | | `Aurora_pq_request_not_chosen_range_scan` | Numero di richieste di query parallele che utilizzano il percorso di elaborazione delle query non parallele perché la query utilizza una scansione di intervallo su un indice. | | `Aurora_pq_request_not_chosen_row_length_too_long` | Numero di richieste di query parallele che utilizzano il percorso di elaborazione delle query non parallele perché la lunghezza totale combinata di tutte le colonne è troppo lunga. | | `Aurora_pq_request_not_chosen_small_table` | Il numero di volte che una query in parallelo non è stata scelta a causa della dimensione globale della tabella, come determinata dal numero di righe e dalla lunghezza media delle stesse. Un'istruzione `EXPLAIN` può incrementare questo contatore anche se la query non viene effettivamente eseguita. | | `Aurora_pq_request_not_chosen_temporary_table` | Numero di richieste di query parallele che utilizzano il percorso di elaborazione delle query non parallele perché la query fa riferimento a tabelle temporanee che utilizzano i tipi di tabella `MyISAM` o `memory` non supportati. | | `Aurora_pq_request_not_chosen_tx_isolation` | Numero di richieste di query parallele che utilizzano il percorso di elaborazione delle query non parallele perché la query utilizza un livello di isolamento delle transazioni non supportato. Sulle istanze del database di lettura, la query parallela si applica solo ai livelli di isolamento `REPEATABLE READ` e `READ COMMITTED`. | | `Aurora_pq_request_not_chosen_update_delete_stmts` | Numero di richieste di query parallele che utilizzano il percorso di elaborazione delle query non parallele perché la query fa parte di un'istruzione `UPDATE` o `DELETE`. | | `Aurora_pq_request_not_chosen_unsupported_access` | Il numero di richieste di query in parallelo che utilizzano il percorso di elaborazione di query non in parallelo in quanto la clausola `WHERE` non soddisfa i criteri delle query in parallelo. Ciò può avvenire se la query non richiede l'analisi di un grande volume di dati oppure se la query è un'istruzione `DELETE` o `UPDATE`. | | `Aurora_pq_request_not_chosen_unsupported_storage_type` | Il numero di richieste di query in parallelo che utilizzano il percorso di elaborazione delle query non in parallelo perché il cluster database Aurora MySQL non utilizza una configurazione di archiviazione del cluster Aurora supportata. Per ulteriori informazioni, consulta [Limitazioni](aurora-mysql-parallel-query.md#aurora-mysql-parallel-query-limitations). Questo parametro si applica solo ad Aurora MySQL versione 3.04 e successive. | | `Aurora_pq_request_throttled` | Il numero di volte che una query in parallelo non è stata scelta a causa del numero massimo di query in parallelo simultanee già in esecuzione su una particolare istanza database Aurora. | | `Aurora_repl_bytes_received` | Numero di byte replicati in un'istanza database di lettura Aurora MySQL dall'ultimo riavvio. Per ulteriori informazioni, consulta [Replica con Amazon Aurora MySQL](AuroraMySQL.Replication.md). | | `Aurora_reserved_mem_exceeded_incidents` | Il numero di volte dall'ultimo riavvio in cui il motore ha superato i limiti di memoria prenotata. Se `aurora_oom_response` configurata, questa soglia definisce quando vengono attivate le attività di evitamento out-of-memory (OOM). Per ulteriori informazioni sulla risposta OOM di Aurora MySQL, consulta [Risoluzione dei problemi di memoria insufficiente per i database Aurora MySQL](AuroraMySQLOOM.md). | | `aurora_temptable_max_ram_allocation` | La quantità massima di memoria (espressa in byte) utilizzata in un momento qualsiasi dalle tabelle temporanee interne dopo l’ultimo riavvio. | | `aurora_temptable_ram_allocation` | La quantità corrente di memoria (espressa in byte) utilizzata dalle tabelle temporanee interne. | | `Aurora_in_memory_relaylog_status` | Lo stato attuale della funzionalità relativa al log di inoltro in memoria; il valore può essere ENABLED o DISABLED. | | `Aurora_in_memory_relaylog_disabled_reason` | Mostra il motivo dello stato corrente della funzionalità relativa al log di inoltro in memoria. Se la funzionalità è disabilitata, visualizza un messaggio in cui viene spiegato il motivo di tale circostanza. | | `Aurora_in_memory_relaylog_fallback_count` | Mostra il numero totale di fallback della funzionalità relativa al log di inoltro in memoria alla modalità log di inoltro persistente (legacy). Il fallback può essere causato da un singolo evento di dimensioni superiori a quelle della cache (attualmente 128 MB) o dal superamento del limite di tentativi di transazione di replica replica\$1transaction\$1retries. | | `Aurora_in_memory_relaylog_recovery_count` | Mostra il numero totale di operazioni di ripristino del log di inoltro in memoria eseguite automaticamente. Il conteggio include il numero totale di fallback e il numero di passaggi automatici alla modalità di log di inoltro in memoria dopo i fallback temporanei. | | `Aurora_thread_pool_thread_count` | Il numero attuale di thread nel pool di thread di Aurora. Per ulteriori informazioni sulla risposta in Aurora MySQL, consulta [Pool di thread](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.pool). | | `Aurora_tmz_version` | Indica la versione corrente delle informazioni sul fuso orario utilizzate dal cluster database. I valori seguono il formato IANA (Internet Assigned Numbers Authority):`YYYYsuffix`, ad esempio `2022a` e `2023c`. Questo parametro si applica ad Aurora MySQL versione 2.12 e successive e versione 3.04 e successive. | | `Aurora_zdr_oom_threshold` | Rappresenta la soglia di memoria, in kilobyte (KB), per un’istanza database Aurora per lanciare un riavvio senza tempi di inattività finalizzato al ripristino da potenziali problemi correlati alla memoria. | | `server_aurora_das_running` | Indica se i flussi di attività del database sono abilitati o disabilitati su questa istanza database. Per ulteriori informazioni, consulta [Monitoraggio di Amazon Aurora tramite i flussi di attività del database](DBActivityStreams.md). | ## Le variabili di stato MySQL seguenti non si applicano ad Aurora MySQL A causa delle differenze tra l'architettura di Aurora MySQL e quella di MySQL, alcuni parametri e variabili di stato MySQL non si applicano ad Aurora MySQL. Le variabili di stato MySQL seguenti non si applicano ad Aurora MySQL. L'elenco non è completo. + `innodb_buffer_pool_bytes_dirty` + `innodb_buffer_pool_pages_dirty` + `innodb_buffer_pool_pages_flushed` Aurora MySQL versione 3 rimuove le seguenti variabili di stato presenti in Aurora MySQL versione 2: + `AuroraDb_lockmgr_bitmaps0_in_use` + `AuroraDb_lockmgr_bitmaps1_in_use` + `AuroraDb_lockmgr_bitmaps_mem_used` + `AuroraDb_thread_deadlocks` + `available_alter_table_log_entries` + `Aurora_lockmgr_memory_used` + `Aurora_missing_history_on_replica_incidents` + `Aurora_new_lock_manager_lock_release_cnt` + `Aurora_new_lock_manager_lock_release_total_duration_micro` + `Aurora_new_lock_manager_lock_timeout_cnt` + `Aurora_total_op_memory` + `Aurora_total_op_temp_space` + `Aurora_used_alter_table_log_entries` + `Aurora_using_new_lock_manager` + `Aurora_volume_bytes_allocated` + `Aurora_volume_bytes_left_extent` + `Aurora_volume_bytes_left_total` + `Com_alter_db_upgrade` + `Compression` + `External_threads_connected` + `Innodb_available_undo_logs` + `Last_query_cost` + `Last_query_partial_plans` + `Slave_heartbeat_period` + `Slave_last_heartbeat` + `Slave_received_heartbeats` + `Slave_retried_transactions` + `Slave_running` + `Time_since_zero_connections` Queste variabili dello stato MySQL sono disponibili in Aurora MySQL versione 2, ma non sono disponibili in Aurora MySQL versione 3: + `Innodb_redo_log_enabled` + `Innodb_undo_tablespaces_total` + `Innodb_undo_tablespaces_implicit` + `Innodb_undo_tablespaces_explicit` + `Innodb_undo_tablespaces_active` # Eventi di attesa Aurora MySQL Di seguito sono riportati alcuni tra gli eventi di attesa più frequenti di Aurora MySQL. **Nota** Per informazioni sull'ottimizzazione delle prestazioni di Aurora MySQL utilizzando gli eventi di attesa, consulta [Regolazione di Aurora MySQL con eventi di attesa](AuroraMySQL.Managing.Tuning.wait-events.md). Per informazioni sulle convenzioni di denominazione utilizzate per gli eventi di attesa MySQL, consulta la pagina relativa alle [ convenzioni di denominazione per la strumentazione dello schema di prestazioni](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-instrument-naming.html) nella documentazione di MySQL. **cpu** Il numero di connessioni attive pronte per l'esecuzione è costantemente superiore al numero di vCPUs. Per ulteriori informazioni, vedere[cpu](ams-waits.cpu.md). **io/aurora\$1redo\$1log\$1flush** Una sessione sta mantenendo i dati permanenti nell'archiviazione Aurora. In genere, questo evento di attesa è per un'operazione di I/O di scrittura in Aurora MySQL. Per ulteriori informazioni, consulta [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md). **io/aurora\$1respond\$1to\$1client** L'elaborazione delle query è stata completata e i risultati vengono restituiti al client dell'applicazione per le seguenti versioni Aurora MySQL: 2.10.2 e versioni 2.10 successive, 2.09.3 e versioni 2.09 successive, 2.07.7 e versioni 2.07 successive. Confrontare la larghezza di banda di rete della classe di istanza database con la dimensione del set di risultati restituito. Inoltre, controlla i tempi di risposta lato client. Se il client non risponde e non è in grado di elaborare i pacchetti TCP, possono verificarsi perdite di pacchetti e ritrasmissioni TCP. Questa situazione influisce negativamente sulla larghezza di banda della rete. Nelle versioni inferiori a 2.10.2, 2.09.3 e 2.07.7, l'evento di attesa include erroneamente il tempo di inattività. Per informazioni su come ottimizzare il database quando questa attesa è importante, vedere [io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md). **io/file/csv/data** Dei thread scrivono su tabelle in formato CSV (Comma-Separated Value, valori separati da virgola). Controlla l'utilizzo delle tabelle CSV. Una causa tipica di questo evento è l'impostazione `log_output` in una tabella. **io/file/sql/binlog** Un thread è in attesa di un file di log binario (binlog) scritto su disco. **io/redo\$1log\$1flush** Una sessione sta mantenendo i dati permanenti nell'archiviazione Aurora. In genere, questo evento di attesa riguarda un' I/O operazione di scrittura in Aurora MySQL. Per ulteriori informazioni, consulta [io/redo\$1log\$1flush](ams-waits.io-redologflush.md). **io/socket/sql/client\$1connessione** Il programma `mysqld` è impegnato a creare thread per gestire le nuove connessioni client in arrivo. Per ulteriori informazioni, consulta [io/socket/sql/client\$1connessione](ams-waits.client-connection.md). **io/table/sql/handler** Il motore è in attesa di accedere a una tabella. Questo evento si verifica indipendentemente dal fatto che i dati siano memorizzati nella cache nel buffer pool o se si accede su disco. Per ulteriori informazioni, consulta [io/table/sql/handler](ams-waits.waitio.md). **lock/table/sql/handler** Questo evento di attesa è un gestore eventi di attesa di blocco di tabella. Per ulteriori informazioni sugli eventi "atom" e "molecule" nello schema di prestazioni, consulta [ eventi Atom e Molecule dello schema di prestazioni](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-atom-molecule-events.html) nella documentazione di MySQL. **synch/cond/innodb/row\$1blocca\$1aspetta** Le istruzioni DML (Data Manipulation Language) accedono contemporaneamente alle stesse righe del database. Per ulteriori informazioni, consulta [synch/cond/innodb/row\$1blocca\$1aspetta](ams-waits.row-lock-wait.md). **synch/cond/innodb/row\$1lock\$1wait\$1cond** Più istruzioni DML (Data Manipulation Language) accedono contemporaneamente alle stesse righe del database. Per ulteriori informazioni, consulta [synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md). **synch/cond/sql/MDL\$1contesto: :COND\$1WAIT\$1STATUS** I thread sono in attesa di un blocco dei metadati di tabella. Il motore utilizza questo tipo di blocco per gestire l'accesso simultaneo a uno schema di database e garantire la coerenza dei dati. Per ulteriori informazioni, consulta la pagina relativa all'[ottimizzazione delle operazioni di blocco](https://dev.mysql.com/doc/refman/8.0/en/locking-issues.html) nella documentazione di MySQL. Per informazioni su come ottimizzare il database quando questo evento è importante, vedere [synch/cond/sql/MDL\$1contesto: :COND\$1WAIT\$1STATUS](ams-waits.cond-wait-status.md). **synch/cond/sql/MYSQL\$1BIN\$1LOG: :cond\$1done** Hai attivato la registrazione binaria. Potrebbe esserci un' elevata velocità effettiva di esecuzione del commit, un numero elevato di transazioni o repliche che leggono i binlog. Prendi in considerazione l'utilizzo di istruzioni multiriga o di crezione di bundle di istruzioni in un'unica transazione. In Aurora, usa i database globali anziché la replica del log binario oppure usa i parametri `aurora_binlog_*`. **synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex** Più istruzioni DML (Data Manipulation Language) accedono contemporaneamente alle stesse righe del database. Per ulteriori informazioni, consulta [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md). **synch/mutex/innodb/buf\$1pool-mutex** Il pool di buffer non è abbastanza grande da contenere il set di dati funzionante. Oppure il carico di lavoro accede alle pagine da una tabella specifica, che porta a contendenze nel buffer pool. Per ulteriori informazioni, consulta [synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md). **synch/mutex/innodb/fil\$1sistema\$1mutex** Il processo è in attesa di accedere alla cache di memoria tablespace. Per ulteriori informazioni, consulta [synch/mutex/innodb/fil\$1sistema\$1mutex](ams-waits.innodb-fil-system-mutex.md). **synch/mutex/innodb/trx\$1sys\$1mutex** Le operazioni consistono nel controllare, aggiornare, eliminare o aggiungere transazioni IDs in InnoDB in modo coerente o controllato. Queste operazioni richiedono una chiamata mutex `trx_sys`, che viene tracciata dalla strumentazione Performance Schema. Le operazioni includono la gestione del sistema di transazioni all'avvio o all'arresto del database, i rollback, le operazioni di cancellazione degli annullamenti, l'accesso in lettura delle righe e i carichi del pool di buffer. L'elevato carico del database con un numero elevato di transazioni comporta la frequente comparsa di questo evento di attesa. Per ulteriori informazioni, consulta [synch/mutex/innodb/trx\$1sys\$1mutex](ams-waits.trxsysmutex.md). **synch/mutex/mysys/KEY\$1CACHE: :cache\$1lock** La mutex `keycache->cache_lock` controlla l'accesso alla cache delle chiavi per le tabelle myISAM. Sebbene Aurora MySQL non consenta l'utilizzo di tabelle MyISAM per archiviare dati persistenti, vengono utilizzate per archiviare tabelle temporanee interne. Valuta se controllare i conteggi dello stato `created_tmp_disk_tables` o `created_tmp_tables`, perché in determinate situazioni, le tabelle temporanee vengono scritte su disco quando non possono più essere contenute nella memoria. **synch/mutex/sql/FILE\$1AS\$1TABLE: :LOCK\$1offsets** Il motore acquisisce questo mutex durante l'apertura o la creazione di un file di metadati di tabella. Quando questo evento di attesa si verifica con frequenza eccessiva, il numero di tabelle create o aperte è aumentato. **synch/mutex/sql/FILE\$1AS\$1TABLE: :LOCK\$1SHIM\$1LIST** Il motore acquisisce questo mutex durante l'esecuzione di operazioni come `reset_size`,`detach_contents`, oppure `add_contents` sulla struttura interna che tiene traccia delle tabelle aperte. Il mutex sincronizza l'accesso al contenuto dell'elenco. Quando questo evento di attesa si verifica con alta frequenza, indica un cambiamento improvviso nel set di tabelle a cui si accedeva in precedenza. Il motore deve accedere a nuove tabelle o lasciare andare il contesto relativo alle tabelle precedentemente accessibili. **synch/mutex/sql/LOCK\$1apri** Il numero di tabelle aperte dalle sessioni supera la dimensione della cache delle definizioni di tabella o della cache aperta della tabella. Aumenta le dimensioni di queste cache. Per ulteriori informazioni, consulta la pagina relativa ad [apertura e chiusura delle tabelle in MySQL](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html). **synch/mutex/sql/LOCK\$1tabella\$1cache** Il numero di tabelle aperte dalle sessioni supera la dimensione della cache delle definizioni di tabella o della cache aperta della tabella. Aumenta le dimensioni di queste cache. Per ulteriori informazioni, consulta la pagina relativa ad [apertura e chiusura delle tabelle in MySQL](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html). **synch/mutex/sql/LOG** In questo evento di attesa, ci sono thread in attesa di un blocco di log. Ad esempio, un thread potrebbe attendere un blocco per scrivere nel file di log delle query con tempi di risposta molto lunghi. **synch/mutex/sql/MYSQL\$1BIN\$1LOG: :LOCK\$1COMMIT** In questo evento di attesa, c'è un thread in attesa di acquisire un blocco per eseguire il commit nel log binario. Può verificarsi un conflitto della registrazione binaria nei database con frequenza di modifica molto alta. A seconda della versione di MySQL, vengono usati alcuni blocchi per proteggere la coerenza e la durabilità del log binario. In RDS for MySQL i log binari vengono usati per la replica e il processo di backup automatico. In Aurora MySQL i log binari non sono necessari per la replica nativa o i backup. Sono disabilitati per impostazione predefinita, ma possono essere abilitati e usati per la replica esterna o l'acquisizione dei dati delle modifiche. Per ulteriori informazioni, consulta la pagina relativa al [log binario](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) nella documentazione di MySQL. **sync/mutex/sql/MYSQL\$1BIN\$1LOG: :Collezione LOCK\$1DUMP\$1THREAD\$1METRICS** Se la registrazione binaria è attivata, il motore acquisisce questo mutex quando stampa le metriche dei thread di dump attivi nel registro degli errori del motore e sulla mappa delle operazioni interne. **sync/mutex/sql/MYSQL\$1BIN\$1LOG: :LOCK\$1INACTIVE\$1BINLOGS\$1MAP** Se la registrazione binaria è attivata, il motore acquisisce questo mutex quando aggiunge, elimina o cerca l'elenco dei file binlog dietro l'ultimo. **sync/mutex/sql/MYSQL\$1BIN\$1LOG: :LOCK\$1IO\$1CACHE** Se la registrazione binaria è attivata, il motore acquisisce questo mutex durante le operazioni della cache I/O di Aurora binlog: allocazione, ridimensionamento, liberazione, scrittura, lettura, rimozione e accesso alle informazioni della cache. Se questo evento si verifica frequentemente, il motore accede alla cache in cui sono memorizzati gli eventi binlog. Per ridurre i tempi di attesa, riduci i commit. Prova a raggruppare più istruzioni in una singola transazione. **synch/mutex/sql/MYSQL\$1BIN\$1LOG: :LOCK\$1LOG** Hai attivato la registrazione binaria. Potrebbe esserci un'elevata velocità effettiva di esecuzione del commit, molte transazioni nell'esecuzione del commit o repliche che leggono i binlog. Prendi in considerazione l'utilizzo di istruzioni multiriga o di crezione di bundle di istruzioni in un'unica transazione. In Aurora, usa i database globali anziché la replica dei log binari o usa i parametri `aurora_binlog_*`. **synch/mutex/sql/SERVER\$1DISCUSSIONE: :LOCK\$1sync** Il `SERVER_THREAD::LOCK_sync` mutex viene acquisito durante la pianificazione, l'elaborazione o l'avvio di thread per la scrittura di file. L'eccessiva occorrenza di questo evento di attesa indica una maggiore attività di scrittura nel database. **synch/mutex/sql/TABLESPACES\$1THREAD: :Lock\$1sync ----sep----:lock** Il motore acquisisce il mutex `TABLESPACES:lock` durante le seguenti operazioni di tablespace: creare, eliminare, troncare ed estendere. L'eccessiva occorrenza di questo evento di attesa indica un'alta frequenza di operazioni di tablespace. Un esempio è il caricamento di una grande quantità di dati nel database. **synch/rwlock/innodb/dict** In questo evento di attesa, ci sono thread in attesa di un oggetto rwlock nel dizionario dei dati InnoDB. **synch/rwlock/innodb/dict\$1operazione\$1lock** In questo evento di attesa, ci sono thread che mantengono blocchi sulle operazioni del dizionario dei dati InnoDB. **synch/rwlock/innodb/dictserratura SYS RW** Un numero elevato di istruzioni simultanee del linguaggio di controllo dei dati (DCLs) nel codice del linguaggio di definizione dei dati (DDLs) viene attivato contemporaneamente. Riduci la dipendenza dell'applicazione DDLs durante la normale attività dell'applicazione. **synch/rwlock/innodb/index\$1tree\$1rw\$1lock** Un gran numero di istruzioni DML (Data Manipolation Language) simili stanno accedendo allo stesso oggetto di database contemporaneamente. Prova a usare istruzioni multiriga. Inoltre, distribuisci il carico di lavoro su diversi oggetti di database. Ad esempio, implementa il partizionamento. **synch/sxlock/innodb/dict\$1operation\$1lock** Viene attivato contemporaneamente un numero elevato di istruzioni del linguaggio di controllo dei dati (DCLs) nel codice del linguaggio di definizione dei dati (DDLs). Riduci la dipendenza dell'applicazione DDLs durante la normale attività dell'applicazione. **synch/sxlock/innodb/dict\$1sys\$1lock** Viene attivato contemporaneamente un numero elevato di istruzioni del linguaggio di controllo dei dati (DCLs) nel codice del linguaggio di definizione dei dati (DDLs). Riduci la dipendenza dell'applicazione DDLs durante la normale attività dell'applicazione. **synch/sxlock/innodb/hash\$1table\$1locks** La sessione non è in grado di trovare pagine nel pool di buffer. Il motore deve leggere un file o modificare l'elenco LRU (LRU) utilizzato meno di recente per il buffer pool. Considera di aumentare le dimensioni della cache del buffer e migliorare i percorsi di accesso per le query pertinenti. **synch/sxlock/innodb/index\$1albero\$1rw\$1lock** Molte istruzioni DML (Data Manipulation Language) simili accedono allo stesso oggetto di database contemporaneamente. Prova a usare istruzioni multiriga. Inoltre, distribuisci il carico di lavoro su diversi oggetti di database. Ad esempio, implementa il partizionamento. **synch/mutex/innodb/temp\$1pool\$1manager\$1mutex** Questo evento di attesa si verifica quando una sessione è in attesa di acquisire un mutex per la gestione del pool di tablespace temporanee della sessione. Per ulteriori informazioni sulla risoluzione dei problemi di sincronizzazione degli eventi di attesa, consulta la sezione relativa al [motivo per cui un'istanza database MySQL mostra un numero elevato di sessioni attive in attesa di eventi di attesa SYNCH in Approfondimenti sulle prestazioni](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-mysql-synch-wait-events/). # Stati del thread Aurora MySQL Di seguito sono riportati alcuni tra gli stati di thread più frequenti di Aurora MySQL. **Verifica delle autorizzazioni** Il thread sta verificando se il server dispone dei privilegi necessari per eseguire l'istruzione. **controllo della cache delle query per la query** Il server sta verificando se la query corrente è presente nella cache delle query. **ripulito** Questo è lo stato finale di una connessione il cui lavoro è completo ma che non è stato chiuso dal client. La soluzione migliore è chiudere esplicitamente la connessione nel codice. Oppure puoi impostare un valore inferiore per `wait_timeout` nel gruppo di parametri. **chiusura tabelle** Il thread sta scaricando i dati della tabella modificati su disco e chiude le tabelle utilizzate. Se non si tratta di un'operazione rapida, verificare le metriche di consumo della larghezza di banda di rete rispetto alla larghezza di banda di rete della classe di istanza. Inoltre, verificare che i valori dei parametri per `table_open_cache`e `table_definition_cache` il parametro consentano di aprire contemporaneamente una quantità sufficiente di tabelle in modo che il motore non debba aprire e chiudere frequentemente le tabelle. Questi parametri influenzano il consumo di memoria sull'istanza. **conversione da HEAP a myISAM** La query sta convertendo una tabella temporanea da memoria a su disco. Questa conversione è necessaria perché le tabelle temporanee create da MySQL nelle fasi intermedie dell'elaborazione delle query sono diventate troppo grandi per la memoria. Verifica i valori di `tmp_table_size` e `max_heap_table_size`. Nelle versioni successive, il nome dello stato del thread è `converting HEAP to ondisk`. **conversione di HEAP in ondisk** Il thread sta convertendo una tabella temporanea interna da una tabella in memoria a una tabella su disco. **copia nella tabella tmp** Il thread sta elaborando un'istruzione `ALTER TABLE`. Questo stato si verifica dopo che la tabella con la nuova struttura è stata creata ma prima che le righe vengano copiate. Per un thread in questo stato, è possibile utilizzare lo schema delle prestazioni per ottenere informazioni sullo stato di avanzamento dell'operazione di copia. **creazione di indice di ordinamento** Aurora MySQL sta eseguendo un ordinamento perché non può utilizzare un indice esistente per soddisfare la clausola `ORDER BY` o `GROUP BY` di una query. Per ulteriori informazioni, consulta [creazione di indice di ordinamento](ams-states.sort-index.md). **Creazione di tabelle** Il thread sta creando una tabella permanente o temporanea. **commit ritardato ok fatto** Un commit asincrono in Aurora MySQL ha ricevuto un riconoscimento ed è completo. **ritardato commit ok avviato** Il thread Aurora MySQL ha avviato il processo di commit asincrono ma è in attesa di un riconoscimento. Di solito questo è il tempo di commit autentico di una transazione. **invio ritardato ok fatto** Un thread di lavoro Aurora MySQL collegato a una connessione può essere liberato mentre viene inviata una risposta al client. Il thread può iniziare altri lavori. Lo stato `delayed send ok` significa che la conferma asincrona al client è stata completata. **invio ritardato ok avviato** Un thread di lavoro Aurora MySQL ha inviato una risposta asincrona a un client ed è ora libero di lavorare per altre connessioni. La transazione ha avviato un processo di commit asincrono che non è ancora stato riconosciuto. **executing** Il thread ha iniziato a eseguire un'istruzione. **liberazione elementi** Il thread ha eseguito un comando. Alcuni liberazioni degli elementi eseguiti durante questo stato coinvolgono la cache delle query. Questo stato è solitamente seguito dalla pulizia. **init** Questo stato si verifica prima dell'inizializzazione di `ALTER TABLE`,`DELETE`,`INSERT`,`SELECT`, oppure istruzioni `UPDATE`. Le azioni in questo stato includono lo svuotamento del log binario o del log InnoDB e alcune operazioni di pulizia della cache delle query. **Source has sent all binlog to replica; waiting for more updates** Il nodo primario ha terminato la sua parte della replica. Il thread è in attesa di eseguire altre query in modo che possa scrivere nel log binario (binlog). **apertura tabella** Il thread sta tentando di aprire una tabella. Questa operazione è veloce a meno che un'istruzione `ALTER TABLE` o `LOCK TABLE` debba finire o superare il valore di `table_open_cache`. **Ottimizzazione** Il server sta eseguendo le ottimizzazioni iniziali per una query. **preparazione** Questo stato si verifica durante l'ottimizzazione delle query. **fine query** Questo stato si verifica dopo l'elaborazione di una query ma prima dello stato di liberazione degli elementi. **rimozione di duplicati** Aurora MySQL non è riuscita a ottimizzare un'operazione `DISTINCT` nella fase iniziale di una query. Aurora MySQL deve rimuovere tutte le righe duplicate prima di inviare il risultato al client. **ricerca di righe per l'aggiornamento** Il thread sta trovando tutte le righe corrispondenti prima di aggiornarle. Questa fase è necessaria se il `UPDATE` sta cambiando l'indice utilizzato dal motore per trovare le righe. **invio dell'evento binlog a slave** Il thread ha letto un evento dal log binario e lo sta inviando alla replica. **invio di risultati memorizzati nella cache al client** Il server sta prendendo il risultato di una query dalla cache delle query e la invia al client. **Invio dei dati** Il thread sta leggendo ed elaborando le righe per un'istruzione `SELECT` ma non ha ancora iniziato a inviare dati al client. Il processo sta identificando quali pagine contengono i risultati necessari per soddisfare la query. Per ulteriori informazioni, consulta [invio dei dati](ams-states.sending-data.md). **invio al client** Il server sta scrivendo un pacchetto sul client. Nelle versioni precedenti di MySQL, questo evento di attesa è stato etichettato `writing to net`. **avvio in corso** Questa è la prima fase all'inizio dell'esecuzione dell'istruzione. **statistiche** Il server sta calcolando le statistiche per sviluppare un piano di esecuzione delle query. Se un thread è in questo stato per un lungo periodo, il server è probabilmente associato a disco durante l'esecuzione di altri lavori. **archiviazione dei risultati nella cache delle query** Il server sta memorizzando il risultato di una query nella cache delle query. **blocco del sistema** Il thread ha chiamato `mysql_lock_tables`, ma lo stato del thread non è stato aggiornato dalla chiamata. Questo stato generale si verifica per molte ragioni. **aggiorna** Il thread si sta preparando per iniziare ad aggiornare la tabella. **aggiornamento** Il thread sta cercando righe e le sta aggiornando. **blocco utente** Il thread ha emesso una chiamata `GET_LOCK`. Il thread ha richiesto un blocco consultivo e lo sta aspettando o sta pianificando di richiederlo. **in attesa di ulteriori aggiornamenti** Il nodo primario ha terminato la sua parte della replica. Il thread è in attesa di eseguire altre query in modo che possa scrivere nel log binario (binlog). **in attesa del blocco dei metadati dello schema** Questa è un'attesa per un blocco dei metadati. **in attesa del blocco dei metadati della funzione memorizzata** Questa è un'attesa per un blocco dei metadati. **in attesa del blocco dei metadati della procedura archiviata** Questa è un'attesa per un blocco dei metadati. **in attesa dello scarico della tabella** Il thread sta eseguendo `FLUSH TABLES` e sta aspettando che tutti i thread chiudano le loro tabelle. Oppure il thread ha ricevuto una notifica che la struttura sottostante per una tabella è cambiata, quindi deve riaprire la tabella per ottenere la nuova struttura. Per riaprire la tabella, il thread deve attendere che tutti gli altri thread abbiano chiuso la tabella. Questa notifica avviene se un altro thread ha utilizzato una delle seguenti istruzioni sulla tabella: `FLUSH TABLES`,`ALTER TABLE`,`RENAME TABLE`,`REPAIR TABLE`,`ANALYZE TABLE`, oppure `OPTIMIZE TABLE`. **in attesa di blocco a livello tabella** Una sessione tiene un blocco su un tavolo mentre un'altra sessione tenta di acquisire lo stesso blocco sulla stessa tabella. **in attesa del blocco dei metadati della tabella** Aurora MySQL utilizza il blocco dei metadati per gestire l'accesso simultaneo agli oggetti del database e garantire la coerenza dei dati. In questo evento di attesa, una sessione tiene un blocco di metadati su una tabella mentre un'altra sessione tenta di acquisire lo stesso blocco sulla stessa tabella. Quando lo schema delle prestazioni è abilitato, questo stato del thread viene segnalato come evento di attesa `synch/cond/sql/MDL_context::COND_wait_status`. **scrittura su rete** Il server sta scrivendo un pacchetto sulla rete. Nelle versioni successive di MySQL, questo evento di attesa è etichettato `Sending to client`. # Livelli di isolamento di Aurora MySQL Scopri come le istanze database in un cluster Aurora MySQL implementano la proprietà di isolamento del database. In questo argomento viene spiegato come il comportamento predefinito di Aurora MySQL si bilancia tra coerenza rigorosa e prestazioni elevate. Puoi utilizzare queste informazioni per decidere quando modificare le impostazioni predefinite in base alle caratteristiche del tuo carico di lavoro. ## Livelli di isolamento disponibili per le istanze di scrittura È possibile utilizzare i livelli di isolamento `REPEATABLE READ`, `READ COMMITTED`, `READ UNCOMMITTED` e `SERIALIZABLE` sull'istanza primaria di un cluster di database Aurora MySQL. Questi livelli di isolamento funzionano allo stesso modo in Aurora MySQL e in RDS for MySQL. ## Livello di isolamento REPEATABLE READ per le istanze di lettura Per impostazione predefinita, le istanze database Aurora MySQL configurate come repliche di Aurora di sola lettura utilizzano sempre il livello di isolamento `REPEATABLE READ`. Queste istanze database ignorano qualsiasi istruzione `SET TRANSACTION ISOLATION LEVEL` e continuano a usare il livello di isolamento `REPEATABLE READ`. ## Livello di isolamento READ COMMITTED per le istanze di lettura Se l'applicazione include un carico di lavoro ad alta intensità di scrittura nell'istanza primaria e query a esecuzione prolungata nelle repliche di Aurora, è possibile che si verifichi un notevole ritardo di eliminazione. Un *ritardo di eliminazione* si verifica quando la garbage collection interna è bloccata da query a esecuzione prolungata. Il sintomo è un valore elevato per `history list length` nell'output del comando `SHOW ENGINE INNODB STATUS`. È possibile monitorare questo valore utilizzando il parametro `RollbackSegmentHistoryListLength` in CloudWatch. Un notevole ritardo dell'eliminazione può ridurre l'efficacia degli indici secondari, diminuire le prestazioni complessive delle query e usare inutilmente lo spazio di archiviazione. Se si verificano questi problemi, puoi usare l'impostazione di configurazione a livello di sessione Aurora MySQL, `aurora_read_replica_read_committed`, per utilizzare il livello di isolamento `READ COMMITTED` nelle repliche di Aurora. L'applicazione di questa impostazione può aiutare a ridurre i rallentamenti e lo spazio usato inutilmente che possono derivare dall'esecuzione di query a esecuzione prolungata contemporaneamente alle transazioni che modificano le tabelle. Prima di usare questa impostazione, ti consigliamo di comprendere il funzionamento di Aurora MySQL specifico dell'isolamento `READ COMMITTED`. Il comportamento `READ COMMITTED` della replica di Aurora è conforme allo standard ANSI SQL. Tuttavia, l'isolamento è meno restrittivo del comportamento `READ COMMITTED` tipico di MySQL che potresti già conoscere. Pertanto, potresti vedere risultati diversi per la query in `READ COMMITTED` su una replica di lettura di Aurora MySQL rispetto alla stessa query in `READ COMMITTED` nell'istanza primaria Aurora MySQL o in RDS per MySQL. Potresti utilizzare l'impostazione `aurora_read_replica_read_committed` per questi casi d'uso, come un report completo che esegue la scansione di un database molto grande. Potresti invece evitarla per brevi query con piccoli set di risultati, dove la precisione e la ripetibilità sono importanti. Il livello di isolamento `READ COMMITTED` non è disponibile per le sessioni all'interno di un cluster secondario in un Aurora Global Database che utilizzano la funzionalità di inoltro di scrittura. Per informazioni sull'inoltro di scrittura, consulta [Utilizzo dell'inoltro di scrittura in un database globale Amazon Aurora](aurora-global-database-write-forwarding.md). ### Utilizzo di READ COMMITTED per le letture Per usare il livello di isolamento `READ COMMITTED` per le repliche di Aurora, configura l'impostazione `aurora_read_replica_read_committed` su `ON`. Usa questa impostazione a livello di sessione mentre è connessa a una replica di Aurora specifica. Per farlo, esegui i comandi SQL seguenti. ``` set session aurora_read_replica_read_committed = ON; set session transaction isolation level read committed; ``` Puoi usare temporaneamente questa impostazione di configurazione per eseguire query interattive una tantum. Potresti anche voler eseguire un'applicazione per la creazione di report o l'analisi dei dati che beneficia del livello di isolamento `READ COMMITTED`, lasciando invariata l'impostazione predefinita per altre applicazioni. Quando l'impostazione `aurora_read_replica_read_committed` è attivata, usa il comando `SET TRANSACTION ISOLATION LEVEL` per specificare il livello di isolamento per le transazioni appropriate. ``` set transaction isolation level read committed; ``` ### Differenze nel comportamento di READ COMMITTED nelle repliche di Aurora L'impostazione `aurora_read_replica_read_committed` rende il livello di isolamento `READ COMMITTED` disponibile per una replica di Aurora con un comportamento coerente che viene ottimizzato per le transazioni a esecuzione prolungata. Il livello di isolamento `READ COMMITTED` nelle repliche di Aurora ha un isolamento meno restrittivo di quello nelle istanze primarie di Aurora. Per questo motivo, abilita l'impostazione solo in repliche di Aurora in cui sai che le query possono accettare la possibilità di determinati tipi di risultati incoerenti. Le tue query possono riscontrare alcuni tipi di anomalie di lettura quando l'impostazione `aurora_read_replica_read_committed` è attivata. Due tipi di anomalie sono particolarmente importanti per comprendere e gestire il codice dell'applicazione. Una *lettura non ripetibile* si verifica quando viene eseguita un'altra transazione durante l'esecuzione della query. Una query a esecuzione prolungata può visualizzare dati diversi all'inizio della query rispetto a quelli visualizzati alla fine. Una *lettura fantasma* si verifica quando altre transazioni causano la riorganizzazione delle righe esistenti mentre la query è in esecuzione e una o più righe vengono lette due volte dalla query. Le query potrebbero presentare conteggi di riga incoerenti a seguito delle letture fantasma. Le tue query potrebbero anche restituire risultati incompleti o incoerenti a causa delle letture non ripetibili. Ad esempio, supponiamo che un'operazione di join si riferisca alle tabelle che sono modificate contemporaneamente dalle istruzioni SQL come `INSERT` o `DELETE`. In questo caso, la query di join potrebbe leggere una riga da una tabella ma non la riga corrispondente da un'altra tabella. Lo standard ANSI SQL consente entrambi questi comportamenti per il livello di isolamento `READ COMMITTED`. Tuttavia, questi comportamenti sono diversi dalla tipica implementazione di MySQL di `READ COMMITTED`. Pertanto, prima di abilitare l'impostazione `aurora_read_replica_read_committed`, controlla qualsiasi codice SQL esistente per verificare se funziona come previsto nel modello di coerenza più flessibile. Il conteggio delle righe e altri risultati potrebbero non essere propriamente coerenti nel livello di isolamento `READ COMMITTED` mentre questa impostazione è abilitata. Pertanto, in genere abiliti l'impostazione solo durante l'esecuzione di query analitiche che aggregano grandi quantità di dati e non richiedono la precisione assoluta. Se non hai questo tipo di query a esecuzione prolungata insieme a un carico di lavoro ad alta intensità di scrittura, probabilmente non è necessaria l'impostazione `aurora_read_replica_read_committed`. Senza la combinazione di query a esecuzione prolungata e carico di lavoro ad alta intensità di scrittura, è improbabile che si verifichino problemi con la lunghezza dell'elenco della cronologia. **Example Query che mostrano il comportamento di isolamento per READ COMMITTED nelle repliche di Aurora** L'esempio seguente mostra come le query `READ COMMITTED` in una replica di Aurora potrebbero restituire risultati non ripetibili se le transazioni modificano contemporaneamente le tabelle associate. La tabella `BIG_TABLE` contiene 1 milione di righe prima dell'inizio di qualsiasi query. Altre istruzioni DML (Data Manipulation Language) aggiungono, rimuovono o modificano le righe mentre sono in esecuzione. Le query nell'istanza primaria Aurora nel livello di isolamento `READ COMMITTED` producono risultati prevedibili. Tuttavia, il sovraccarico di mantenere la visualizzazione di lettura coerente per la durata di ogni query a esecuzione prolungata può portare a costose operazioni di garbage collection in un secondo momento. Le query nella replica di Aurora nel livello di isolamento `READ COMMITTED` sono ottimizzate per ridurre al minimo questo sovraccarico di garbage collection. Il compromesso sta nei risultati che possono variare a seconda che le query recuperino o meno le righe aggiunte, rimosse o riorganizzate dalle transazioni che eseguono il commit mentre la query è in esecuzione. Le query possono prendere in considerazione queste righe, ma non sono obbligate a farlo. A scopo dimostrativo, le query controllano solo il numero di righe nella tabella utilizzando la funzione `COUNT(*)`. | Orario | Istruzione DML nell'istanza primaria Aurora | Query nell'istanza primaria Aurora con READ COMMITTED | Query nella replica di Aurora con READ COMMITTED | | --- | --- | --- | --- | | T1 | INSERT INTO big\$1table SELECT \$1 FROM other\$1table LIMIT 1000000; COMMIT; | | | | T2 | | Q1: SELECT COUNT(\$1) FROM big\$1table; | Q2: SELECT COUNT(\$1) FROM big\$1table; | | T3 | INSERT INTO big\$1table (c1, c2) VALUES (1, 'one more row'); COMMIT; | | | | T4 | | Se Q1 finisce ora, il risultato è 1.000.000. | Se Q2 finisce ora, il risultato è 1.000.000 o 1.000.001. | | T5 | DELETE FROM big\$1table LIMIT 2; COMMIT; | | | | T6 | | Se Q1 finisce ora, il risultato è 1.000.000. | Se Q2 finisce ora, il risultato è 1.000.000 o 1.000.001 o 999.999 o 999.998. | | T7 | UPDATE big\$1table SET c2 = CONCAT(c2,c2,c2); COMMIT; | | | | T8 | | Se Q1 finisce ora, il risultato è 1.000.000. | Se Q2 finisce ora, il risultato è 1.000.000 o 1.000.001 o 999.999 oppure possibilmente un numero più alto. | | T9 | | Q3: SELECT COUNT(\$1) FROM big\$1table; | Q4: SELECT COUNT(\$1) FROM big\$1table; | | T10 | | Se Q3 finisce ora, il risultato è 999.999. | Se Q4 finisce ora, il risultato è 999.999. | | T11 | | Q5: SELECT COUNT(\$1) FROM parent\$1table p JOIN child\$1table c ON (p.id = c.id) WHERE p.id = 1000; | Q6: SELECT COUNT(\$1) FROM parent\$1table p JOIN child\$1table c ON (p.id = c.id) WHERE p.id = 1000; | | T12 | INSERT INTO parent\$1table (id, s) VALUES (1000, 'hello'); INSERT INTO child\$1table (id, s) VALUES (1000, 'world'); COMMIT; | | | | T13 | | Se Q5 finisce ora, il risultato è 0. | Se Q6 finisce ora, il risultato è 0 o 1. | Se le query finiscono rapidamente, prima che qualsiasi altra transazione esegua istruzioni e commit DML, i risultati sono prevedibili e uguali tra l'istanza primaria e la replica di Aurora. Esaminiamo in dettaglio le differenze di comportamento, a partire dalla prima query. I risultati di Q1 sono prevedibili perché `READ COMMITTED` nell'istanza primaria usa un modello di consistenza elevata simile al livello di isolamento `REPEATABLE READ`. I risultati per Q2 possono variare a seconda delle transazioni sottoposte al commit durante l'esecuzione della query. Ad esempio, supponiamo che altre transazioni eseguano istruzioni DML ed eseguano il commit mentre le query sono in esecuzione. In questo caso, la query nella replica di Aurora con il livello di isolamento `READ COMMITTED` potrebbe o meno prendere in considerazione le modifiche. I conteggi delle righe non sono prevedibili come nel livello di isolamento `REPEATABLE READ`. Inoltre, non sono prevedibili come le query in esecuzione sotto il livello di isolamento `READ COMMITTED` nell'istanza primaria o in un'istanza RDS for MySQL. L'istruzione `UPDATE` a T7 in effetti non cambia il numero di righe della tabella. Tuttavia, modificando la lunghezza di una colonna di lunghezza variabile, questa istruzione può causare la riorganizzazione interna delle righe. Una transazione `READ COMMITTED` a esecuzione prolungata potrebbe visualizzare la versione precedente di una riga e, successivamente, all'interno della stessa query, visualizzare la nuova versione della stessa riga. La query può anche ignorare sia la versione precedente che quella nuova della riga, quindi il conteggio delle righe potrebbe essere diverso da quello previsto. I risultati di Q5 e Q6 potrebbero essere identici o leggermente diversi. La query Q6 nella replica di Aurora in `READ COMMITTED` è in grado di vedere, ma non è obbligata a vedere, le nuove righe che vengono confermate mentre la query è in esecuzione. Potrebbe anche vedere la riga di una tabella, ma non dell'altra tabella. Se la query di join non trova una riga corrispondente in entrambe le tabelle, restituisce un conteggio pari a zero. Se la query trova entrambe le nuove righe in `PARENT_TABLE` e `CHILD_TABLE`, la query restituisce un conteggio pari a uno. In una query a esecuzione prolungata, le ricerche dalle tabelle unite potrebbero avvenire in momenti ampiamente separati. Queste differenze di comportamento dipendono dal momento in cui vengono eseguite le transazioni e vengono elaborate dalle query le righe della tabella sottostante. Pertanto, è molto probabile che si notino tali differenze nelle query di report che richiedono minuti o ore e che vengono eseguite in cluster Aurora che elaborano contemporaneamente transazioni OLTP. Questi sono i tipi di carichi di lavoro misti che beneficiano maggiormente del livello di isolamento `READ COMMITTED` nelle repliche di Aurora. # Suggerimenti di Aurora MySQL È possibile utilizzare i suggerimenti SQL con le query Aurora MySQL per ottimizzare le prestazioni. È inoltre possibile utilizzare i suggerimenti per impedire che i piani di esecuzione per query importanti vengano modificati a causa di condizioni imprevedibili. **Suggerimento** Per verificare l'effetto di un suggerimento su una query, esaminare il piano di query prodotto dall'istruzione `EXPLAIN`. Confrontare i piani di query con e senza il suggerimento. In Aurora MySQL versione 3, puoi usare tutti i suggerimenti disponibili in MySQL Community Edition 8.0. Per ulteriori informazioni su questi suggerimenti, consulta [Suggerimenti di ottimizzazione](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) nel *Manuale di riferimento MySQL*. Questi suggerimenti sono disponibili in Aurora MySQL versione 2. Questi suggerimenti si applicano alle query che utilizzano la funzionalità hash join in Aurora MySQL versione 2, in particolare alle query che utilizzano l'ottimizzazione delle query parallele. **PQ, NO\$1PQ** Specifica se forzare l'ottimizzatore a utilizzare una query parallela per tabella o per query. `PQ` forza l'ottimizzazione a utilizzare la query parallela per le tabelle specificate o per l'intera query (blocco). `NO_PQ` impedisce all'ottimizzazione di utilizzare la query parallela per le tabelle specificate o per l'intera query (blocco). Questo suggerimento è disponibile in Aurora MySQL versione 2.11 e successive. Gli esempi seguenti mostrano come utilizzare questo suggerimento. La specificazione del nome di una tabella impone all'ottimizzazione di applicare il suggerimento `PQ/NO_PQ` solo su quelle tabelle selezionate. La mancata specificazione del nome di una tabella impone il suggerimento `PQ/NO_PQ` su tutte le tabelle interessate dal blocco di query. ``` EXPLAIN SELECT /*+ PQ() */ f1, f2 FROM num1 t1 WHERE f1 > 10 and f2 < 100; EXPLAIN SELECT /*+ PQ(t1) */ f1, f2 FROM num1 t1 WHERE f1 > 10 and f2 < 100; EXPLAIN SELECT /*+ PQ(t1,t2) */ f1, f2 FROM num1 t1, num1 t2 WHERE t1.f1 = t2.f21; EXPLAIN SELECT /*+ NO_PQ() */ f1, f2 FROM num1 t1 WHERE f1 > 10 and f2 < 100; EXPLAIN SELECT /*+ NO_PQ(t1) */ f1, f2 FROM num1 t1 WHERE f1 > 10 and f2 < 100; EXPLAIN SELECT /*+ NO_PQ(t1,t2) */ f1, f2 FROM num1 t1, num1 t2 WHERE t1.f1 = t2.f21; ``` **HASH\$1JOIN, NO\$1HASH\$1JOIN** Attiva o disattiva la possibilità dell'ottimizzazione di query parallele di scegliere se utilizzare il metodo di ottimizzazione hash join per una query. `HASH_JOIN` consente all'ottimizzazione di utilizzare hash join se tale meccanismo è più efficiente. `NO_HASH_JOIN` impedisce all'ottimizzazione di utilizzare hash join per la query. Questo suggerimento è disponibile in Aurora MySQL versione 2.08 e successive. Non ha alcun effetto in Aurora MySQL versione 3. Gli esempi seguenti mostrano come utilizzare questo suggerimento. ``` EXPLAIN SELECT/*+ HASH_JOIN(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; EXPLAIN SELECT /*+ NO_HASH_JOIN(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; ``` **HASH\$1JOIN\$1PROBING, NO\$1HASH\$1JOIN\$1PROBING** In una query hash join, indica se utilizzare la tabella specificata per il lato probe del join. La query verifica se i valori delle colonne della tabella di generazione esistono nella tabella probe, anziché leggerne l'intero contenuto. È possibile utilizzare `HASH_JOIN_PROBING` e `HASH_JOIN_BUILDING` per specificare la modalità di elaborazione delle query di join hash senza riordinare le tabelle all'interno del testo della query. Questo suggerimento è disponibile in Aurora MySQL versione 2.08 e successive. Non ha alcun effetto in Aurora MySQL versione 3. Gli esempi seguenti mostrano come utilizzare questo suggerimento. Specificare il suggerimento `HASH_JOIN_PROBING` per la tabella `T2` ha lo stesso effetto di specificare `NO_HASH_JOIN_PROBING` per la tabella `T1`. ``` EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_PROBING(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_PROBING(t1) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; ``` **HASH\$1JOIN\$1BUILDING, NO\$1HASH\$1JOIN\$1BUILDING** In una query hash join, indica se utilizzare la tabella specificata per il lato build del join. La query elabora tutte le righe di questa tabella per creare l'elenco dei valori di colonna per un riferimento incrociato con l'altra tabella. È possibile utilizzare `HASH_JOIN_PROBING` e `HASH_JOIN_BUILDING` per specificare la modalità di elaborazione delle query di join hash senza riordinare le tabelle all'interno del testo della query. Questo suggerimento è disponibile in Aurora MySQL versione 2.08 e successive. Non ha alcun effetto in Aurora MySQL versione 3. L'esempio seguente mostra come utilizzare questo suggerimento. Specificare il suggerimento `HASH_JOIN_BUILDING` per la tabella `T2` ha lo stesso effetto di specificare `NO_HASH_JOIN_BUILDING` per la tabella `T1`. ``` EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_BUILDING(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_BUILDING(t1) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; ``` **JOIN\$1FIXED\$1ORDER** Specifica che le tabelle della query vengono unite in base all'ordine in cui sono elencate nella query. È utile con le query che coinvolgono almeno tre tabelle. È inteso come un sostituto per il suggerimento MySQL `STRAIGHT_JOIN` ed è equivalente al suggerimento MySQL [JOIN\$1FIXED\$1ORDER](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html). Questo suggerimento è disponibile in Aurora MySQL versione 2.08 e successive. L'esempio seguente mostra come utilizzare questo suggerimento. ``` EXPLAIN SELECT /*+ JOIN_FIXED_ORDER() */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id); ``` **JOIN\$1ORDER** Specifica l'ordine join per le tabelle nella query. È utile con le query che coinvolgono almeno tre tabelle. È equivalente al suggerimento MySQL [JOIN\$1ORDER](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html). Questo suggerimento è disponibile in Aurora MySQL versione 2.08 e successive. L'esempio seguente mostra come utilizzare questo suggerimento. ``` EXPLAIN SELECT /*+ JOIN_ORDER (t4, t2, t1, t3) */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id); ``` **JOIN\$1PREFIX** Specifica le tabelle da inserire per prime nell'ordine join. È utile con le query che coinvolgono almeno tre tabelle. È equivalente al suggerimento MySQL [JOIN\$1PREFIX](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html). Questo suggerimento è disponibile in Aurora MySQL versione 2.08 e successive. L'esempio seguente mostra come utilizzare questo suggerimento. ``` EXPLAIN SELECT /*+ JOIN_PREFIX (t4, t2) */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id); ``` **JOIN\$1SUFFIX** Specifica le tabelle da inserire per ultime nell'ordine join. È utile con le query che coinvolgono almeno tre tabelle. È equivalente al suggerimento MySQL [JOIN\$1SUFFIX](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html). Questo suggerimento è disponibile in Aurora MySQL versione 2.08 e successive. L'esempio seguente mostra come utilizzare questo suggerimento. ``` EXPLAIN SELECT /*+ JOIN_SUFFIX (t1) */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id); ``` Per informazioni sull'utilizzo delle query di hash join, vedere [Ottimizzazione di grandi query di join Aurora MySQL con hash join](AuroraMySQL.BestPractices.Performance.md#Aurora.BestPractices.HashJoin). # Informazioni di riferimento sulle stored procedure Aurora MySQL Puoi gestire il cluster di database Aurora MySQL tramite la chiamata delle stored procedure integrate. **Topics** + [Raccolta e gestione della cronologia dello stato globale](mysql-stored-proc-gsh.md) + [Configurazione, avvio e arresto della replica dei log binari (binlog)](mysql-stored-proc-replicating.md) + [Terminare una sessione o una query](mysql-stored-proc-ending.md) + [Replica delle transazioni utilizzando GTIDs](mysql-stored-proc-gtid.md) + [Rotazione dei log di query](mysql-stored-proc-logging.md) + [Impostazione e visualizzazione della configurazione dei log binari](mysql-stored-proc-configuring.md) # Raccolta e gestione della cronologia dello stato globale Amazon RDS fornisce una serie di procedure che acquisiscono uno snapshot dei valori di queste variabili di stato nel tempo e li scrivono in una tabella insieme alle modifiche eseguite dopo l'ultimo snapshot. Questa infrastruttura si chiama cronologia di stato globale. Per ulteriori informazioni, consulta [Gestione della cronologia di stato globale](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH). Le seguenti stored procedure gestiscono il modo in cui la cronologia di stato globale viene raccolta e gestita. **Topics** + [mysql.rds\$1collect\$1global\$1status\$1history](#mysql_rds_collect_global_status_history) + [mysql.rds\$1disable\$1gsh\$1collector](#mysql_rds_disable_gsh_collector) + [mysql.rds\$1disable\$1gsh\$1rotation](#mysql_rds_disable_gsh_rotation) + [mysql.rds\$1enable\$1gsh\$1collector](#mysql_rds_enable_gsh_collector) + [mysql.rds\$1enable\$1gsh\$1rotation](#mysql_rds_enable_gsh_rotation) + [mysql.rds\$1rotate\$1global\$1status\$1history](#mysql_rds_rotate_global_status_history) + [mysql.rds\$1set\$1gsh\$1collector](#mysql_rds_set_gsh_collector) + [mysql.rds\$1set\$1gsh\$1rotation](#mysql_rds_set_gsh_rotation) ## mysql.rds\$1collect\$1global\$1status\$1history Acquisisce uno snapshot on demand per la cronologia di stato globale. ### Sintassi ``` CALL mysql.rds_collect_global_status_history; ``` ## mysql.rds\$1disable\$1gsh\$1collector Disabilita gli snapshot creati mediante la cronologia di stato globale. ### Sintassi ``` CALL mysql.rds_disable_gsh_collector; ``` ## mysql.rds\$1disable\$1gsh\$1rotation Disattiva la rotazione della tabella `mysql.global_status_history`. ### Sintassi ``` CALL mysql.rds_disable_gsh_rotation; ``` ## mysql.rds\$1enable\$1gsh\$1collector Abilita la cronologia di stato globale per acquisire snapshot predefiniti agli intervalli specificati da `rds_set_gsh_collector`. ### Sintassi ``` CALL mysql.rds_enable_gsh_collector; ``` ## mysql.rds\$1enable\$1gsh\$1rotation Attiva la rotazione dei contenuti della tabella `mysql.global_status_history` su `mysql.global_status_history_old` agli intervalli specificati da `rds_set_gsh_rotation`. ### Sintassi ``` CALL mysql.rds_enable_gsh_rotation; ``` ## mysql.rds\$1rotate\$1global\$1status\$1history Ruota i contenuti della tabella `mysql.global_status_history` su `mysql.global_status_history_old` a richiesta. ### Sintassi ``` CALL mysql.rds_rotate_global_status_history; ``` ## mysql.rds\$1set\$1gsh\$1collector Specifica l'intervallo, espresso in minuti, tra gli snapshot acquisiti mediante la cronologia di stato globale. ### Sintassi ``` CALL mysql.rds_set_gsh_collector(intervalPeriod); ``` ### Parametri *intervalPeriod* L'intervallo, in minuti, tra gli snapshot. Il valore predefinito è `5`. ## mysql.rds\$1set\$1gsh\$1rotation Specifica l’intervallo, in giorni, tra le conversioni della tabella `mysql.global_status_history`. ### Sintassi ``` CALL mysql.rds_set_gsh_rotation(intervalPeriod); ``` ### Parametri *intervalPeriod* L'intervallo, in giorni, tra le conversioni delle tabelle. Il valore predefinito è `7`. # Configurazione, avvio e arresto della replica dei log binari (binlog) Puoi chiamare le seguenti procedure archiviate mentre sei connesso all'istanza primaria in un cluster Aurora MySQL. Queste procedure controllano il modo in cui le transazioni vengono replicate da un database esterno a Aurora MySQL o da Aurora MySQL a un database esterno. **Topics** + [mysql.rds\$1disable\$1session\$1binlog (Aurora MySQL versione 2)](#mysql_rds_disable_session_binlog) + [mysql.rds\$1enable\$1session\$1binlog (Aurora MySQL versione 2)](#mysql_rds_enable_session_binlog) + [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) + [mysql.rds\$1next\$1master\$1log](#mysql_rds_next_master_log) + [mysql.rds\$1next\$1source\$1log (Aurora MySQL versione 3)](#mysql_rds_next_source_log) + [mysql.rds\$1remove\$1binlog\$1ssl\$1material](#mysql_rds_remove_binlog_ssl_material) + [mysql.rds\$1reset\$1external\$1master (Aurora MySQL versione 2)](#mysql_rds_reset_external_master) + [mysql.rds\$1reset\$1external\$1source (Aurora MySQL versione 3)](#mysql_rds_reset_external_source) + [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versione 3)](#mysql_rds_set_binlog_source_ssl) + [mysql.rds\$1set\$1external\$1master (Aurora MySQL versione 2)](#mysql_rds_set_external_master) + [mysql.rds\$1set\$1external\$1source (Aurora MySQL versione 3)](#mysql_rds_set_external_source) + [mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (Aurora MySQL versione 2)](#mysql_rds_set_external_master_with_auto_position) + [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL versione 3)](#mysql_rds_set_external_source_with_auto_position) + [mysql.rds\$1set\$1master\$1auto\$1position (RDS )](#mysql_rds_set_master_auto_position) + [mysql.rds\$1set\$1read\$1only (Aurora MySQL versione 3)](#mysql_rds_set_read_only) + [mysql.rds\$1set\$1session\$1binlog\$1format (Aurora MySQL versione 2)](#mysql_rds_set_session_binlog_format) + [mysql.rds\$1set\$1source\$1auto\$1position (Aurora MySQL versione 3)](#mysql_rds_set_source_auto_position) + [mysql.rds\$1skip\$1repl\$1error](#mysql_rds_skip_repl_error) + [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) + [mysql.rds\$1start\$1replication\$1until (Aurora MySQL versione 3)](#mysql_rds_start_replication_until) + [mysql.rds\$1stop\$1replication](#mysql_rds_stop_replication) ## mysql.rds\$1disable\$1session\$1binlog (Aurora MySQL versione 2) Disattiva la registrazione binaria per la sessione corrente impostando la variabile `sql_log_bin` su `OFF`. ### Sintassi ``` CALL mysql.rds_disable_session_binlog; ``` ### Parameters Nessuno ### Note per l’utilizzo Per un cluster di database Aurora MySQL, puoi chiamare questa procedura archiviata mentre sei connesso all’istanza primaria. Per Aurora, questa procedura è supportata per Aurora MySQL versione 2.12 e versioni successive compatibili con MySQL 5.7. **Nota** In Aurora MySQL versione 3, è possibile utilizzare il seguente comando per disabilitare la registrazione di log binari per la sessione corrente se si dispone del privilegio `SESSION_VARIABLES_ADMIN`: ``` SET SESSION sql_log_bin = OFF; ``` ## mysql.rds\$1enable\$1session\$1binlog (Aurora MySQL versione 2) Attiva la registrazione binaria per la sessione corrente impostando la variabile `sql_log_bin` su `ON`. ### Sintassi ``` CALL mysql.rds_enable_session_binlog; ``` ### Parameters Nessuno ### Note per l’utilizzo Per un cluster di database Aurora MySQL, puoi chiamare questa procedura archiviata mentre sei connesso all’istanza primaria. Per Aurora, questa procedura è supportata per Aurora MySQL versione 2.12 e versioni successive compatibili con MySQL 5.7. **Nota** In Aurora MySQL versione 3, è possibile utilizzare il seguente comando per abilitare la registrazione di log binari per la sessione corrente se si dispone del privilegio `SESSION_VARIABLES_ADMIN`: ``` SET SESSION sql_log_bin = ON; ``` ## mysql.rds\$1import\$1binlog\$1ssl\$1material Importa il certificato dell'autorità di certificazione, il certificato client e la chiave client in un cluster di database Aurora MySQL. Le informazioni sono necessarie per la comunicazione SSL e la replica crittografata. **Nota** Attualmente, questa procedura è supportata per Aurora MySQL versione 2 (2.09.2, 2.10.0, 2.10.1 e 2.11.0) e versione 3 (3.01.1 e successive). ### Sintassi ``` CALL mysql.rds_import_binlog_ssl_material ( ssl_material ); ``` ### Parameters *ssl\$1material* Il payload JSON che contiene il contenuto dei seguenti file in formato .pem per un client MySQL: + «ssl\$1it»:»» *Certificate authority certificate* + «certificato SSL»:»» *Client certificate* + «chiave\$1ssl»:»» *Client key* ### Note per l’utilizzo Prepara la replica crittografata prima di eseguire questa procedura: + Se SSL non è abilitato sull’istanza database di origine MySQL esterna e non disponi di una chiave client e di un certificato client preparato, abilita SSL sul server di database MySQL e genera la chiave client e il certificato client necessari. + Se SSL è abilitato sull’istanza database di origine esterna, fornisci un certificato e una chiave client per il cluster database Aurora MySQL. Se non disponi di questi elementi, genera una nuova chiave e un nuovo certificato per il cluster di database Aurora MySQL. Per firmare il certificato client, devi avere la chiave autorità certificato che hai utilizzato per configurare SSL nell’istanza database di origine esterna MySQL. Per ulteriori informazioni, consulta [Creating SSL Certificates and Keys Using openssl](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html) nella documentazione MySQL. **Importante** Dopo aver preparato la replica crittografata, utilizza una connessione SSL per eseguire questa procedura. La chiave client non deve essere trasferita mediante una connessione non sicura. Questa procedura importa le informazioni SSL da un database MySQL esterno in un cluster di database Aurora MySQL. Le informazioni SSL sono in file in formato .pem che contengono le informazioni SSL per il cluster di database Aurora MySQL. Durante la replica crittografata, il cluster di database Aurora MySQL agisce come un client per il server di database MySQL. I certificati e le chiavi per il client Aurora MySQL sono in file in formato .pem. Puoi copiare le informazioni da questi file nel parametro `ssl_material` nel payload JSON corretto. Per supportare la replica crittografata, importa queste informazioni SSL nel cluster di database Aurora MySQL. Il payload JSON deve avere il formato seguente. ``` '{"ssl_ca":"-----BEGIN CERTIFICATE----- ssl_ca_pem_body_code -----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE----- ssl_cert_pem_body_code -----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY----- ssl_key_pem_body_code -----END RSA PRIVATE KEY-----\n"}' ``` ### Esempi L'esempio seguente importa le informazioni SSL in Aurora MySQL. Nei file in formato .pem, il codice del corpo è in genere più lungo del codice del corpo riportato nell'esempio. ``` call mysql.rds_import_binlog_ssl_material( '{"ssl_ca":"-----BEGIN CERTIFICATE----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END RSA PRIVATE KEY-----\n"}'); ``` ## mysql.rds\$1next\$1master\$1log Cambia la posizione del log dell'istanza database di origine all'inizio del successivo log binario nell'istanza database di origine. Utilizzate questa procedura solo se ricevete l'errore di replica 1236 I/O su una replica di lettura. ### Sintassi ``` CALL mysql.rds_next_master_log( curr_master_log ); ``` ### Parameters *curr\$1master\$1log* L'indice del file di log master corrente. Ad esempio, se il file corrente è denominato `mysql-bin-changelog.012345`, l’indice è 12345. Per determinare il nome del file di log master corrente, esegui il comando `SHOW REPLICA STATUS` e visualizza il campo `Master_Log_File`. ### Note per l’utilizzo La procedura `mysql.rds_next_master_log` deve essere eseguita dall’utente master. **avvertimento** Effettua la chiamata `mysql.rds_next_master_log` solo se la replica fallisce dopo un failover di un'istanza DB Multi-AZ che è l'origine della replica e il campo riporta l'errore 1236. `Last_IO_Errno` `SHOW REPLICA STATUS` I/O La chiamata di `mysql.rds_next_master_log` può comportare una perdita di dati nella replica di lettura se le transazioni nell’istanza di origine non sono state scritte nel log binario sul disco prima dell’evento di failover. ### Esempi Supponi che una replica di lettura Aurora MySQL non riesca. L’esecuzione di `SHOW REPLICA STATUS\G` nella replica di lettura restituisce il risultato seguente: ``` *************************** 1. row *************************** Replica_IO_State: Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com Source_User: MasterUser Source_Port: 3306 Connect_Retry: 10 Source_Log_File: mysql-bin-changelog.012345 Read_Source_Log_Pos: 1219393 Relay_Log_File: relaylog.012340 Relay_Log_Pos: 30223388 Relay_Source_Log_File: mysql-bin-changelog.012345 Replica_IO_Running: No Replica_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Source_Log_Pos: 30223232 Relay_Log_Space: 5248928866 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Source_SSL_Allowed: No Source_SSL_CA_File: Source_SSL_CA_Path: Source_SSL_Cert: Source_SSL_Cipher: Source_SSL_Key: Seconds_Behind_Master: NULL Source_SSL_Verify_Server_Cert: No Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.' Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Source_Server_Id: 67285976 ``` Il campo `Last_IO_Errno` mostra che l'istanza riceve l'errore I/O 1236. Il campo `Master_Log_File` mostra che il nome di file è `mysql-bin-changelog.012345`, il che significa che l'indice del file di log è `12345`. Per risolvere il problema, puoi chiamare `mysql.rds_next_master_log` con il seguente parametro: ``` CALL mysql.rds_next_master_log(12345); ``` ## mysql.rds\$1next\$1source\$1log (Aurora MySQL versione 3) Cambia la posizione del log dell'istanza database di origine all'inizio del successivo log binario nell'istanza database di origine. Utilizzare questa procedura solo se si riceve l' I/O errore di replica 1236 su una replica di lettura. ### Sintassi ``` CALL mysql.rds_next_source_log( curr_source_log ); ``` ### Parameters *curr\$1source\$1log* L'indice del file di log di origine corrente. Ad esempio, se il file corrente è denominato `mysql-bin-changelog.012345`, l’indice è 12345. Per determinare il nome del file di log di origine corrente, esegui il comando `SHOW REPLICA STATUS` e visualizza il campo `Source_Log_File`. ### Note per l’utilizzo L’utente amministrativo deve eseguire la procedura `mysql.rds_next_source_log`. **avvertimento** Effettua la chiamata `mysql.rds_next_source_log` solo se la replica fallisce dopo un failover di un'istanza DB Multi-AZ che è l'origine della replica e il campo riporta l'errore 1236. `Last_IO_Errno` `SHOW REPLICA STATUS` I/O La chiamata di `mysql.rds_next_source_log` può comportare una perdita di dati nella replica di lettura se le transazioni nell’istanza di origine non sono state scritte nel log binario sul disco prima dell’evento di failover. Si può diminuire la possibilità che si verifichi una situazione di questo tipo impostando i parametri dell’istanza di origine `sync_binlog` e `innodb_support_xa` su `1`, anche se ciò può compromettere le prestazioni. ### Esempi Supponi che una replica di lettura Aurora MySQL non riesca. L’esecuzione di `SHOW REPLICA STATUS\G` nella replica di lettura restituisce il risultato seguente: ``` *************************** 1. row *************************** Replica_IO_State: Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com Source_User: MasterUser Source_Port: 3306 Connect_Retry: 10 Source_Log_File: mysql-bin-changelog.012345 Read_Source_Log_Pos: 1219393 Relay_Log_File: relaylog.012340 Relay_Log_Pos: 30223388 Relay_Source_Log_File: mysql-bin-changelog.012345 Replica_IO_Running: No Replica_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Source_Log_Pos: 30223232 Relay_Log_Space: 5248928866 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Source_SSL_Allowed: No Source_SSL_CA_File: Source_SSL_CA_Path: Source_SSL_Cert: Source_SSL_Cipher: Source_SSL_Key: Seconds_Behind_Source: NULL Source_SSL_Verify_Server_Cert: No Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from source when reading data from binary log: 'Client requested source to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.' Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Source_Server_Id: 67285976 ``` Il campo `Last_IO_Errno` mostra che l'istanza riceve l'errore I/O 1236. Il campo `Source_Log_File` mostra che il nome di file è `mysql-bin-changelog.012345`, il che significa che l'indice del file di log è `12345`. Per risolvere il problema, puoi chiamare `mysql.rds_next_source_log` con il seguente parametro: ``` CALL mysql.rds_next_source_log(12345); ``` ## mysql.rds\$1remove\$1binlog\$1ssl\$1material Elimina il certificato dell'autorità di certificazione, il certificato client e la chiave client per la comunicazione SSL e la replica crittografata. Queste informazioni sono importate utilizzando [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material). ### Sintassi ``` CALL mysql.rds_remove_binlog_ssl_material; ``` ## mysql.rds\$1reset\$1external\$1master (Aurora MySQL versione 2) Riconfigura un'istanza database Aurora MySQL affinché non sia più una replica di lettura di un'istanza di MySQL in esecuzione all'esterno di Amazon RDS. **Importante** Per eseguire questa procedura, è necessario abilitare `autocommit`. Per abilitarlo, impostare il parametro `autocommit` su `1`. Per ulteriori informazioni sulla modifica dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md). ### Sintassi ``` CALL mysql.rds_reset_external_master; ``` ### Note per l’utilizzo La procedura `mysql.rds_reset_external_master` deve essere eseguita dall'utente master. Questa procedura deve essere eseguita sull’istanza database MySQL da rimuovere come replica di lettura di un’istanza MySQL eseguita esternamente a Amazon RDS. **Nota** Queste stored procedure sono fornite principalmente per abilitare la replica con le istanze MySQL eseguite esternamente a Amazon RDS. Ti consigliamo di usare le repliche Aurora per gestire la replica in un cluster database Aurora MySQL. Per informazioni sulla gestione della replica nei cluster database Aurora MySQL, consulta [Utilizzo delle repliche di Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas). Per ulteriori informazioni sull'uso della replica per importare dati da un'istanza di MySQL in esecuzione all'esterno di Aurora MySQL, consulta [Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)](AuroraMySQL.Replication.MySQL.md). ## mysql.rds\$1reset\$1external\$1source (Aurora MySQL versione 3) Riconfigura un'istanza database Aurora MySQL affinché non sia più una replica di lettura di un'istanza di MySQL in esecuzione all'esterno di Amazon RDS. **Importante** Per eseguire questa procedura, è necessario abilitare `autocommit`. Per abilitarlo, impostare il parametro `autocommit` su `1`. Per ulteriori informazioni sulla modifica dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md). ### Sintassi ``` CALL mysql.rds_reset_external_source; ``` ### Note per l’utilizzo L’utente amministrativo deve eseguire la procedura `mysql.rds_reset_external_source`. Questa procedura deve essere eseguita sull’istanza database MySQL da rimuovere come replica di lettura di un’istanza MySQL eseguita esternamente a Amazon RDS. **Nota** Queste stored procedure sono fornite principalmente per abilitare la replica con le istanze MySQL eseguite esternamente a Amazon RDS. Ti consigliamo di usare le repliche Aurora per gestire la replica in un cluster database Aurora MySQL. Per informazioni sulla gestione della replica nei cluster database Aurora MySQL, consulta [Utilizzo delle repliche di Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas). ## mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versione 3) Abilita la crittografia `SOURCE_SSL` per la replica binlog. Per ulteriori informazioni, consulta [CHANGE REPLICATION SOURCE TO statement](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html) nella documentazione MySQL. ### Sintassi ``` CALL mysql.rds_set_binlog_source_ssl(mode); ``` ### Parameters *mode* Valore che indica se la crittografia `SOURCE_SSL` è abilitata: + `0`: la crittografia `SOURCE_SSL` è disabilitata. Il valore predefinito è `0`. + `1`: la crittografia `SOURCE_SSL` è abilitata. È possibile configurare la crittografia utilizzando SSL o TLS. ### Note per l’utilizzo Questa procedura è supportata per Aurora MySQL versione 3.06 e successive. ## mysql.rds\$1set\$1external\$1master (Aurora MySQL versione 2) Configura un'istanza database Aurora MySQL come replica di lettura di un'istanza di MySQL in esecuzione all'esterno di Amazon RDS. La procedura `mysql.rds_set_external_master` è obsoleta e verrà rimossa in una versione futura. Usare invece `mysql.rds\$1set\$1external\$1source`. **Importante** Per eseguire questa procedura, è necessario abilitare `autocommit`. Per abilitarlo, impostare il parametro `autocommit` su `1`. Per ulteriori informazioni sulla modifica dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md). ### Sintassi ``` CALL mysql.rds_set_external_master ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption ); ``` ### Parameters *host\$1name* Il nome host o l'indirizzo IP dell'istanza di MySQL eseguita esternamente a Amazon RDS per diventare l’istanza database di origine. *host\$1port* La porta utilizzata dall'istanza di MySQL eseguita esternamente a Amazon RDS e da configurare come istanza database di origine. Se la configurazione della rete include la replica della porta Secure Shell (SSH) che converte il numero di porta, specifica il numero di porta esposto da SSH. *replication\$1user\$1name* L'ID di un utente con autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` nell'istanza di MySQL eseguita esternamente a Amazon RDS. Ti consigliamo di fornire un account utilizzato unicamente per la replica con l'istanza esterna. *replication\$1user\$1password* La password dell'ID utente specificata in `replication_user_name`. *mysql\$1binary\$1log\$1file\$1name* Il nome del log binario sull’istanza database di origine che contiene le informazioni relative alla replica. *mysql\$1binary\$1log\$1file\$1location* La posizione nel log binario `mysql_binary_log_file_name` a partire dalla quale la replica inizia a leggere le informazioni a essa relative. È possibile determinare il nome e la posizione del file binlog in esecuzione `SHOW MASTER STATUS` sull'istanza del database di origine. *ssl\$1encryption* Un valore che specifica se la crittografia Secure Socket Layer (SSL) è utilizzata sulla connessione di replica. 1 indica che la crittografia SSL deve essere utilizzata; 0 specifica che la crittografia non deve essere utilizzata. Il valore predefinito è 0. L’opzione `MASTER_SSL_VERIFY_SERVER_CERT` non è supportata. Questa opzione è impostata su 0, il che significa che la connessione è crittografata, ma i certificati non sono verificati. ### Note per l’utilizzo La procedura `mysql.rds_set_external_master` deve essere eseguita dall'utente master. Questa procedura deve essere eseguita sull’istanza database MySQL da configurare come replica di lettura di un’istanza MySQL eseguita esternamente a Amazon RDS. Prima di eseguire `mysql.rds_set_external_master`, devi configurare l’istanza di MySQL in esecuzione all’esterno di Amazon RDS come istanza database di origine. Per connetterti all'istanza MySQL in esecuzione all'esterno di Amazon RDS, devi specificare i valori di `replication_user_name` e `replication_user_password` che indicano un utente della replica dotato delle autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` per l'istanza esterna di MySQL. **Per configurare un'istanza esterna di MySQL come istanza database di origine** 1. Mediante il client MySQL scelto, eseguire la connessione all'istanza esterna di MySQL e creare un account utente da utilizzare per la replica. Di seguito è riportato un esempio di : **MySQL 5.7** ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **MySQL 8.0** ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED WITH mysql_native_password BY 'password'; ``` **Nota** Specifica una password diversa dal prompt mostrato qui come best practice per la sicurezza. 1. Nell’istanza esterna di MySQL, concedere i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` all’utente della replica. L’esempio seguente concede i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` su tutti i database per l’utente “repl\$1user” del dominio: **MySQL 5.7** ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **MySQL 8.0** ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'; ``` Per utilizzare la replica crittografata, configura l'istanza database di origine per utilizzare le connessioni SSL. Importa inoltre il certificato dell'autorità di certificazione, il certificato client e la chiave client nell'istanza database o nel cluster di database utilizzando la procedura [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material). **Nota** Queste stored procedure sono fornite principalmente per abilitare la replica con le istanze MySQL eseguite esternamente a Amazon RDS. Ti consigliamo di usare le repliche Aurora per gestire la replica in un cluster database Aurora MySQL. Per informazioni sulla gestione della replica nei cluster database Aurora MySQL, consulta [Utilizzo delle repliche di Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas). Dopo aver chiamato `mysql.rds_set_external_master` per configurare un’istanza database di Amazon RDS come replica di lettura, puoi chiamare [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) nella replica di lettura per avviare il processo di replica. Puoi chiamare [mysql.rds\$1reset\$1external\$1master (Aurora MySQL versione 2)](#mysql_rds_reset_external_master) per rimuovere la configurazione della replica di lettura. Quando `mysql.rds_set_external_master` viene chiamato, Amazon RDS registra l'ora, l'utente e un'operazione di `set master` nelle tabelle `mysql.rds_history` e `mysql.rds_replication_status`. ### Esempi Nel caso di esecuzione su un’istanza database MySQL, l’esempio seguente configura l’istanza database come replica di lettura di un’istanza di MySQL eseguita esternamente a Amazon RDS. ``` call mysql.rds_set_external_master( 'Externaldb.some.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.0777', 120, 1); ``` ## mysql.rds\$1set\$1external\$1source (Aurora MySQL versione 3) Configura un'istanza database Aurora MySQL come replica di lettura di un'istanza di MySQL in esecuzione all'esterno di Amazon RDS. **Importante** Per eseguire questa procedura, è necessario abilitare `autocommit`. Per abilitarlo, impostare il parametro `autocommit` su `1`. Per ulteriori informazioni sulla modifica dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md). ### Sintassi ``` CALL mysql.rds_set_external_source ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption ); ``` ### Parameters *host\$1name* Il nome host o l'indirizzo IP dell'istanza di MySQL eseguita esternamente a Amazon RDS per diventare l’istanza database di origine. *host\$1port* La porta utilizzata dall'istanza di MySQL eseguita esternamente a Amazon RDS e da configurare come istanza database di origine. Se la configurazione della rete include la replica della porta Secure Shell (SSH) che converte il numero di porta, specifica il numero di porta esposto da SSH. *replication\$1user\$1name* L'ID di un utente con autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` nell'istanza di MySQL eseguita esternamente a Amazon RDS. Ti consigliamo di fornire un account utilizzato unicamente per la replica con l'istanza esterna. *replication\$1user\$1password* La password dell'ID utente specificata in `replication_user_name`. *mysql\$1binary\$1log\$1file\$1name* Il nome del log binario sull’istanza database di origine che contiene le informazioni relative alla replica. *mysql\$1binary\$1log\$1file\$1location* La posizione nel log binario `mysql_binary_log_file_name` a partire dalla quale la replica inizia a leggere le informazioni a essa relative. È possibile determinare il nome e la posizione del file binlog in esecuzione `SHOW MASTER STATUS` sull'istanza del database di origine. *ssl\$1encryption* Un valore che specifica se la crittografia Secure Socket Layer (SSL) è utilizzata sulla connessione di replica. 1 indica che la crittografia SSL deve essere utilizzata; 0 specifica che la crittografia non deve essere utilizzata. Il valore predefinito è 0. Per abilitare questa opzione, è necessario aver importato un certificato SSL personalizzato tramite [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material). Se non è stato importato un certificato SSL personalizzato, impostare questo parametro su 0 e utilizzare [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versione 3)](#mysql_rds_set_binlog_source_ssl) per abilitare SSL per la replica dei log binari. L’opzione `SOURCE_SSL_VERIFY_SERVER_CERT` non è supportata. Questa opzione è impostata su 0, il che significa che la connessione è crittografata, ma i certificati non sono verificati. ### Note per l’utilizzo L’utente amministrativo deve eseguire la procedura `mysql.rds_set_external_source`. Questa procedura deve essere eseguita nell’istanza database Aurora MySQL da configurare come replica di lettura di un’istanza MySQL eseguita esternamente ad Amazon RDS. Prima di eseguire `mysql.rds_set_external_source`, devi configurare l’istanza di MySQL in esecuzione all’esterno di Amazon RDS come istanza database di origine. Per connetterti all'istanza MySQL in esecuzione all'esterno di Amazon RDS, devi specificare i valori di `replication_user_name` e `replication_user_password` che indicano un utente della replica dotato delle autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` per l'istanza esterna di MySQL. **Per configurare un'istanza esterna di MySQL come istanza database di origine** 1. Mediante il client MySQL scelto, eseguire la connessione all'istanza esterna di MySQL e creare un account utente da utilizzare per la replica. Di seguito è riportato un esempio di : ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **Nota** Specifica una password diversa dal prompt mostrato qui come best practice per la sicurezza. 1. Nell’istanza esterna di MySQL, concedere i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` all’utente della replica. L’esempio seguente concede i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` su tutti i database per l’utente “repl\$1user” del dominio: ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'; ``` Per utilizzare la replica crittografata, configura l'istanza database di origine per utilizzare le connessioni SSL. Importa inoltre il certificato dell'autorità di certificazione, il certificato client e la chiave client nell'istanza database o nel cluster database utilizzando la procedura [mysql.rds\$1import\$1binlog\$1ssl\$1material](url-rds-user;mysql_rds_import_binlog_ssl_material.html). **Nota** Queste stored procedure sono fornite principalmente per abilitare la replica con le istanze MySQL eseguite esternamente a Amazon RDS. Ti consigliamo di usare le repliche Aurora per gestire la replica in un cluster database Aurora MySQL. Per informazioni sulla gestione della replica nei cluster database Aurora MySQL, consulta [Utilizzo delle repliche di Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas). Dopo aver chiamato `mysql.rds_set_external_source` per configurare un’istanza database Aurora MySQL come replica di lettura, è possibile chiamare [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) sulla replica di lettura per avviare il processo di replica. Puoi chiamare [mysql.rds\$1reset\$1external\$1source (Aurora MySQL versione 3)](#mysql_rds_reset_external_source) per rimuovere la configurazione della replica di lettura. Quando `mysql.rds_set_external_source` viene chiamato, Amazon RDS registra l'ora, l'utente e un'operazione di `set master` nelle tabelle `mysql.rds_history` e `mysql.rds_replication_status`. ### Esempi Se in esecuzione in un’istanza database Aurora MySQL, l’esempio seguente configura l’istanza database come replica di lettura di un’istanza di MySQL eseguita esternamente ad Amazon RDS. ``` call mysql.rds_set_external_source( 'Externaldb.some.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.0777', 120, 1); ``` ## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (Aurora MySQL versione 2) Configura un’istanza primaria Aurora MySQL affinché accetti la replica in entrata da un’istanza di MySQL esterna. Questa procedura configura anche la replica in base agli identificatori globali delle transazioni (). GTIDs Questa procedura non configura la replica ritardata in quanto non è supportata da Aurora MySQL. ### Sintassi ``` CALL mysql.rds_set_external_master_with_auto_position ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption ); ``` ### Parameters *host\$1name* Il nome host o l'indirizzo IP dell'istanza di MySQL eseguita esternamente a Aurora per diventare il fonte di replica. *host\$1port* La porta utilizzata dall'istanza di MySQL eseguita esternamente a Aurora e da configurare come fonte di replica. Se la configurazione della rete include la replica della porta Secure Shell (SSH) che converte il numero di porta, specifica il numero di porta esposto da SSH. *replication\$1user\$1name* L'ID di un utente con autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` nell'istanza di MySQL eseguita esternamente a Aurora. Ti consigliamo di fornire un account utilizzato unicamente per la replica con l'istanza esterna. *replication\$1user\$1password* La password dell'ID utente specificata in `replication_user_name`. *ssl\$1encryption* Questa opzione non è al momento implementata. Il valore predefinito è 0. ### Note per l'utilizzo Per un cluster di database Aurora MySQL, puoi chiamare questa procedura archiviata mentre sei connesso all'istanza primaria. La procedura `mysql.rds_set_external_master_with_auto_position` deve essere eseguita dall'utente master. L'utente master esegue questa procedura sull'istanza primaria di un cluster di database Aurora MySQL che opera da destinazione di replica. Questa può essere la destinazione di replica di un’istanza database MySQL esterna o di un cluster di database Aurora MySQL. Questa procedura è supportata per Aurora MySQL versione 2. Per Aurora MySQL versione 3, utilizzare invece la procedura [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL versione 3)](#mysql_rds_set_external_source_with_auto_position). Prima di eseguire `mysql.rds_set_external_master_with_auto_position`, configura l’istanza database MySQL esterna come fonte di replica. Per connetterti all’istanza di MySQL esterna, specifica i valori per `replication_user_name` e `replication_user_password`. Questi valori devono indicare un utente di replica che dispone delle autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` sull’istanza di MySQL esterna. **Per configurare un'istanza di MySQL esterna come fonte di replica** 1. Mediante il client MySQL scelto, eseguire la connessione all’istanza di MySQL esterna e creare un account utente da utilizzare per la replica. Di seguito è riportato un esempio. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` 1. Per un'istanza di MySQL esterna, concedere i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` all'utente della replica. L’esempio seguente concede i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` su tutti i database per l’utente `'repl_user'` per il dominio. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` Quando chiami `mysql.rds_set_external_master_with_auto_position`, Amazon RDS registra determinate informazioni. Queste informazioni sono l'orario, l'utente e l'operazione di `"set master"` nelle tabelle `mysql.rds_history` e `mysql.rds_replication_status`. Per passare a una specifica transazione basata su GTID che notoriamente causa un problema, puoi usare la procedura archiviata [mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL versione 2 e 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Per ulteriori informazioni sull’utilizzo della replica basata su GTID, consulta [Utilizzo della replica basata su GTID](mysql-replication-gtid.md). ### Esempi Nel caso di esecuzione su un’istanza primaria Aurora, l’esempio seguente configura il cluster Aurora come replica di lettura di un’istanza di MySQL eseguita esternamente a Aurora. ``` call mysql.rds_set_external_master_with_auto_position( 'Externaldb.some.com', 3306, 'repl_user'@'mydomain.com', 'SomePassW0rd'); ``` ## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL versione 3) Configura un’istanza primaria Aurora MySQL affinché accetti la replica in entrata da un’istanza di MySQL esterna. Questa procedura configura anche la replica in base agli identificatori globali delle transazioni (). GTIDs ### Sintassi ``` CALL mysql.rds_set_external_source_with_auto_position ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption ); ``` ### Parameters *host\$1name* Il nome host o l'indirizzo IP dell'istanza di MySQL eseguita esternamente a Aurora per diventare il fonte di replica. *host\$1port* La porta utilizzata dall'istanza di MySQL eseguita esternamente a Aurora e da configurare come fonte di replica. Se la configurazione della rete include la replica della porta Secure Shell (SSH) che converte il numero di porta, specifica il numero di porta esposto da SSH. *replication\$1user\$1name* L'ID di un utente con autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` nell'istanza di MySQL eseguita esternamente a Aurora. Ti consigliamo di fornire un account utilizzato unicamente per la replica con l'istanza esterna. *replication\$1user\$1password* La password dell'ID utente specificata in `replication_user_name`. *ssl\$1encryption* Questa opzione non è al momento implementata. Il valore predefinito è 0. Utilizzare [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL versione 3)](#mysql_rds_set_binlog_source_ssl) per abilitare SSL per la replica di log binari. ### Note per l’utilizzo Per un cluster di database Aurora MySQL, puoi chiamare questa procedura archiviata mentre sei connesso all’istanza primaria. L'utente amministrativo deve eseguire la procedura `mysql.rds_set_external_source_with_auto_position`. L'utente master esegue questa procedura sull'istanza primaria di un cluster di database Aurora MySQL che opera da destinazione di replica. Questa può essere la destinazione di replica di un’istanza database MySQL esterna o di un cluster di database Aurora MySQL. Questa procedura è supportata per Aurora MySQL versione 3. Questa procedura non configura la replica ritardata in quanto non è supportata da Aurora MySQL. Prima di eseguire `mysql.rds_set_external_source_with_auto_position`, configura l’istanza database MySQL esterna come fonte di replica. Per connetterti all’istanza di MySQL esterna, specifica i valori per `replication_user_name` e `replication_user_password`. Questi valori devono indicare un utente di replica che dispone delle autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` sull’istanza di MySQL esterna. **Per configurare un'istanza di MySQL esterna come fonte di replica** 1. Mediante il client MySQL scelto, eseguire la connessione all’istanza di MySQL esterna e creare un account utente da utilizzare per la replica. Di seguito è riportato un esempio. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` 1. Per un'istanza di MySQL esterna, concedere i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` all'utente della replica. L’esempio seguente concede i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` su tutti i database per l’utente `'repl_user'` per il dominio. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` Quando chiami `mysql.rds_set_external_source_with_auto_position`, Amazon RDS registra determinate informazioni. Queste informazioni sono l'orario, l'utente e l'operazione di `"set master"` nelle tabelle `mysql.rds_history` e `mysql.rds_replication_status`. Per passare a una specifica transazione basata su GTID che notoriamente causa un problema, puoi usare la procedura archiviata [mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL versione 2 e 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Per ulteriori informazioni sull’utilizzo della replica basata su GTID, consulta [Utilizzo della replica basata su GTID](mysql-replication-gtid.md). ### Esempi Nel caso di esecuzione su un’istanza primaria Aurora, l’esempio seguente configura il cluster Aurora come replica di lettura di un’istanza di MySQL eseguita esternamente a Aurora. ``` call mysql.rds_set_external_source_with_auto_position( 'Externaldb.some.com', 3306, 'repl_user'@'mydomain.com', 'SomePassW0rd'); ``` ## mysql.rds\$1set\$1master\$1auto\$1position (RDS ) Imposta la modalità di replica in modo che sia basata sulle posizioni dei file di registro binari o sugli identificatori globali delle transazioni (). GTIDs ### Sintassi ``` CALL mysql.rds_set_master_auto_position ( auto_position_mode ); ``` ### Parameters *auto\$1position\$1mode* Valore che indica se usare la replica basata sulla posizione del file di log o la replica basata su GTID: + `0` – Usa il metodo di replica basato sulla posizione del file di log binario. Il valore di default è `0`. + `1` – Usa il metodo di replica basato su GTID. ### Note per l’utilizzo La procedura `mysql.rds_set_master_auto_position` deve essere eseguita dall’utente master. Questa procedura è supportata per Aurora MySQL versione 2. ## mysql.rds\$1set\$1read\$1only (Aurora MySQL versione 3) Attiva o disattiva la modalità `read_only` a livello globale per l’istanza database. ### Sintassi ``` CALL mysql.rds_set_read_only(mode); ``` ### Parameters *mode* Valore che indica se la modalità `read_only` è attiva o disattiva a livello globale per l’istanza database: + `0` – `OFF`. Il valore predefinito è `0`. + `1` – `ON` ### Note per l’utilizzo La stored procedure `mysql.rds_set_read_only` modifica solo il parametro `read_only`. Il parametro `innodb_read_only` non può essere modificato sulle istanze database di lettura. La modifica del parametro `read_only` non viene mantenuta al riavvio. Per apportare modifiche permanenti a `read_only`, è necessario utilizzare il parametro `read_only` del cluster di database. Questa procedura è supportata per Aurora MySQL versione 3.06 e successive. ## mysql.rds\$1set\$1session\$1binlog\$1format (Aurora MySQL versione 2) Imposta il formato di log binario per la sessione corrente. ### Sintassi ``` CALL mysql.rds_set_session_binlog_format(format); ``` ### Parameters *format* Un valore che indica il formato di log binario per la sessione corrente: + `STATEMENT`: l'origine della replica scrive eventi nel log binario in base alle istruzioni SQL. + `ROW`: l'origine della replica scrive eventi nel log binario che indicano le modifiche alle singole righe della tabella. + `MIXED`: la registrazione si basa in genere su istruzioni SQL, ma passa alle righe in determinate condizioni. Per ulteriori informazioni, consulta [Mixed Binary Logging Format](https://dev.mysql.com/doc/refman/8.0/en/binary-log-mixed.html) nella documentazione di MySQL. ### Note per l’utilizzo Per un cluster di database Aurora MySQL, puoi chiamare questa procedura archiviata mentre sei connesso all’istanza primaria. Per utilizzare questa procedura archiviata, la registrazione binaria deve essere configurata per la sessione corrente. Per Aurora, questa procedura è supportata per Aurora MySQL versione 2.12 e versioni successive compatibili con MySQL 5.7. ## mysql.rds\$1set\$1source\$1auto\$1position (Aurora MySQL versione 3) Imposta la modalità di replica in modo che sia basata sulle posizioni dei file di registro binari o sugli identificatori globali delle transazioni (). GTIDs ### Sintassi ``` CALL mysql.rds_set_source_auto_position (auto_position_mode); ``` ### Parameters *auto\$1position\$1mode* Valore che indica se usare la replica basata sulla posizione del file di log o la replica basata su GTID: + `0` – Usa il metodo di replica basato sulla posizione del file di log binario. Il valore di default è `0`. + `1` – Usa il metodo di replica basato su GTID. ### Note per l'utilizzo Per un cluster di database Aurora MySQL, puoi chiamare questa procedura archiviata mentre sei connesso all’istanza primaria. L'utente amministrativo deve eseguire la procedura `mysql.rds_set_source_auto_position`. ## mysql.rds\$1skip\$1repl\$1error Ignora ed elimina un errore di replica su una replica di lettura database MySQL. ### Sintassi ``` CALL mysql.rds_skip_repl_error; ``` ### Note per l’utilizzo La procedura `mysql.rds_skip_repl_error` deve essere eseguita dall'utente master su una replica di lettura. Per ulteriori informazioni su questa procedura, consulta [Ignorare l'errore di replica corrente](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.SkipError). Per determinare se ci sono errori, esegui il comando MySQL `SHOW REPLICA STATUS\G`. Se un errore di replica non è critico, puoi eseguire `mysql.rds_skip_repl_error` per ignorare l'errore. Se vi sono più errori, `mysql.rds_skip_repl_error` elimina il primo, quindi informa della presenza di altri errori. Puoi quindi utilizzare `SHOW REPLICA STATUS\G` per determinare l'operazione corretta per l'errore successivo. Per informazioni sui valori restituiti, consulta [Istruzione SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) nella documentazione di MySQL. Per ulteriori informazioni sulla risoluzione degli errori di replica con Aurora MySQL, consulta [](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.RR). #### Errore di replica interrotta Quando si chiama la procedura `mysql.rds_skip_repl_error`, è possibile che venga visualizzato un messaggio di errore che indica che la replica è inattiva o disattivata. Questo messaggio di errore viene visualizzato se si esegue la procedura sull'istanza primaria anziché sulla replica di lettura. È necessario eseguire questa procedura sulla replica di lettura affinché funzioni. Questo messaggio di errore può essere visualizzato anche quando si esegue la procedura sulla replica di lettura, ma la replica non viene riavviata correttamente. Se devi ignorare un numero elevato di errori, il ritardo della replica potrebbe superare il periodo di retention predefinito per i file di log binari (binlog). In questo caso può verificarsi un errore irreversibile causato dall’eliminazione dei file binlog prima della loro riproduzione nella replica di lettura. Questa eliminazione causa l'arresto della replica e non è più possibile chiamare il comando `mysql.rds_skip_repl_error` per ignorare errori di replica. Puoi limitare questo problema aumentando il numero di ore di retention dei file binlog nell’istanza database di origine. Una volta aumentato il tempo di retention dei file binlog, puoi riavviare la replica e chiamare il comando `mysql.rds_skip_repl_error` secondo necessità. Per impostare il periodo di retention dei file binlog, usa la procedura [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) e specifica un parametro di configurazione di `'binlog retention hours'` insieme al numero di ore di retention dei file binlog nel cluster di database. Nell'esempio seguente il periodo di retention dei file binlog è impostato su 48 ore. ``` CALL mysql.rds_set_configuration('binlog retention hours', 48); ``` ## mysql.rds\$1start\$1replication Avvia la replica da un cluster di database Aurora MySQL. **Nota** Puoi usare la stored procedure [mysql.rds\$1start\$1replication\$1until (Aurora MySQL versione 3)](#mysql_rds_start_replication_until) o [mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL versione 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) per avviare la replica da un'istanza database Aurora MySQL e arrestare la replica in corrispondenza della posizione del file di log binario specificato. ### Sintassi ``` CALL mysql.rds_start_replication; ``` ### Note per l’utilizzo La procedura `mysql.rds_start_replication` deve essere eseguita dall’utente master. Per importare dati da un’istanza MySQL in esecuzione all’esterno di Amazon RDS, chiama `mysql.rds_start_replication` nella replica di lettura per avviare il processo di replica dopo aver chiamato [mysql.rds\$1set\$1external\$1master (Aurora MySQL versione 2)](#mysql_rds_set_external_master) o [mysql.rds\$1set\$1external\$1source (Aurora MySQL versione 3)](#mysql_rds_set_external_source) per creare la configurazione della replica. Per ulteriori informazioni, consulta [Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)](AuroraMySQL.Replication.MySQL.md). Per esportare dati in un'istanza di MySQL in esecuzione all'esterno di Amazon RDS, devi chiamare `mysql.rds_start_replication` e `mysql.rds_stop_replication` nella replica di lettura per controllare alcune operazioni di replica, come l'eliminazione di log binari. Per ulteriori informazioni, consulta [Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)](AuroraMySQL.Replication.MySQL.md). Puoi anche chiamare `mysql.rds_start_replication` nella replica di lettura per riavviare un processo di replica arrestato in precedenza chiamando `mysql.rds_stop_replication`. Per ulteriori informazioni, consulta [Errore di replica interrotta](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicationStopped). ## mysql.rds\$1start\$1replication\$1until (Aurora MySQL versione 3) Avvia la replica da cluster di database Aurora MySQL e la arresta in corrispondenza della posizione del file di log binario specificato. ### Sintassi ``` CALL mysql.rds_start_replication_until ( replication_log_file , replication_stop_point ); ``` ### Parameters *replication\$1log\$1file* Il nome del log binario sull’istanza database di origine che contiene le informazioni relative alla replica. *replication\$1stop\$1point * Posizione nel log binario `replication_log_file` in corrispondenza di cui la replica verrà arrestata. ### Note per l’utilizzo La procedura `mysql.rds_start_replication_until` deve essere eseguita dall'utente master. Questa procedura è supportata per Aurora MySQL versione 3.04 e successive. La stored procedure `mysql.rds_start_replication_until` non è supportata per la replica gestita, che include quanto segue: + [Repliche di cluster di database Amazon Aurora MySQL tra Regioni AWS](AuroraMySQL.Replication.CrossRegion.md) + [Migrazione di dati da un'istanza database RDS per MySQL a un cluster database Amazon Aurora MySQL utilizzando una replica di lettura Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md) Il nome file specificato per il parametro `replication_log_file` deve corrispondere al nome file binlog dell'istanza database di origine. Quando il parametro `replication_stop_point` specifica una posizione di arresto nel passato, la replica viene arrestata immediatamente. ### Esempi L'esempio seguente avvia la replica e replica le modifiche fino a raggiungere la posizione `120` nel file di log binario `mysql-bin-changelog.000777`. ``` call mysql.rds_start_replication_until( 'mysql-bin-changelog.000777', 120); ``` ## mysql.rds\$1stop\$1replication Arresta la replica da un'istanza database MySQL. ### Sintassi ``` CALL mysql.rds_stop_replication; ``` ### Note per l’utilizzo La procedura `mysql.rds_stop_replication` deve essere eseguita dall'utente master. Se configuri la replica per importare dati da un'istanza di MySQL in esecuzione all'esterno di Amazon RDS, puoi chiamare `mysql.rds_stop_replication` nella replica di lettura per arrestare il processo di replica al termine dell'importazione. Per ulteriori informazioni, consulta [Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)](AuroraMySQL.Replication.MySQL.md). Se configuri la replica per esportare dati in un'istanza di MySQL esterna ad Amazon RDS, devi chiamare `mysql.rds_start_replication` e `mysql.rds_stop_replication` nella replica di lettura per controllare alcune operazioni di replica, come l'eliminazione di log binari. Per ulteriori informazioni, consulta [Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)](AuroraMySQL.Replication.MySQL.md). La stored procedure `mysql.rds_stop_replication` non è supportata per la replica gestita, che include quanto segue: + [Repliche di cluster di database Amazon Aurora MySQL tra Regioni AWS](AuroraMySQL.Replication.CrossRegion.md) + [Migrazione di dati da un'istanza database RDS per MySQL a un cluster database Amazon Aurora MySQL utilizzando una replica di lettura Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md) # Terminare una sessione o una query Le seguenti stored procedure terminano una sessione o una query. **Topics** + [mysql.rds\$1kill](#mysql_rds_kill) + [mysql.rds\$1kill\$1query](#mysql_rds_kill_query) ## mysql.rds\$1kill Termina una connessione al server MySQL. ### Sintassi ``` CALL mysql.rds_kill(processID); ``` ### Parametri *processID* L'identità del thread di connessione da terminare. ### Note per l'utilizzo Ogni connessione al server MySQL viene eseguita in un thread distinto. Per terminare una connessione, utilizza la procedura `mysql.rds_kill` e passa l'ID di thread di quella connessione. Per ottenere l'ID di thread, utilizza il comando MySQL [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html). ### Esempi L'esempio seguente termina una connessione con l'ID di thread 4243: ``` CALL mysql.rds_kill(4243); ``` ## mysql.rds\$1kill\$1query Termina una query in esecuzione sul server MySQL. ### Sintassi ``` CALL mysql.rds_kill_query(processID); ``` ### Parametri *processID* L'identità del processo o del thread che esegue la query da terminare. ### Note per l'utilizzo Per arrestare una query in esecuzione nel server MySQL, utilizza la procedura `mysql_rds_kill_query` e invia l'ID di connessione del thread che sta eseguendo la query. La procedura termina quindi la connessione. Per ottenere l'ID, esegui una query sulla [tabella INFORMATION\$1SCHEMA PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/information-schema-processlist-table.html) MySQL o utilizza il comando MySQL [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html). Il valore nella colonna ID da `SHOW PROCESSLIST` o `SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST` è *processID*. ### Esempi L'esempio seguente arresta una query con l'ID di thread di query 230040: ``` CALL mysql.rds_kill_query(230040); ``` # Replica delle transazioni utilizzando GTIDs Le seguenti stored procedure controllano il modo in cui le transazioni vengono replicate utilizzando gli identificatori di transazione globali (GTIDs) con Aurora MySQL. Per informazioni su come utilizzare la replica basata su GTIDs Aurora MySQL, consulta. [Utilizzo della replica basata su GTID](mysql-replication-gtid.md) **Topics** + [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL versione 3)](#mysql_assign_gtids_to_anonymous_transactions) + [mysql.rds\$1gtid\$1purged (Aurora MySQL versione 3)](#mysql_rds_gtid_purged) + [mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL versione 2 e 3)](#mysql_rds_skip_transaction_with_gtid) + [mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL versione 3)](#mysql_rds_start_replication_until_gtid) ## mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL versione 3) Configura l'opzione `ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS` dell'istruzione `CHANGE REPLICATION SOURCE TO`. Il canale di replica assegna così un GTID alle transazioni replicate che non ne hanno uno. In questo modo, è possibile eseguire la replica del log binario da un'origine che non utilizza la replica basata su GTID in una replica che lo usa. *Per ulteriori informazioni, vedere [CHANGE REPLICATION SOURCE TO Statement and Replication From a](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html) [Source Without GTIDs to a Replica With GTIDs](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-assign-anon.html) nel MySQL Reference Manual.* ### Sintassi ``` CALL mysql.rds_assign_gtids_to_anonymous_transactions(gtid_option); ``` ### Parameters *gtid\$1option* Valore di stringa. I valori consentiti sono `OFF`, `LOCAL` o un UUID specificato. ### Note per l’utilizzo Questa procedura ha lo stesso effetto del rilascio dell'istruzione `CHANGE REPLICATION SOURCE TO ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = gtid_option` nella community MySQL. GTID deve essere impostato su o su un `ON` UUID specifico. *gtid\$1option* `LOCAL` Il valore predefinito è `OFF`, il che significa che la funzione non viene utilizzata. `LOCAL` assegna un GTID incluso l'UUID della replica (l'impostazione `server_uuid`). Il passaggio di un parametro che è un UUID assegna un GTID che include l'UUID specificato, ad esempio l'impostazione `server_uuid` per il server di fonte di replica. ### Esempi Per disattivare questa funzione: ``` mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('OFF'); +-------------------------------------------------------------+ | Message | +-------------------------------------------------------------+ | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: OFF | +-------------------------------------------------------------+ 1 row in set (0.07 sec) ``` Per utilizzare l'UUID della replica: ``` mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('LOCAL'); +---------------------------------------------------------------+ | Message | +---------------------------------------------------------------+ | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: LOCAL | +---------------------------------------------------------------+ 1 row in set (0.07 sec) ``` Per utilizzare un UUID specificato: ``` mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('317a4760-f3dd-3b74-8e45-0615ed29de0e'); +----------------------------------------------------------------------------------------------+ | Message | +----------------------------------------------------------------------------------------------+ | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: 317a4760-f3dd-3b74-8e45-0615ed29de0e | +----------------------------------------------------------------------------------------------+ 1 row in set (0.07 sec) ``` ## mysql.rds\$1gtid\$1purged (Aurora MySQL versione 3) Imposta il valore globale della variabile di sistema `gtid_purged` su un set di ID globali di transazione (GTID) specificato. La variabile di `gtid_purged` sistema è un set GTID composto da tutte le transazioni che sono state eseguite sul server, ma che non esistono in alcun file di registro binario sul server. GTIDs Per consentire la compatibilità con MySQL 8.0, esistono due modi per impostare il valore di `gtid_purged`: + Sostituire il valore di `gtid_purged` con il set di GTID specificato. + Aggiungere il set di GTID specificato al set di GTID già contenuto in `gtid_purged`. ### Sintassi Per sostituire il valore di `gtid_purged` con il set di GTID specificato: ``` CALL mysql.rds_gtid_purged (gtid_set); ``` Per aggiungere il valore di `gtid_purged` con al set di GTID specificato: ``` CALL mysql.rds_gtid_purged (+gtid_set); ``` ### Parameters *gtid\$1set* Il valore di *gtid\$1set* deve essere un superset del valore corrente di `gtid_purged` e non può intersecarsi con. `gtid_subtract(gtid_executed,gtid_purged)` Cioè, il nuovo set GTID deve includere quelli già presenti GTIDs `gtid_purged` e non può includere quelli `gtid_executed` che non sono ancora GTIDs stati eliminati. Inoltre, il *gtid\$1set* parametro non può includere GTIDs quelli presenti nel `gtid_owned` set globale, vale a dire GTIDs per le transazioni attualmente in corso di elaborazione sul server. ### Note per l’utilizzo La procedura `mysql.rds_gtid_purged` deve essere eseguita dall’utente master. Questa procedura è supportata per Aurora MySQL versione 3.04 e successive. ### Esempi L'esempio seguente assegna il GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23` alla variabile globale `gtid_purged`. ``` CALL mysql.rds_gtid_purged('3E11FA47-71CA-11E1-9E33-C80AA9429562:23'); ``` ## mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL versione 2 e 3) Ignora la replica di una transazione con l'ID globale di transazione (GTID) specificato in un'istanza primaria Aurora. Puoi usare questa procedura per il ripristino di emergenza quando è noto che una specifica transazione GTID causa un problema. Usa questa stored procedure per saltare la transazione problematica. Esempi di transazioni problematiche includono le transazioni che disabilitano la replica, eliminano dati importanti o con le quali l'istanza database diventa non disponibile. ### Sintassi ``` CALL mysql.rds_skip_transaction_with_gtid ( gtid_to_skip ); ``` ### Parameters *gtid\$1to\$1skip* GTID della transazione di replica da ignorare. ### Note per l'utilizzo La procedura `mysql.rds_skip_transaction_with_gtid` deve essere eseguita dall’utente master. Questa procedura è supportata per Aurora MySQL versione 2 e 3. ### Esempi Nell'esempio seguente viene ignorata la replica della transazione con il GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`. ``` CALL mysql.rds_skip_transaction_with_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23'); ``` ## mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL versione 3) Avvia la replica da un cluster di database Aurora MySQL e la arresta immediatamente dopo l'ID globale di transazione (GTID) specificato. ### Sintassi ``` CALL mysql.rds_start_replication_until_gtid(gtid); ``` ### Parameters *gtid* Il GTID dopo il quale deve essere arrestata la replica. ### Note per l'utilizzo La procedura `mysql.rds_start_replication_until_gtid` deve essere eseguita dall’utente master. Questa procedura è supportata per Aurora MySQL versione 3.04 e successive. La stored procedure `mysql.rds_start_replication_until_gtid` non è supportata per la replica gestita, che include quanto segue: + [Repliche di cluster di database Amazon Aurora MySQL tra Regioni AWS](AuroraMySQL.Replication.CrossRegion.md) + [Migrazione di dati da un'istanza database RDS per MySQL a un cluster database Amazon Aurora MySQL utilizzando una replica di lettura Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md) Quando il parametro `gtid` specifica una transazione che è già stata eseguita dalla replica, la procedura viene arrestata immediatamente. ### Esempi L'esempio seguente avvia la replica e replica le modifiche finché non raggiunge il GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`. ``` call mysql.rds_start_replication_until_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23'); ``` # Rotazione dei log di query Le seguenti stored procedure ruotano i log MySQL nelle tabelle di backup. Per ulteriori informazioni, consulta [File di registro del database Aurora MySQL](USER_LogAccess.Concepts.MySQL.md). **Topics** + [mysql.rds\$1rotate\$1general\$1log](#mysql_rds_rotate_general_log) + [mysql.rds\$1rotate\$1slow\$1log](#mysql_rds_rotate_slow_log) ## mysql.rds\$1rotate\$1general\$1log Converte la tabella `mysql.general_log` in una tabella di backup. ### Sintassi ``` CALL mysql.rds_rotate_general_log; ``` ### Note per l’utilizzo Puoi convertire la tabella `mysql.general_log` in una tabella di backup chiamando la procedura `mysql.rds_rotate_general_log`. Quando le tabelle di log sono convertite, la tabella di log corrente è copiata in una tabella di logo di backup e le voci nella tabella di log corrente sono eliminate. Se una tabella di log di backup esiste, viene eliminata prima che la tabella di log corrente sia copiata nel backup. Puoi eseguire una query sulla tabella di log di backup, se necessario. La tabella di log di backup per la tabella `mysql.general_log` è denominata `mysql.general_log_backup`. È possibile eseguire questa procedura solo quando il parametro `log_output` è impostato su `TABLE`. ## mysql.rds\$1rotate\$1slow\$1log Converte la tabella `mysql.slow_log` in una tabella di backup. ### Sintassi ``` CALL mysql.rds_rotate_slow_log; ``` ### Note per l’utilizzo Puoi convertire la tabella `mysql.slow_log` in una tabella di backup chiamando la procedura `mysql.rds_rotate_slow_log`. Quando le tabelle di log sono convertite, la tabella di log corrente è copiata in una tabella di logo di backup e le voci nella tabella di log corrente sono eliminate. Se una tabella di log di backup esiste, viene eliminata prima che la tabella di log corrente sia copiata nel backup. Puoi eseguire una query sulla tabella di log di backup, se necessario. La tabella di log di backup per la tabella `mysql.slow_log` è denominata `mysql.slow_log_backup`. # Impostazione e visualizzazione della configurazione dei log binari Le seguenti stored procedure impostano e mostrano i parametri di configurazione, ad esempio per la conservazione dei file di log binari. **Topics** + [mysql.rds\$1set\$1configuration](#mysql_rds_set_configuration) + [mysql.rds\$1show\$1configuration](#mysql_rds_show_configuration) ## mysql.rds\$1set\$1configuration Specifica il numero di ore di conservazione dei log binari o il numero di secondi di ritardo della replica. ### Sintassi ``` CALL mysql.rds_set_configuration(name,value); ``` ### Parameters *name* Il nome del parametro di configurazione da impostare. *value* Il valore del parametro di configurazione. ### Note per l'utilizzo la procedura archiviata `mysql.rds_set_configuration` supporta i parametri di configurazione seguenti: + [binlog retention hours](#mysql_rds_set_configuration-usage-notes.binlog-retention-hours) I parametri di configurazione vengono archiviati in modo permanente e restano effettivi dopo qualsiasi riavvio o failover dell'istanza database. #### binlog retention hours Il parametro `binlog retention hours` viene utilizzato per specificare il numero di ore di conservazione dei file di log binari. Amazon Aurora elimina in genere un log binario non appena possibile, tuttavia il log potrebbe continuare a essere necessario per la replica con un database MySQL esterno ad Aurora. Il valore predefinito di `binlog retention hours` è `NULL`. Per Aurora MySQL, `NULL` significa che i log binari vengono eliminati lentamente. I log binari Aurora MySQL potrebbero rimanere nel sistema per un certo periodo, di solito non più di un giorno. Per specificare il numero di ore per mantenere i log binari in un cluster di database, usa la stored procedure `mysql.rds_set_configuration` e specifica un periodo con tempo sufficiente per l'esecuzione della replica, come mostrato nell'esempio seguente. `call mysql.rds_set_configuration('binlog retention hours', 24);` **Nota** Non puoi utilizzare il valore `0` per `binlog retention hours`. Il valore `binlog retention hours` massimo per i cluster database Aurora MySQL versione 2.11.0 e successive e versione 3 è 2160 (90 giorni). Dopo l'impostazione del periodo di retention, monitora l'utilizzo dello storage per l'istanza database per verificare che i log binari conservati non occupino troppo spazio di storage. ## mysql.rds\$1show\$1configuration Il numero di ore di retention dei log binari. ### Sintassi ``` CALL mysql.rds_show_configuration; ``` ### Note per l'utilizzo Per verificare il numero di ore per cui Amazon RDS deve conservare i log binari, usa la stored procedure `mysql.rds_show_configuration`. ### Esempi L'esempio seguente visualizza il periodo di retention: ``` call mysql.rds_show_configuration; name value description binlog retention hours 24 binlog retention hours specifies the duration in hours before binary logs are automatically deleted. ``` # Tabelle information\$1schema specifiche di Aurora MySQL Aurora MySQL dispone di determinate tabelle `information_schema` che sono specifiche di Aurora. ## information\$1schema.aurora\$1global\$1db\$1instance\$1status La tabella `information_schema.aurora_global_db_instance_status` contiene informazioni sullo stato di tutte le istanze database nei cluster database primario e secondario di un database globale. Nella tabella seguente vengono visualizzate le colonne che è possibile utilizzare. Le colonne rimanenti sono solo per uso interno di Aurora. **Nota** Questa tabella dello schema informativo è disponibile solo con Aurora MySQL 3.04.0 e versioni successive. | Colonna | Tipo di dati | Descrizione | | --- | --- | --- | | SERVER\$1ID | varchar(100) | Identificatore istanza database. | | SESSION\$1ID | varchar(100) | Un identificatore univoco per la sessione corrente. Il valore di MASTER\$1SESSION\$1ID identifica l'istanza database di lettura (primaria). | | AWS\$1REGION | varchar(100) | La Regione AWS in cui viene eseguita questa istanza database globale. Per l'elenco delle regioni, consulta [Disponibilità nelle regioni](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability). | | DUREVOLE\$1LSN | bigint unsigned | Il numero di sequenza di log (LSN) reso durevole nello storage. Numero di sequenza di log (LSN) è un numero sequenziale univoco che identifica un record nel log delle transazioni del database. Gli LSN sono ordinati in modo tale che un LSN più grande rappresenti una transazione successiva. | | HIGHEST\$1LSN\$1RCVD | bigint unsigned | L'LSN più alto ricevuto dall'istanza database dall'istanza database di scrittura. | | OLDEST\$1READ\$1VIEW\$1TRX\$1ID | bigint unsigned | L'ID della transazione più vecchia che può essere rimossa dall'istanza database di scrittura. | | OLDEST\$1READ\$1VIEW\$1LSN | bigint unsigned | L'LSN più vecchio utilizzato dall'istanza database per le operazioni di lettura dallo storage. | | VISIBILITY\$1LAG\$1IN\$1MSEC | float(10,0) unsigned | Per le istanze di lettura nel cluster database primario, il ritardo in millisecondi di questa istanza database rispetto all'istanza database di scrittura. Per istanze di lettura in un cluster database secondario, il ritardo in millisecondi di questa istanza database rispetto al volume secondario. | ## information\$1schema.aurora\$1global\$1db\$1status La tabella `information_schema.aurora_global_db_status` contiene informazioni su vari aspetti del ritardo del database globale Aurora, in particolare il ritardo dello storage Aurora sottostante (chiamato ritardo di durabilità) e il ritardo tra l'obiettivo del punto di ripristino (RPO). Nella tabella seguente vengono visualizzate le colonne che è possibile utilizzare. Le colonne rimanenti sono solo per uso interno di Aurora. **Nota** Questa tabella dello schema informativo è disponibile solo con Aurora MySQL 3.04.0 e versioni successive. | Colonna | Tipo di dati | Descrizione | | --- | --- | --- | | AWS\$1REGION | varchar(100) | La Regione AWS in cui viene eseguita questa istanza database globale. Per l'elenco delle regioni, consulta [Disponibilità nelle regioni](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability). | | HIGHEST\$1LSN\$1WRITTEN | bigint unsigned | Il numero di sequenza di log (LSN) più alto attualmente esistente in questo cluster database. Numero di sequenza di log (LSN) è un numero sequenziale univoco che identifica un record nel log delle transazioni del database. Gli LSN sono ordinati in modo tale che un LSN più grande rappresenti una transazione successiva. | | DURABILITY\$1LAG\$1IN\$1MILLISECONDS | float(10,0) unsigned | La differenza nei valori di timestamp tra il parametro HIGHEST\$1LSN\$1WRITTEN su un cluster database secondario e il parametro HIGHEST\$1LSN\$1WRITTEN sul cluster database primario. Questo valore è sempre 0 sul cluster database primario del database globale Aurora. | | RPO\$1LAG\$1IN\$1MILLISECONDS | float(10,0) unsigned | Il ritardo dell'obiettivo del punto di ripristino (RPO). Il ritardo dell'obiettivo del punto di ripristino (RPO) è il tempo necessario per memorizzare il COMMIT delle transazioni utente più recenti dopo la sua memorizzazione nel cluster di database primario del database globale Aurora. Questo valore è sempre 0 sul cluster database primario del database globale Aurora. In sintesi, questo parametro calcola l'obiettivo del punto di ripristino per ciascun cluster database Aurora MySQL nel database globale Aurora, ovvero quanti dati potrebbero andare perduti in caso di interruzione. Come per il ritardo, l'obiettivo del punto di ripristino (RPO) viene misurato nel tempo. | | LAST\$1LAG\$1CALCULATION\$1TIMESTAMP | datetime | Il timestamp che specifica quando sono stati calcolati i valori per DURABILITY\$1LAG\$1IN\$1MILLISECONDS e RPO\$1LAG\$1IN\$1MILLISECONDS. Il valore temporale 1970-01-01 00:00:00\$100 indica che questo è il cluster di database primario. | | OLDEST\$1READ\$1VIEW\$1TRX\$1ID | bigint unsigned | L'ID della transazione più vecchia che può essere rimossa dall'istanza database di scrittura. | ## information\$1schema.replica\$1host\$1status La tabella `information_schema.replica_host_status` contiene informazioni sulla replica. Le colonne che è possibile utilizzare sono mostrate nella tabella seguente. Le colonne rimanenti sono solo per uso interno di Aurora. | Colonna | Tipo di dati | Descrizione | | --- | --- | --- | | CPU | double | La percentuale di utilizzo della CPU dell'host di replica. | | IS\$1CURRENT | tinyint | Se la replica è aggiornata. | | LAST\$1UPDATE\$1TIMESTAMP | datetime(6) | L'ora dell'ultimo aggiornamento. Utilizzata per determinare se un record è obsoleto. | | REPLICA\$1LAG\$1IN\$1MILLISECONDS | double | Il ritardo di replica in millisecondi. | | SERVER\$1ID | varchar(100) | L'ID del server di database. | | SESSION\$1ID | varchar(100) | L'ID della sessione di database. Utilizzato per determinare se un'istanza database è un'istanza di scrittura o di lettura. | **Nota** Quando un'istanza di replica rimane indietro, le informazioni interrogate dalla relativa tabelle `information_schema.replica_host_status` potrebbero essere obsolete. In questo caso, ti consigliamo di eseguire una query dall'istanza si scrittura. Sebbene la tabella `mysql.ro_replica_status` contenga informazioni simili, ti consigliamo di non utilizzarla. ## information\$1schema.aurora\$1forwarding\$1processlist La tabella `information_schema.aurora_forwarding_processlist` contiene informazioni sui processi coinvolti nell'inoltro di scrittura. I contenuti di questa tabella sono visibili solo sull'istanza database di scrittura per un cluster database con l'inoltro di scrittura globale o interno al cluster attivato. Viene restituito un set di risultati vuoto sulle istanze database di lettura. | Campo | Tipo di dati | Descrizione | | --- | --- | --- | | ID | bigint | L'identificatore della connessione sull'istanza DB di scrittura. Questo identificatore è lo stesso valore visualizzato nella colonna Iddell'istruzione SHOW PROCESSLIST e restituita dalla funzione CONNECTION\$1ID() all'interno del thread. | | UTENTE | varchar(32) | L'utente MySQL che ha eseguito l'istruzione. | | HOST | varchar(255) | Il client MySQL che ha eseguito l'istruzione. Per le istruzioni inoltrate, questo campo mostra l'indirizzo host del client dell'applicazione che ha stabilito la connessione sull'istanza database di lettura di inoltro. | | DB | varchar(64) | Il database predefinito per il thread. | | COMMAND | varchar(16) | Il tipo di comando eseguito dal thread per conto del client o Sleep se lo stato della sessione è inattivo. Per le descrizioni dei comandi di thread, consulta la documentazione MySQL su [Thread Command Values](https://dev.mysql.com/doc/refman/8.0/en/thread-commands.html) nella documentazione MySQL. | | TIME | int | Il tempo in secondi in cui il thread è rimasto nello stato corrente. | | STATE | varchar(64) | Un'azione, un evento o uno stato che indica cosa sta facendo il thread. Per le descrizioni dei valori di stato, consulta [Stati generali del thread](https://dev.mysql.com/doc/refman/8.0/en/general-thread-states.html) nella documentazione di MySQL. | | INFO | longtext | L'istruzione eseguita dal thread o NULL se non sta eseguendo un'istruzione. L'istruzione può essere quella inviata al server o un'istruzione più interna se l' istruzione esegue altre istruzioni. | | IS\$1FORWARDED | bigint | Indica se il thread viene inoltrato da un'istanza database di lettura. | | REPLICA\$1SESSION\$1ID | bigint | L'identificatore di connessione sulla replica di Aurora. Questo identificatore è lo stesso valore visualizzato nella colonna Iddell'istruzione SHOW PROCESSLIST sull'istanza database di lettura Aurora di inoltro. | | REPLICA\$1INSTANCE\$1IDENTIFIER | varchar(64) | L'identificatore dell'istanza database del thread di inoltro. | | REPLICA\$1CLUSTER\$1NAME | varchar(64) | L'identificatore cluster database del thread di inoltro. Per l'inoltro di scrittura all'interno del cluster, questo identificatore è lo stesso cluster database dell'istanza database di scrittura. | | REPLICA\$1REGION | varchar(64) | La Regione AWS di origine del thread di inoltro. Per l'inoltro di scrittura all'interno del cluster, questa regione è la stessa Regione AWS dell'istanza database di scrittura. |