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à. # Risoluzione dei problemi per Amazon RDS Utilizza le sezioni seguenti per risolvere i problemi che riscontri con le istanze database in Amazon RDS e Amazon Aurora. **Topics** + [Impossibile connettersi all'istanza database di Amazon RDS](#CHAP_Troubleshooting.Connecting) + [Problemi relativi alla sicurezza di Amazon RDS](#CHAP_Troubleshooting.Security) + [Risoluzione dei problemi relativi allo stato di rete non compatibile](#CHAP_Troubleshooting.IncompatibleNetworkMode) + [Reimpostazione della password del ruolo di proprietario dell'istanza di database](#CHAP_Troubleshooting.ResetPassword) + [Errore o riavvio di un'istanza di database Amazon RDS](#CHAP_Troubleshooting.Reboots) + [Modifiche ai parametri di database Amazon RDS che non hanno effetto](#CHAP_Troubleshooting.Parameters) + [Mancanza di spazio di storage per l'istanza di database Amazon RDS](#CHAP_Troubleshooting.Storage) + [Disponibilità insufficiente delle istanze database Amazon RDS](#CHAP_Troubleshooting.Capacity) + [Problemi di memoria liberabile in Amazon RDS](#Troubleshooting.FreeableMemory) + [Problemi relativi a MySQL e MariaDB](#CHAP_Troubleshooting.MySQL) + [Impossibile impostare il periodo di retention dei backup su 0](#CHAP_Troubleshooting.Backup.Retention) Per informazioni sui problemi di debug con l'API Amazon RDS, consulta [Risoluzione dei problemi delle applicazioni in Amazon RDS](APITroubleshooting.md). ## Impossibile connettersi all'istanza database di Amazon RDS Quando non è possibile connettersi a un'istanza database, le cause comuni sono le seguenti: + **Regole in entrata**: le regole di accesso applicate dal firewall locale e gli indirizzi IP autorizzati per accedere all'istanza database potrebbero non corrispondere. Il problema è probabilmente correlato alle regole in entrata del gruppo di sicurezza. Per impostazione predefinita, le istanze database non consentono l'accesso. L'accesso viene concesso tramite un gruppo di sicurezza associato al VPC che consente il traffico in entrata e in uscita dall'istanza database. Se necessario, aggiungi regole in entrata e in uscita per la situazione particolare al gruppo di sicurezza. Puoi specificare un indirizzo IP, un intervallo di indirizzi IP o un altro gruppo di sicurezza VPC. **Nota** Quando si aggiunge una nuova regola in entrata, puoi scegliere **My IP (Il mio IP)** per **Source (Origine)** per consentire l'accesso all'istanza database dall'indirizzo IP rilevato nel browser. Per ulteriori informazioni sulla configurazione di un gruppo di sicurezza, consulta [Fornisci accesso alla istanza database nel VPC creando un gruppo di sicurezza](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup). **Nota** Le connessioni client da indirizzi IP all'interno dell'intervallo 169.254.0.0/16 non sono consentite. Si tratta di un intervallo APIPA (Automatic Private IP Addressing), utilizzato per gli indirizzi con collegamenti locali. + **Public accessibility (Accesso pubblico)**: per connettersi all'istanza database dall'esterno del VPC, ad esempio utilizzando un'applicazione client, occorre assegnare all'istanza un indirizzo IP pubblico. Per rendere l'istanza accessibile pubblicamente, modificarla e scegliere **Yes (Sì)** in **Public accessibility (Accesso pubblico)**. Per ulteriori informazioni, consulta [Nascondere istanze database in un VPC da Internet](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Hiding). + **Porta**: la porta specificata al momento della creazione dell’istanza database non può essere utilizzata per inviare o ricevere comunicazioni a causa delle restrizioni del firewall locale. Per determinare se la rete consente l'utilizzo della porta specificata per le comunicazioni in entrata e in uscita, consulta il tuo amministratore di rete. + **Disponibilità**: per una nuova istanza database creata, lo stato dell'istanza database è `creating` finché non è pronta per essere utilizzata. Quando lo stato cambia in `available`, puoi connetterti all'istanza database. A seconda delle dimensioni dell'istanza di database, potresti dover attendere circa 20 minuti prima che questa diventi disponibile. + **Gateway Internet** – Per un'istanza database che deve essere accessibile pubblicamente, le sottoreti nel gruppo di sottoreti del database devono disporre di un gateway Internet. **Per configurare un gateway Internet per una sottorete** 1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nel riquadro di navigazione, scegliere **Databases (Database)** e selezionare il nome dell'istanza database. 1. Nella scheda **Connectivity & security (Connettività e sicurezza)** annotare i valori dell'ID VPC in **VPC** e l'ID della sottorete in **Subnets (Sottoreti)**. 1. Apri la console Amazon VPC all'indirizzo [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Nel riquadro di navigazione, scegliere **Internet Gateways**. Verificare che al VPC sia associato un Internet gateway. In caso contrario, scegliere **Create Internet Gateway (Crea Internet gateway)** per crearne uno. Selezionare l'Internet gateway, quindi **Attach to VPC (Associa a VPC)** e seguire le istruzioni di associazione del gateway al VPC. 1. Nel riquadro di navigazione scegliere **Subnets (Sottoreti)** e selezionare la sottorete desiderata. 1. Nella scheda **Route Table (Tabella di routing)** verificare che sia presente un instradamento con `0.0.0.0/0` come destinazione e l'Internet gateway del VPC come target. Se ti connetti alla tua istanza utilizzando il relativo IPv6 indirizzo, verifica che esista un percorso per tutto IPv6 il traffico (`::/0`) che punti al gateway Internet. In caso contrario, eseguire le seguenti operazioni: 1. Selezionare l'ID per la tabella di routing (rtb-*xxxxxxxx*) per navigare alla tabella di routing. 1. Nella scheda **Routes (Route)**, scegliere **Edit routes (Modifica route)**. Selezionare **Add route (Aggiungi route)**, utilizzare `0.0.0.0/0` come destinazione e il gateway internet come target. Ad esempio IPv6, scegli **Aggiungi percorso**, utilizza `::/0` come destinazione e il gateway Internet come destinazione. 1. Seleziona **Salva route**. Inoltre, se stai tentando di connetterti all' IPv6 endpoint, assicurati che l'intervallo di IPv6 indirizzi del client sia autorizzato a connettersi all'istanza DB. Per ulteriori informazioni, consulta [Uso di un'istanza database in un VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md). Per problemi di connessione specifici del motore, consulta i seguenti argomenti: + [Risoluzione dei problemi relativi alle connessioni all'istanza database di SQL Server](USER_ConnectToMicrosoftSQLServerInstance.Troubleshooting.md) + [Risoluzione dei problemi relativi alle connessioni all'istanza database Oracle](USER_ConnectToOracleInstance.Troubleshooting.md) + [Risoluzione dei problemi relativi alle connessioni all'istanza RDS per PostgreSQL](USER_ConnectToPostgreSQLInstance.Troubleshooting.md) + [Numero massimo di connessioni MySQL e MariaDB](#USER_ConnectToInstance.max_connections) ### Test della connessione a un'istanza database Puoi verificare la connessione a un'istanza database utilizzando strumenti comuni di Linux o Windows. Da un terminale Linux o Unix, puoi eseguire il test della connessione immettendo quanto segue. Sostituisci `DB-instance-endpoint` con l'endpoint e `port` con la porta dell'istanza database. ``` nc -zv DB-instance-endpoint port ``` Di seguito è riportato un comando di esempio e il valore restituito. ``` nc -zv postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299 Connection to postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299 port [tcp/vvr-data] succeeded! ``` Gli utenti Windows possono utilizzare Telnet per eseguire il test della connessione a un'istanza di database. Le operazioni di Telnet non sono supportate, ad eccezione del test della connessione. Se una connessione ha esito positivo, l'operazione non restituisce alcun messaggio. Se una connessione non va a buon fine, riceverai un messaggio di errore del tipo seguente. ``` C:\>telnet sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com 819 Connecting To sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com...Could not open connection to the host, on port 819: Connect failed ``` Se le operazioni di Telnet hanno esito positivo, il tuo gruppo di sicurezza è configurato correttamente. **Nota** Amazon RDS non accetta il traffico del protocollo ICMP (Internet Control Message Protocol), incluso il ping. ### Risoluzione di problemi di autenticazione della connessione In alcuni casi, è possibile connettersi all'istanza database, ma si ricevono errori di autenticazione. In questi casi, potrebbe essere necessario ripristinare la password utente master per l'istanza database. A tale scopo, è necessario modificare l'istanza RDS. Per ulteriori informazioni sulla modifica di un'istanza database , consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md). ## Problemi relativi alla sicurezza di Amazon RDS Per evitare problemi di sicurezza, non utilizzare mai l'indirizzo e-mail e la password dell'utente Account AWS root per un account utente. Come best practice, si consiglia di utilizzare l’utente root per creare utenti e assegnarli agli account utente database. È anche possibile utilizzare l’utente root per creare altri account utente, se necessario. Per informazioni sulla creazione di utenti, consulta [Creazione di un utente IAM nell' Account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html). Per informazioni sulla creazione di utenti in AWS IAM Identity Center, consulta [Gestire le identità in IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html). ### Messaggio di errore "Impossibile recuperare gli attributi dell'account, alcune funzioni della console potrebbero non essere attive." Puoi ricevere questo errore per diversi motivi. È possibile che l'account non disponga delle autorizzazioni o che l'account non sia stato configurato correttamente. Se si tratta di un nuovo account, potrebbe essere necessario attendere che l'account sia pronto. Se si tratta di un account esistente, nelle policy di accesso potrebbero non essere disponibili alcune autorizzazioni per eseguire determinate operazioni, come creare un'istanza database. Per risolvere il problema, l'amministratore deve fornire i ruoli necessari per il tuo account. Per ulteriori informazioni, consulta la [documentazione di IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/). ## Risoluzione dei problemi relativi allo stato di rete non compatibile Lo stato di rete non compatibile significa che il database potrebbe essere ancora accessibile a livello di database ma non è possibile modificarlo o riavviarlo. ### Cause Lo stato di rete non compatibile dell'istanza database potrebbe essere il risultato di una delle seguenti azioni: + Modifica della classe dell'istanza database. + Modifica dell'istanza database per utilizzare l'implementazione multi-AZ del cluster database. + Sostituzione di un host a causa di un evento di manutenzione. + Avvio di un'istanza database di sostituzione. + Ripristino da un backup snapshot. + Avvio di un'istanza database arrestata. ### Risoluzione #### Usa il comando start-db-instance Per correggere un database che si trova in uno stato di rete non compatibile, segui queste istruzioni: 1. Apri [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)e scegli **Database** dal riquadro di navigazione. 1. **Scegli l'istanza DB che si trova nello stato di rete incompatibile e annota l'identificatore dell'istanza DB, l'ID VPC e la IDs sottorete dalla scheda Connettività e sicurezza.** 1. Utilizzate il per eseguire il comando. AWS CLI `start-db-instance` Specifica il valore `--db-instance-identifier`. **Nota** L'esecuzione di questo comando quando il database è in modalità non compatibile potrebbe causare tempi di inattività. Il comando `start-db-instance` non risolve questo problema per le istanze database RDS per SQL Server. Lo stato del database diventa **Disponibile** se il comando viene eseguito correttamente. Se il database si riavvia, l'istanza database potrebbe eseguire l'ultima operazione eseguita sull'istanza prima che tale istanza assumesse lo stato di rete non compatibile. Ciò potrebbe riportare l'istanza allo stato di rete non compatibile. Se il comando `start-db-instance` ha esito negativo o l'istanza torna allo stato di rete non compatibile, apri la pagina **Database** nella console RDS e seleziona il database. Passa alla sezione **Log ed eventi**. Nella sezione **Eventi recenti** sono visualizzati ulteriori passaggi di risoluzione da seguire. I messaggi sono classificati come segue: + **CONTROLLO DELLE RISORSE INTERNE**: potrebbero essersi verificati problemi con le risorse interne. + **CONTROLLO DNS**: verifica la risoluzione DNS e i nomi host per il VPC nella console VPC. + **CONTROLLO ENI**: l'interfaccia di rete elastica (ENI) per il database potrebbe non esistere. + **CONTROLLO DEL GATEWAY**: il gateway Internet per il database disponibile pubblicamente non è collegato al VPC. + **CONTROLLO IP**: non ci sono indirizzi IP gratuiti nelle tue sottoreti. + **CONTROLLO DEL GRUPPO DI SICUREZZA**: non ci sono gruppi di sicurezza associati al database oppure i gruppi di sicurezza non sono validi. + **CONTROLLO DELLE SOTTORETI**: non ci sono sottoreti valide nel tuo gruppo di sottoreti database o ci sono problemi nella tua sottorete. + **CONTROLLO DEL VPC**: il VPC associato al database non è valido. #### Eseguire point-in-time il ripristino È consigliabile disporre di un backup (snapshot o logico), nel caso in cui il database passi a uno stato di rete non compatibile. Per informazioni, consulta [Introduzione ai backup](USER_WorkingWithAutomatedBackups.md). Se hai attivato i backup automatici, interrompi temporaneamente le scritture sul database ed esegui un point-in-time ripristino. **Nota** Dopo che un'istanza passa allo stato di rete non compatibile, l'istanza database potrebbe non essere accessibile per eseguire un backup logico. Se non hai attivato i backup automatici, crea una nuova istanza database. Esegui quindi la migrazione dei dati utilizzando [AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/;Welcome.html) o utilizzando uno strumento di backup e ripristino. Se il problema persiste, contatta Supporto per ulteriore assistenza. ## Reimpostazione della password del ruolo di proprietario dell'istanza di database Se si viene bloccati dal di istanze DB, è possibile accedere come utente master. È quindi possibile reimpostare le credenziali per altri utenti o ruoli amministrativi. Se non riesci ad accedere come utente principale, il proprietario dell' AWS account può reimpostare la password dell'utente principale. Per informazioni dettagliate sugli account o sui ruoli amministrativi che potrebbe essere necessario reimpostare, vedere [Privilegi dell'account utente master](UsingWithRDS.MasterAccounts.md). Puoi modificare la password dell'istanza DB utilizzando la console Amazon RDS, il AWS CLI comando [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)o utilizzando l'operazione [Modify DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API. Per ulteriori informazioni sulla modifica di un'istanza database, consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md). ## Errore o riavvio di un'istanza di database Amazon RDS Un errore dell'istanza database può verificarsi quando viene riavviata. Può anche verificarsi quando l'istanza database viene inserita in uno stato che impedisce l'accesso e quando il database viene riavviato. Un riavvio può verificarsi quando si riavvia manualmente l'istanza database. Un riavvio può anche verificarsi quando si modifica un'impostazione dell'istanza database che richiede un riavvio prima che la modifica diventi effettiva. Il riavvio di un'istanza database può verificarsi quando si modifica un'impostazione che richiede un riavvio o quando il riavvio viene innescato manualmente. Un riavvio può verificarsi immediatamente se si modifica un'impostazione e si richiede che la modifica abbia effetto immediato. Oppure può verificarsi durante la finestra di manutenzione dell'istanza database. Un riavvio dell'istanza del database si verifica immediatamente quando si verifica una delle seguenti condizioni: + Il periodo di retention dei backup per un'istanza database viene modificato da 0 a un valore diverso da zero o da un valore diverso da zero a 0. Quindi si imposta **Apply Immediately** (Applica immediatamente) su `true`. + Si modifica la classe di istanza database e si imposta **Apply Immediately (Applica immediatamente)** su `true`. + Si modifica il tipo di storage da **Magnetico (Standard)** a **Uso generale (SSD)** o da **IPOS con provisioning (SSD)** oppure da **IPOS con provisioning (SSD)** o **Uso generale (SSD)** a **Magnetico (Standard)**. Un riavvio dell'istanza di database avviene durante la finestra di manutenzione quando si verifica una delle seguenti condizioni: + Si modifica il periodo di retention dei backup per un'istanza database da 0 a un valore diverso da zero o da un valore diverso da zero a 0 e **Apply Immediately (Applica immediatamente)** è impostato su `false`. + Si modifica la classe di istanza database e si imposta **Apply Immediately (Applica immediatamente)** su `false`. Quando si modifica un parametro statico in un gruppo di parametri database, la modifica non diventa effettiva fino al riavvio dell'istanza database associata al gruppo di parametri. La modifica richiede un riavvio manuale. L'istanza database non viene riavviata automaticamente durante la finestra di manutenzione. Per visualizzare una tabella che illustra le operazioni di un'istanza database e l'effetto dell'impostazione del valore **Apply Immediately (Applica immediatamente)**, consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md). ## Modifiche ai parametri di database Amazon RDS che non hanno effetto In alcuni casi, si potrebbe modificare un parametro in un gruppo di parametri database senza che le modifiche diventino effettive. In tal caso, è probabile che sia necessario riavviare l'istanza database associata al gruppo di parametri database. Quando si modifica un parametro dinamico, la modifica diventa immediatamente effettiva. Quando si modifica un parametro statico, la modifica non diventa effettiva finché l'istanza database associata al gruppo di parametri non viene riavviata. Puoi riavviare un'istanza database utilizzando la console RDS. In alternativa puoi chiamare esplicitamente l'operazione API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBInstance.html). È possibile riavviare senza failover se l'istanza database è in un'implementazione Multi-AZ. La necessità di riavviare l'istanza database associata dopo la modifica di un parametro statico consente di ridurre il rischio di errore di configurazione di un parametro che influenza una chiamata API. Un esempio è la chiamata di `ModifyDBInstance` per modificare la classe di istanza database. Per ulteriori informazioni, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ## Mancanza di spazio di storage per l'istanza di database Amazon RDS Se l'istanza di database non dispone di spazio di storage sufficiente, potrebbe non essere più disponibile. Ti consigliamo vivamente di monitorare costantemente la `FreeStorageSpace` metrica pubblicata in CloudWatch per assicurarti che l'istanza DB disponga di spazio di archiviazione libero sufficiente. Se la capacità di storage dell'istanza database si esaurisce, il suo stato cambia in `storage-full`. Di seguito è riportato, ad esempio, l'output di una chiamata all'operazione API `DescribeDBInstances` per un'istanza database che ha esaurito lo spazio di storage. ``` aws rds describe-db-instances --db-instance-identifier mydbinstance DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 50 sa storage-full mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 SECGROUP default active PARAMGRP default.mysql8.0 in-sync ``` Per eseguire il ripristino da questo scenario, aggiungi altro spazio di archiviazione all'istanza utilizzando l'operazione `ModifyDBInstance` API o il AWS CLI comando seguente. Per Linux, macOS o Unix: ``` aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --allocated-storage 60 \ --apply-immediately ``` Per Windows: ``` aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --allocated-storage 60 ^ --apply-immediately ``` ``` DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 50 sa storage-full mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 60 SECGROUP default active PARAMGRP default.mysql8.0 in-sync ``` Ora, l'istanza database che descrivi si trova nello stato `modifying`, il che significa che è in corso il dimensionamento dello storage. ``` 1. aws rds describe-db-instances --db-instance-identifier mydbinstance ``` ``` DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 50 sa modifying mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 60 SECGROUP default active PARAMGRP default.mysql8.0 in-sync ``` Al termine del dimensionamento dello storage, lo stato dell'istanza database cambia in `available`. ``` aws rds describe-db-instances --db-instance-identifier mydbinstance ``` ``` DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 60 sa available mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 SECGROUP default active PARAMGRP default.mysql8.0 in-sync ``` Puoi continuare a ricevere notifiche quando lo spazio di storage disponibile è esaurito utilizzando l'operazione `DescribeEvents`. Ad esempio, in questo scenario, se effettui una chiamata `DescribeEvents` dopo queste operazioni, viene visualizzato il seguente risultato: ``` aws rds describe-events --source-type db-instance --source-identifier mydbinstance ``` ``` 2009-12-22T23:44:14.374Z mydbinstance Allocated storage has been exhausted db-instance 2009-12-23T00:14:02.737Z mydbinstance Applying modification to allocated storage db-instance 2009-12-23T00:31:54.764Z mydbinstance Finished applying modification to allocated storage ``` ## Disponibilità insufficiente delle istanze database Amazon RDS L'errore `InsufficientDBInstanceCapacity` può essere restituito quando si tenta di creare, avviare o modificare un'istanza database. Può anche essere restituito quando si tenta di ripristinare un'istanza database da uno snapshot DB. Quando viene restituito questo errore, una causa comune è che la classe dell'istanza database specifica non è disponibile nella zona di disponibilità richiesta. Puoi provare una delle seguenti soluzioni per risolvere il problema: + Ritenta la richiesta con una classe di istanza database differente. + Ritenta la richiesta con una zona di disponibilità differente. + Ritenta la richiesta senza specificare una zona di disponibilità esplicita. Per ulteriori informazioni sulla risoluzione dei problemi di capacità delle istanze per Amazon EC2, consulta [Capacità dell'istanza insufficiente](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html#troubleshooting-launch-capacity) nella *Guida per l'utente Amazon EC2*. Per ulteriori informazioni sulla modifica di un'istanza database, consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md). ## Problemi di memoria liberabile in Amazon RDS La *memoria liberabile* è la memoria RAM (Random Access Memory) su un'istanza database che può essere resa disponibile al motore di database. È la somma della memoria libera del sistema operativo (OS) e della memoria disponibile del buffer e della cache delle pagine. Il motore di database utilizza la maggior parte della memoria sull'host, ma anche i processi del sistema operativo utilizzano RAM. La memoria attualmente allocata al motore di database o utilizzata dai processi del sistema operativo non è inclusa nella memoria liberabile. Quando il motore di database sta per esaurire la memoria, l'istanza database può utilizzare lo spazio temporaneo normalmente utilizzato per il buffering e la memorizzazione nella cache. Come accennato in precedenza, questo spazio temporaneo è incluso nella memoria liberabile. Utilizzi la `FreeableMemory` metrica di Amazon CloudWatch per monitorare la memoria liberabile. Per ulteriori informazioni, consulta [Strumenti di monitoraggio di Amazon RDS](MonitoringOverview.md). Se la memoria liberabile dell'istanza database diventa insufficiente o viene utilizzato uno spazio di scambio, valutare l'aumento a una classe di istanza database più grande. Per ulteriori informazioni, consulta [Classi di istanze DB ](Concepts.DBInstanceClass.md). Inoltre, puoi modificare le impostazioni della memoria. Ad esempio, in RDS per MySQL, puoi regolare le dimensioni del parametro `innodb_buffer_pool_size`. Questo parametro è impostato per default sul 75% della memoria fisica. Per ulteriori suggerimenti per la risoluzione di problemi di MySQL, consulta [Come è possibile risolvere i problemi di memoria liberabile insufficiente in un database Amazon RDS per MySQL?](https://aws.amazon.com/premiumsupport/knowledge-center/low-freeable-memory-rds-mysql-mariadb/) ## Problemi relativi a MySQL e MariaDB Puoi diagnosticare e risolvere i problemi relativi alle istanze database MySQL e MariaDB. **Topics** + [Numero massimo di connessioni MySQL e MariaDB](#USER_ConnectToInstance.max_connections) + [Diagnosi e risoluzione dello stato dei parametri incompatibili per un limite di memoria](#CHAP_Troubleshooting.incompatible-parameters-memory) + [Diagnosi e risoluzione del ritardo tra repliche di lettura](#CHAP_Troubleshooting.MySQL.ReplicaLag) + [Diagnosi e risoluzione di un errore di replica di lettura MySQL o MariaDB](#CHAP_Troubleshooting.MySQL.RR) + [La creazione di trigger con log binario abilitato richiede i privilegi SUPER](#CHAP_Troubleshooting.MySQL.CreatingTriggers) + [Diagnosi e risoluzione point-in-time degli errori di ripristino](#CHAP_Troubleshooting.MySQL.PITR) + [Errore di replica interrotta](#CHAP_Troubleshooting.MySQL.ReplicationStopped) + [Creazione della replica di lettura non riuscita o interruzione della replica in seguito a errore irreversibile 1236](#CHAP_Troubleshooting.MySQL.ReadReplicas) + [La replica di lettura non riesce a inizializzare la struttura dei metadati](#CHAP_Troubleshooting.MySQL.ReadReplicas.ReplicationErrorMetadata) ### Numero massimo di connessioni MySQL e MariaDB Il numero massimo di connessioni consentite a un'istanza database di RDS for MySQL o RDS for MariaDB si basa sulla quantità di memoria disponibile per la relativa classe dell'istanza database. Una classe di istanza database con più memoria disponibile permetterà un maggior numero di connessioni. Per ulteriori informazioni sulle classi di istanza database, consulta [Classi di istanze DB ](Concepts.DBInstanceClass.md). Il limite di connessioni per un'istanza database è impostata per default sul valore massimo per la classe dell'istanza database. Puoi limitare il numero di connessioni simultanee a un qualsiasi valore fino al numero massimo di connessioni consentite. Utilizza il parametro `max_connections` nel gruppo di parametri per l'istanza database. Per ulteriori informazioni, consulta [Numero massimo di connessioni di database](CHAP_Limits.md#RDS_Limits.MaxConnections) e [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md). Puoi recuperare il numero massimo di connessioni consentite per un'istanza database MySQL o MariaDB eseguendo la query seguente. ``` SELECT @@max_connections; ``` Puoi recuperare il numero di connessioni attive a un'istanza database MySQL o MariaDB eseguendo la query seguente. ``` SHOW STATUS WHERE `variable_name` = 'Threads_connected'; ``` ### Diagnosi e risoluzione dello stato dei parametri incompatibili per un limite di memoria Un'istanza database MariaDB o MySQL può essere impostata sullo stato **parametri incompatibili** per un limite di memoria quando sono soddisfatte entrambe le seguenti condizioni: + L'istanza database viene riavviata almeno tre volte in un'ora o almeno cinque volte in un giorno quando lo stato dell'istanza database **Disponibile**. + Un tentativo di riavvio dell'istanza database non riesce perché un'operazione di manutenzione o un processo di monitoraggio non sono riusciti a riavviare l'istanza database. + Il potenziale utilizzo della memoria dell'istanza database supera 1,2 volte la memoria allocata alla classe di istanza database. Quando un'istanza database viene riavviata per la terza volta in un'ora o per la quinta volta in un giorno, viene eseguito un controllo dell'utilizzo della memoria. Il controllo calcola il potenziale utilizzo della memoria dell'istanza database. Il valore restituito dal calcolo è la somma dei seguenti valori: + **Valore 1** – La somma dei seguenti parametri: + `innodb_additional_mem_pool_size` + `innodb_buffer_pool_size` É possibile modificare il valore di `innodb_buffer_pool_size`. Tuttavia, il valore non sempre corrisponderà a quello immesso. Questa mancata corrispondenza si verifica per diversi motivi. Innanzitutto, se l’istanza database è un’istanza database micro, si deve sostituire il valore predefinito impostandolo su 256 MB. Per ulteriori informazioni, consulta [Sovrascrivere innodb\$1buffer\$1pool\$1size](MySQL.KnownIssuesAndLimitations.md#MySQL.Concepts.KnownIssuesAndLimitations.innodb-bp-size). In secondo luogo, è necessario che 500 MB di memoria siano riservati sull’istanza database per l’host manager, il motore, il sistema operativo e il kernel. Infine, si ottimizza `innodb_buffer_pool_size` dividendola in unità. L’host manager arrotonda per difetto al multiplo più vicino di tali unità. Le unità vengono calcolate moltiplicando `innodb_buffer_pool_chunk_size` per `innodb_buffer_pool_instances`. Per ulteriori informazioni, consulta [Configuring InnoDB Buffer Pool Size](https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool-resize.html) nella documentazione MySQL. L’impostazione predefinita per `innodb_buffer_pool_instances` è 8, a meno che `innodb_buffer_pool_size` non sia inferiore a 1 GB. Se `innodb_buffer_pool_size` è inferiore a 1 GB, l’impostazione predefinita per `innodb_buffer_pool_instances` è 1. Il valore predefinito per `innodb_buffer_pool_chunk_size` è 128 MB. + `innodb_log_buffer_size` + `key_buffer_size` + `query_cache_size` (solo MySQL versione 5.7) + `tmp_table_size` + **Valore 2** – Il parametro `max_connections` moltiplicato per la somma dei seguenti parametri: + `binlog_cache_size` + `join_buffer_size` + `read_buffer_size` + `read_rnd_buffer_size` + `sort_buffer_size` + `thread_stack` + **Valore 3** – Se il parametro `performance_schema` è abilitato, moltiplicare il parametro `max_connections` per `429498`. Se invece il parametro `performance_schema` è disabilitato, questo valore è zero. Quindi, il valore restituito dal calcolo è il seguente: `Value 1 + Value 2 + Value 3` Quando questo valore supera 1,2 volte la memoria allocata alla classe di istanza database utilizzata dall'istanza database, l'istanza database viene posizionata nello stato dei **parametri incompatibili** . Per informazioni sulla memoria allocata alle classi di istanza database, consulta [Specifiche hardware per le classi di istanze DB ](Concepts.DBInstanceClass.Summary.md). Il calcolo moltiplica il valore del parametro `max_connections` per la somma di diversi parametri. Se il parametro `max_connections` è impostato su un valore elevato, è possibile che il controllo restituisca un valore eccessivamente elevato per il potenziale utilizzo della memoria dell'istanza database. In questo caso, considera la riduzione del valore del parametro `max_connections`. Per risolvere il problema, completa la seguente procedura: 1. Regola i parametri di memoria nel gruppo di parametri database associato all'istanza database. Esegui questa operazione in modo che il potenziale di utilizzo della memoria sia inferiore a 1,2 volte la memoria allocata alla classe di istanza database Per informazioni sull'estensione dei parametri consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. Riavviare l'istanza database. Per informazioni sull'estensione dei parametri consulta [Avvio di un'istanza database Amazon RDS arrestata in precedenza](USER_StartInstance.md). ### Diagnosi e risoluzione del ritardo tra repliche di lettura Quando una replica di lettura MySQL or MariaDB viene creata ed è disponibile, Amazon RDS esegue per prima cosa la replica delle modifiche apportate all'istanza database di origine dal momento in cui l'operazione di creazione della replica di lettura è stata avviata. Durante questa fase, il ritardo di replica per la replica di lettura è maggiore di 0. Puoi monitorare questo ritardo in Amazon CloudWatch visualizzando la metrica Amazon RDS. `ReplicaLag` Il parametro `ReplicaLag` indica il valore del campo `Seconds_Behind_Master` del comando `SHOW REPLICA STATUS` MySQL o MariaDB. Per ulteriori informazioni, consulta [Istruzione SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) nella documentazione di MySQL. Quando il parametro `ReplicaLag` è 0, la replica ha raggiunto l'istanza del database di origine. Se il parametro `ReplicaLag` restituisce -1, la replica potrebbe non essere attiva. Per la risoluzione di problemi relativi a un errore di replica, consulta [Diagnosi e risoluzione di un errore di replica di lettura MySQL o MariaDB](#CHAP_Troubleshooting.MySQL.RR). Un valore di `ReplicaLag` pari a -1 può anche indicare che il valore di `Seconds_Behind_Master` non può essere determinato oppure è `NULL`. **Nota** Le versioni precedenti di MariaDB utilizzavano `SHOW SLAVE STATUS` anziché `SHOW REPLICA STATUS`. Se utilizzi una versione di MariaDB precedente alla 10.5, utilizza `SHOW SLAVE STATUS`. Il parametro `ReplicaLag` restituisce -1 durante un'interruzione della rete o quando viene applicata una patch durante la finestra di manutenzione. In questo caso, attendi fino al ripristino della connettività di rete o al termine della finestra di manutenzione prima di controllare nuovamente il parametro `ReplicaLag` . La tecnologia di replica di lettura di MySQL e MariaDB è asincrona. Pertanto, è possibile che si verifichino incrementi occasionali del parametro `BinLogDiskUsage` nell'istanza database di origine e del parametro `ReplicaLag` nella replica di lettura. Ad esempio, considera una situazione in cui si verifica un elevato volume di operazioni di scrittura nell'istanza database di origine in parallelo. Allo stesso tempo, le operazioni di scrittura sulla replica di lettura vengono serializzate utilizzando un singolo thread. I/O Tale situazione può portare a un ritardo tra l'istanza di origine e la replica di lettura. Per ulteriori informazioni sulle repliche di lettura e su MySQL, consulta la pagina dei [dettagli dell'implementazione di repliche](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation-details.html) nella documentazione di MySQL. Per ulteriori informazioni sulle repliche di lettura e su MariaDB, consulta la pagina della [panoramica della replica](http://mariadb.com/kb/en/mariadb/replication-overview/) nella documentazione di MariaDB. Puoi ridurre il ritardo tra gli aggiornamenti di un'istanza database di origine e i successivi aggiornamenti della replica di lettura attenendoti alla seguente procedura: + Imposta la classe dell'istanza database della replica di lettura in modo che le sue dimensioni di storage siano paragonabili a quelle dell'istanza del database di origine. + Assicurati che le impostazioni dei parametri dei gruppi di parametri database utilizzati dall'istanza database di origine e la replica di lettura siano compatibili. Per ulteriori informazioni e un esempio, consulta la discussione sul parametro `max_allowed_packet` nella sezione seguente. + Disabilita la cache delle query. Per le tabelle modificate di frequente, l'uso della cache delle query può aumentare il ritardo della replica perché la cache viene bloccata e aggiornata spesso. In questo caso, potresti visualizzare un ritardo della replica inferiore se disabiliti la cache delle query. Puoi disabilitare la cache delle query impostando il parametro `query_cache_type parameter` sul valore 0 nel gruppo di parametri di database dell'istanza di database. Per ulteriori informazioni sulla cache delle query, consulta la sezione relativa alla [configurazione della cache delle query](https://dev.mysql.com/doc/refman/5.7/en/query-cache-configuration.html). + Riscaldare il buffer pool sulla replica di lettura per InnoDB per MySQL o MariaDB. Ad esempio, supponi di disporre di un set ridotto di tabelle che vengono aggiornate di frequente e di utilizzare lo schema di tabella InnoDB o XtraDB. In questo caso, esegui il dump di tali tabelle nella replica di lettura In questo modo, il motore di database esegue la scansione delle righe delle tabelle del disco e le memorizza nella cache nel pool di buffer, il che può ridurre il ritardo della replica. Di seguito viene riportato un esempio. Per Linux, macOS o Unix: ``` PROMPT> mysqldump \ -h \ --port= \ -u= \ -p \ database_name table1 table2 > /dev/null ``` Per Windows: ``` PROMPT> mysqldump ^ -h ^ --port= ^ -u= ^ -p ^ database_name table1 table2 > /dev/null ``` ### Diagnosi e risoluzione di un errore di replica di lettura MySQL o MariaDB Amazon RDS monitora lo stato delle repliche di lettura. RDS aggiorna il campo **Replication State** (Stato di replica) dell'istanza della replica di lettura con il valore `Error`, se la replica viene arrestata per qualsiasi motivo. Puoi rivedere i dettagli dell'errore associato generato dai motori MySQL o MariaDB visualizzando il campo **Replication Error (Errore di replica)**. Vengono generati anche eventi che indicano lo stato della replica di lettura, inclusi [RDS-EVENT-0045](USER_Events.Messages.md#RDS-EVENT-0045), [RDS-EVENT-0046](USER_Events.Messages.md#RDS-EVENT-0046) e [RDS-EVENT-0057](USER_Events.Messages.md#RDS-EVENT-0057). Per ulteriori informazioni sugli eventi e sulla sottoscrizione a essi, consulta [Utilizzo della notifica degli eventi di Amazon RDS](USER_Events.md). Se viene restituito un messaggio di errore MySQL, controlla l'errore nella [documentazione dei messaggi di errore MySQL](https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html). Se viene restituito un messaggio di errore MariaDB, controlla l'errore nella [documentazione dei messaggi di errore MariaDB](http://mariadb.com/kb/en/mariadb/mariadb-error-codes/). Situazioni comuni che possono causare errori di replica sono: + Il valore del parametro `max_allowed_packet` di una replica di lettura è inferiore al parametro `max_allowed_packet` dell'istanza database di origine. Il parametro `max_allowed_packet` è un parametro personalizzato che puoi impostare in un gruppo di parametri database. Il parametro `max_allowed_packet` viene utilizzato per specificare la dimensione massima delle query DML (Data Manipulation Language) che possono essere eseguite sul database. In alcuni casi, il valore `max_allowed_packet` dell'istanza database di origine potrebbe essere più grande del valore `max_allowed_packet` per la replica di lettura. In questo caso, il processo di replica può generare un errore e interrompere la replica. L'errore più comune è `packet bigger than 'max_allowed_packet' bytes`. Puoi correggere questo errore impostando l'origine e la replica di lettura in modo che utilizzino i gruppi di parametri database con gli stessi valori del parametro `max_allowed_packet`. + Scrittura in tabelle su una replica di lettura. Se crei indici su una replica di lettura, il parametro `read_only` deve essere impostato su *0* affinché gli indici vengano creati. Se esegui la scrittura su tabelle sulla replica di lettura, ciò può interrompere la replica. + Uso di un motore di storage non transazionale come MyISAM. Le repliche di lettura richiedono un motore di storage transazionale. La replica è supportata solo per i seguenti motori di archiviazione: InnoDB per MySQL o MariaDB. Puoi convertire una tabella MyISAM in InnoDB, utilizzando il comando seguente: `alter table . engine=innodb;` + Utilizzo di query non deterministiche non sicure come `SYSDATE()`. Per ulteriori informazioni, consulta la pagina relativa alla [determinazione delle istruzioni sicure e non sicure nel logging binario](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html) nella documentazione MySQL. La seguente procedura può essere di aiuto per la risoluzione dell'errore di replica: + Se riscontri un errore logico e puoi ignorarlo in modo sicuro, attieniti alla procedura descritta in [Ignorare l’errore di replica corrente per RDS per MySQL](Appendix.MySQL.CommonDBATasks.SkipError.md). L'istanza di database MySQL o MariaDB deve eseguire una versione che includa la procedura `mysql_rds_skip_repl_error`. Per ulteriori informazioni, consulta [mysql.rds\$1skip\$1repl\$1error](mysql-stored-proc-replicating.md#mysql_rds_skip_repl_error). + Se si verifica un problema di posizione del log binario (binlog), è possibile modificare la posizione di riproduzione della replica con il comando [mysql.rds\$1next\$1source\$1log (RDS per MySQL versioni principali 8.4 e successive)](mysql-stored-proc-replicating.md#mysql_rds_next_source_log) o [](mysql-stored-proc-replicating.md#mysql_rds_next_master_log). + Si potrebbe verificare un problema temporaneo a livello di prestazioni dovuto a un elevato carico DML. In tal caso, puoi impostare il parametro `innodb_flush_log_at_trx_commit` su 2 nel gruppo di parametri database sulla replica di lettura. Ciò può agevolare il recupero delle prestazioni della replica di lettura, sebbene le proprietà ACID (atomicità, consistenza, isolamento e durata) subiscano una riduzione temporanea. + Puoi eliminare la replica di lettura e creare un'istanza utilizzando lo stesso identificatore istanze DB. In questo modo, l'endpoint rimane identico a quello della vecchia replica di lettura. Quando un problema relativo alla replica viene risolto, il campo **Replication State (Stato di replica)** cambia in **replicating (replica in corso)**. Per ulteriori informazioni, consulta [Risoluzione dei problemi relativi a una replica di lettura MySQL](USER_ReadRepl.Troubleshooting.md). ### La creazione di trigger con log binario abilitato richiede i privilegi SUPER Durante la creazione di trigger in un'istanza database RDS for MySQL o RDS for MariaDB, potresti ricevere il seguente errore. ``` "You do not have the SUPER privilege and binary logging is enabled" ``` L'utilizzo di trigger quando il log binario è abilitato richiede i privilegi SUPER, che sono soggetti a restrizioni per le istanze database RDS for MySQL e RDS for MariaDB. Puoi creare trigger quando il log binario è abilitato senza privilegi SUPER impostando il parametro `log_bin_trust_function_creators` su true. Per impostare il parametro `log_bin_trust_function_creators` su true, crea un gruppo di parametri di database o modificane uno esistente. Puoi creare un nuovo gruppo di parametri database per poter creare trigger nell'istanza database RDS per MySQL o RDS per MariaDB con la registrazione binaria abilitata. A tale scopo, utilizza i seguenti comandi della CLI. Per modificare un gruppo di parametri esistente, inizia dalla fase 2. **Per creare un nuovo gruppo di parametri per consentire trigger con log binario abilitato utilizzando CLI** 1. Crea un nuovo set di parametri. Per Linux, macOS o Unix: ``` aws rds create-db-parameter-group \ --db-parameter-group-name allow-triggers \ --db-parameter-group-family mysql8.0 \ --description "parameter group allowing triggers" ``` Per Windows: ``` aws rds create-db-parameter-group ^ --db-parameter-group-name allow-triggers ^ --db-parameter-group-family mysql8.0 ^ --description "parameter group allowing triggers" ``` 1. Modifica il gruppo di parametri di database per consentire i trigger. Per Linux, macOS o Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name allow-triggers \ --parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot" ``` Per Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name allow-triggers ^ --parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot" ``` 1. Modifica l'istanza di database per utilizzare il nuovo gruppo di parametri di database. Per Linux, macOS o Unix: ``` aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --db-parameter-group-name allow-triggers \ --apply-immediately ``` Per Windows: ``` aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --db-parameter-group-name allow-triggers ^ --apply-immediately ``` 1. Per rendere effettive le modifiche, riavvia manualmente l'istanza database. ``` aws rds reboot-db-instance --db-instance-identifier mydbinstance ``` ### Diagnosi e risoluzione point-in-time degli errori di ripristino **Ripristino di un’istanza database che include tabelle temporanee** Quando tenti di point-in-time ripristinare (PITR) la tua istanza MySQL o MariaDB, potresti riscontrare il seguente errore. ``` Database instance could not be restored because there has been incompatible database activity for restore functionality. Common examples of incompatible activity include using temporary tables, in-memory tables, or using MyISAM tables. In this case, use of Temporary table was detected. ``` Il ripristino PITR si basa su snapshot di backup e log binari (binlog) di MySQL o MariaDB per eseguire il ripristino di un'istanza database a un momento specifico. Le informazioni nelle tabelle temporanee potrebbero non essere affidabili nei binlog e causare un errore di ripristino PITR. L’utilizzo delle tabelle temporanee nell’istanza database MySQL o MariaDB consente di ridurre il rischio di errore PITR effettuando backup più frequenti. È più probabile che tale errore si verifichi tra la creazione di una tabella temporanea e il successivo snapshot di backup. **Ripristino di un’istanza database che include tabelle in memoria** È possibile che si verifichi un problema durante il ripristino di un database con tabelle in memoria. Il contenuto delle tabelle in memoria viene rimosso durante il riavvio. Pertanto, le tabelle in memoria potrebbero risultare vuote dopo un riavvio. Quando utilizzi tabelle in memoria, è consigliabile progettare l'architettura della soluzione in modo che gestisca le tabelle vuote in caso di riavvio. Se utilizzi tabelle in memoria con istanze database replicate, potrebbe essere necessario ricreare le repliche di lettura dopo un riavvio. Ciò potrebbe essere necessario se una replica di lettura viene riavviata e non è in grado di ripristinare i dati da una tabella in memoria vuota. Per ulteriori informazioni sui backup e sul ripristino PITR, consulta [Introduzione ai backup](USER_WorkingWithAutomatedBackups.md) e [Ripristino di un’istanza database a un punto temporale specifico per Amazon RDS](USER_PIT.md). ### Errore di replica interrotta Quando si chiama il comando `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 perché la replica è stata arrestata e non può essere riavviata. 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. In questo caso, si potrebbe verificare un errore irreversibile a causa di file di log binari che sono stati eliminati prima di essere riprodotti sulla replica. 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 di log binari nella sorgente di replica. 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, utilizza la procedura [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration). Specifica un parametro di configurazione di "binlog retention hours" (ore di retention dei file binlog) insieme al numero di ore di retention dei file binlog nel cluster di database, fino a 720 (30 giorni). Nell'esempio seguente il periodo di retention dei file binlog è impostato su 48 ore. ``` CALL mysql.rds_set_configuration('binlog retention hours', 48); ``` ### Creazione della replica di lettura non riuscita o interruzione della replica in seguito a errore irreversibile 1236 Dopo aver modificato i valori dei parametri predefiniti per un'istanza di database MySQL o MariaDB, potresti riscontrare uno dei seguenti problemi: + Non è possibile creare una replica di lettura per l'istanza database. + La replica non riesce e viene visualizzato `fatal error 1236`. Alcuni valori di parametri predefiniti per le istanze database MySQL o MariaDB garantiscono che il database sia conforme ad ACID e che le repliche di lettura siano protette da arresti anomali. A questo scopo viene fatto in modo che ogni commit sia completamente sincronizzato mediante la scrittura della transazione nel log binario prima dell'esecuzione del commit. La modifica di questi parametri rispetto ai valori predefiniti per migliorare le prestazioni può causare errori di replica quando una transazione non è stata scritta nel log binario. Per risolvere questo problema, utilizza i seguenti valori di parametri: + `sync_binlog = 1` + `innodb_support_xa = 1` + `innodb_flush_log_at_trx_commit = 1` ### La replica di lettura non riesce a inizializzare la struttura dei metadati Al tentativo di avviare la replica, è stato ricevuto il seguente messaggio di errore: ``` Read Replica Replication Error - SQLError: 13124, reason: Replica failed to initialize applier metadata structure from the repository ``` Questo errore si verifica se viene rilevato un problema relativo alla struttura dei metadati della replica. Per correggere la struttura dei metadati, è necessario creare una nuova replica. Per evitare che ciò accada in futuro, esegui una delle azioni riportate di seguito: + Se possibile, disattiva il multithreading sulle repliche. A partire da MySQL 8.0.27, il multithreading è abilitato per impostazione predefinita. + Se è necessario utilizzare il multithreading sulle repliche, si consiglia di utilizzare la replica basata su GTID. Per ulteriori informazioni, consulta [Utilizzo della replica basata su GTID](mysql-replication-gtid.md). ## Impossibile impostare il periodo di retention dei backup su 0 Esistono diversi i motivi per cui potrebbe essere necessario impostare il periodo di retention dei backup su 0. Ad esempio, puoi disabilitare immediatamente i backup automatici impostando il periodo di retention su 0. In alcuni casi, potrebbe essere necessario impostare il valore su 0 e ricevere un messaggio che indica che il periodo di retention deve essere compreso tra 1 e 35. In questi casi, verificare di non aver impostato una replica di lettura per l'istanza. Le repliche di lettura richiedono i backup per gestire i log delle repliche di lettura e pertanto non puoi impostare un periodo di retention pari a 0.