Risoluzione dei problemi per Amazon RDS - Amazon Relational Database Service
Impossibile connettersi all'istanza database di Problemi relativi alla sicurezzaRisoluzione dei problemi relativi allo stato di rete non compatibileReimpostazione della password del ruolo di proprietario dell'istanza di databaseErrore o riavvio di un'istanza di databaseModifiche ai parametri che non hanno effettoMancanza di spazio di storage per l'istanza di databaseCapacità insufficiente dell'istanza di databaseProblemi di memoria liberabile RDSProblemi relativi a MySQL e MariaDBImpossibile impostare il periodo di retention dei backup su 0

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.

Per informazioni sui problemi di debug con l'API Amazon RDS, consulta Risoluzione dei problemi delle applicazioni in Amazon RDS.

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.

    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.

  • 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 tuo 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 AWS Management Console e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

    2. Nel riquadro di navigazione, scegliere Databases (Database) e selezionare il nome dell'istanza database.

    3. Nella scheda Connectivity & security (Connettività e sicurezza) annotare i valori dell'ID VPC in VPC e l'ID della sottorete in Subnets (Sottoreti).

    4. Accedere alla console Amazon VPC all'indirizzo https://console.aws.amazon.com/vpc/.

    5. 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.

    6. Nel riquadro di navigazione scegliere Subnets (Sottoreti) e selezionare la sottorete desiderata.

    7. 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 si sta effettuando la connessione all'istanza utilizzando il relativo indirizzo IPv6, verificare che sia disponibile un instradamento per tutto il traffico IPv6 (::/0) che punti all'Internet gateway. In caso contrario, eseguire le seguenti operazioni:

      1. Selezionare l'ID per la tabella di routing (rtb-xxxxxxxx) per navigare alla tabella di routing.

      2. 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.

        Per IPv6, selezionare Add route (Aggiungi route), utilizzare ::/0 come destinazione e il gateway internet come target.

      3. Selezionare Save routes (Salva route).

      Inoltre, se stai tentando di connetterti all'endpoint IPv6, assicurati che l'intervallo di indirizzi IPv6 del client sia autorizzato a connettersi all'istanza database.

    Per ulteriori informazioni, consulta Uso di un'istanza database in un VPC.

Per problemi di connessione specifici del motore, consulta i seguenti argomenti:

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.

Problemi relativi alla sicurezza di Amazon RDS

Per evitare problemi di sicurezza, non utilizzare mai il nome AWS utente principale e la password per un account utente. È consigliabile utilizzare il master Account AWS per creare utenti e assegnarli agli account utente DB. Puoi anche utilizzare il tuo account principale per creare altri account utente, se necessario.

Per informazioni sulla creazione di utenti, consulta Creazione di un utente IAM nell' Account AWS. Per informazioni sulla creazione di utenti in AWS IAM Identity Center, consulta Gestire le identità in IAM Identity Center.

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.

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/ e scegli Database nel pannello di navigazione.

  2. Scegli l'istanza database che si trova nello stato di rete non compatibile e annota l'identificatore dell'istanza database, l'ID del VPC e gli ID di sottorete nella scheda Connettività e sicurezza.

  3. Usa il AWS CLI per eseguire il start-db-instance comando. 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. 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) o utilizzando uno strumento di backup e ripristino.

Se il problema persiste, contatta AWS Support 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.

Puoi modificare la password dell'istanza DB utilizzando la console Amazon RDS, il AWS CLI comando o utilizzando l'modify-db-instanceoperazione API ModifyDBInstance. Per ulteriori informazioni sulla modifica di un'istanza database, consulta Modifica di un'istanza database Amazon RDS.

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.

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 RebootDBInstance. È 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 di parametri in un gruppo di parametri del database.

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 la tua istanza DB abbia abbastanza spazio di archiviazione libero.

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 LinuxmacOS, oUnix:

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.

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

Capacità insufficiente dell'istanza di 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 nella Guida per l'utente Amazon EC2.

Per ulteriori informazioni sulla modifica di un'istanza database, consulta Modifica di un'istanza database Amazon RDS.

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 disponibile. Per ulteriori informazioni, consulta Panoramica del monitoraggio dei parametri di Amazon RDS.

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 database.

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?

Problemi relativi a MySQL e MariaDB

Puoi diagnosticare e risolvere i problemi relativi alle istanze database MySQL e MariaDB.

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 database.

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 e Utilizzo di gruppi di parametri.

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

      Puoi modificare il valore per. innodb_buffer_pool_size Tuttavia, il valore non corrisponderà sempre a quello immesso. Questa mancata corrispondenza si verifica per diversi motivi. Innanzitutto, se l'istanza DB è un'istanza micro DB, sovrascriviamo il valore predefinito e lo impostiamo su 256 MB. Per ulteriori informazioni, consulta Sovrascrivere innodb_buffer_pool_size.

      In secondo luogo, ci assicuriamo che 500 MB di memoria siano riservati sull'istanza DB per l'host manager, il motore, il sistema operativo e il kernel.

      Infine, ottimizziamo innodb_buffer_pool_size dividendola in unità. L'host manager arrotonda per difetto al multiplo più vicino di tali unità. Le unità vengono calcolate innodb_buffer_pool_chunk_size moltiplicando per. innodb_buffer_pool_instances Per ulteriori informazioni, vedere Configurazione della dimensione del pool di buffer di InnoDB nella documentazione di MySQL.

      L'impostazione predefinita innodb_buffer_pool_instances è 8, a meno che non innodb_buffer_pool_size sia inferiore a 1 GB. Se innodb_buffer_pool_size è inferiore a 1 GB, l'impostazione predefinita per innodb_buffer_pool_instances è 1. L'impostazione predefinita 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 istanza database .

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 di parametri in un gruppo di parametri del database.

  2. Riavviare l'istanza database.

    Per informazioni sull'estensione dei parametri consulta Avvio di un'istanza database Amazon RDS arrestata in precedenza.

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 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 relativo alla replica di lettura MySQL o MariaDB. 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 e MySQL utilizzavano SHOW SLAVE STATUS anziché SHOW REPLICA STATUS. Se si utilizza una versione di MariaDB precedente alla 10.5 o una versione di MySQL precedente alla 8.0.23, utilizzare 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. Contemporaneamente, le operazioni di scrittura nella 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 nella documentazione di MySQL. Per ulteriori informazioni sulle repliche di lettura e su MariaDB, consulta la pagina della panoramica della replica 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.

  • 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.

    PerLinux, o: macOS Unix

    PROMPT> mysqldump \
    -h <endpoint> \
    --port=<port> \
    -u=<username> \
    -p <password> \
    database_name table1 table2 > /dev/null

    Per Windows:

    PROMPT> mysqldump ^
    -h <endpoint> ^
    --port=<port> ^
    -u=<username> ^
    -p <password> ^
    database_name table1 table2 > /dev/null

Diagnosi e risoluzione di un errore relativo alla 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, RDS-EVENT-0046 e RDS-EVENT-0057. Per ulteriori informazioni sugli eventi e sulla sottoscrizione a essi, consulta Utilizzo della notifica degli eventi di Amazon RDS. Se viene restituito un messaggio di errore MySQL, controlla l'errore nella documentazione dei messaggi di errore MySQL. Se viene restituito un messaggio di errore MariaDB, controlla l'errore nella documentazione dei messaggi di errore MariaDB.

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 <schema>.<table_name> 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 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. 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_skip_repl_error.

  • Se si verifica un problema di posizione del log binario (binlog), puoi modificare la posizione di riproduzione della replica con il comando mysql_rds_next_master_log. L'istanza database MySQL o MariaDB deve eseguire una versione che supporti il comando mysql_rds_next_master_log per modificare la posizione di riproduzione della replica. Per informazioni sulla versione, consulta 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.

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 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 LinuxmacOS, oUnix:

    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"

  2. Modifica il gruppo di parametri di database per consentire i trigger.

    Per LinuxmacOS, oUnix:

    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"

  3. Modifica l'istanza di database per utilizzare il nuovo gruppo di parametri di database.

    Per LinuxmacOS, oUnix:

    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

  4. Per rendere effettive le modifiche, riavvia manualmente l'istanza database.

    aws rds reboot-db-instance --db-instance-identifier mydbinstance

Diagnosi e risoluzione degli errori point-in-time di ripristino

Ripristino di un'istanza di 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. Se utilizzi tabelle temporanee nell'istanza database MySQL o MariaDB, puoi ridurre la possibilità di un errore PITR. A questo scopo, esegui 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 di 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 e Ripristino a un'ora specifica per un'istanza database.

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, potresti riscontrare 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_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

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.