Seleziona le tue preferenze relative ai cookie

Utilizziamo cookie essenziali e strumenti simili necessari per fornire il nostro sito e i nostri servizi. Utilizziamo i cookie prestazionali per raccogliere statistiche anonime in modo da poter capire come i clienti utilizzano il nostro sito e apportare miglioramenti. I cookie essenziali non possono essere disattivati, ma puoi fare clic su \"Personalizza\" o \"Rifiuta\" per rifiutare i cookie prestazionali.

Se sei d'accordo, AWS e le terze parti approvate utilizzeranno i cookie anche per fornire utili funzionalità del sito, ricordare le tue preferenze e visualizzare contenuti pertinenti, inclusa la pubblicità pertinente. Per continuare senza accettare questi cookie, fai clic su \"Continua\" o \"Rifiuta\". Per effettuare scelte più dettagliate o saperne di più, fai clic su \"Personalizza\".

Preferenze
Contattaci
Feedback
AWS Documentation
Crea un Account AWS
Risoluzione dei problemi per Amazon Aurora - Amazon Aurora
Impossibile connettersi all'istanza database di Problemi relativi alla sicurezzaReimpostazione della password del ruolo di proprietario dell'istanza di databaseErrore o riavvio di un'istanza di databaseModifiche ai parametri che non hanno effettoProblemi di memoria liberabile AuroraProblemi di replica di Aurora MySQL

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

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 Aurora

PDFRSS

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

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 l'accesso al cluster DB VPC tramite la creazione di 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 cluster database in un VPC da Internet.

  • Porta: la porta specificata al momento della creazione dell'istanza DB 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 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. Apri la 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 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.

      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.

        Ad esempio IPv6, scegli Aggiungi percorso, utilizza ::/0 come destinazione e il gateway Internet come destinazione.

      3. 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 cluster database in un VPC.

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.

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. È consigliabile utilizzare l'utente root per creare utenti e assegnarli agli account utente DB. È inoltre 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. 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.

Reimpostazione della password del ruolo di proprietario dell'istanza di database

Se si viene bloccati dal cluster di 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 modify-db-instanceo utilizzando l'operazione Modify DBInstance API. Per ulteriori informazioni sulla modifica di un'istanza database in un cluster di database, consulta Modifica di un'istanza database in un cluster database.

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.

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.

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 dei parametri in un gruppo di parametri DB in .

Problemi di memoria liberabile in Amazon Aurora

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 Strumenti di monitoraggio per Aurora.

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 Amazon Aurora.

Inoltre, puoi modificare le impostazioni della memoria. Ad esempio, in Aurora 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?

In Aurora Serverless v2, FreeableMemory rappresenta la quantità di memoria inutilizzata disponibile quando Aurora Serverless v2 L'istanza DB viene scalata fino alla capacità massima. È possibile che l'istanza sia stata ridotta a una capacità relativamente bassa, ma continui a segnalare un valore elevato per FreeableMemory, perché l'istanza può aumentare. Questa memoria non è disponibile al momento, ma puoi recuperarla se ti serve.

Per ogni unità di capacità Aurora (ACU) la cui capacità corrente è inferiore alla capacità massima, FreeableMemory aumenta di circa 2 GiB. Pertanto, questo parametro non si avvicina a zero finché non viene eseguito il dimensionamento verso l'alto dell'istanza database fino al valore più alto possibile.

Se questo parametro si avvicina al valore 0, è stato raggiunto il massimo di aumento dell'istanza database. Ovvero al valore più prossimo al limite di memoria disponibile. Valuta la possibilità di aumentare l'impostazione ACU massima per il cluster. Se il valore di questo parametro si avvicina a 0 per un'istanza database di lettura, valuta la possibilità di aggiungere altre istanze database di lettura al cluster. In questo modo, puoi distribuire la parte di sola lettura del carico di lavoro su più istanze database e ridurre conseguentemente l'utilizzo della memoria su ogni istanza database di lettura. Per ulteriori informazioni, consulta CloudWatch Parametri Amazon importanti per Aurora Serverless v2.

In Aurora Serverless v1, è possibile modificare l'intervallo di capacità per utilizzarne di più ACUs. Per ulteriori informazioni, consulta Modificare un Aurora Serverless v1 cluster di database.

Problemi di replica relativi a Amazon Aurora MySQL

Alcuni problemi di replica MySQL si applicano anche a Aurora MySQL. Puoi diagnosticare e risolvere questi problemi.

Diagnosi e risoluzione del ritardo tra repliche di lettura

Quando una replica di lettura MySQL 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.

Il parametro AuroraBinlogReplicaLag indica il valore del campo Seconds_Behind_Master del comando SHOW REPLICA STATUS di MySQL. Per ulteriori informazioni, consulta Istruzione SHOW REPLICA STATUS nella documentazione di MySQL.

Quando il parametro AuroraBinlogReplicaLag è 0, la replica ha raggiunto l'istanza del database di origine. Se il parametro AuroraBinlogReplicaLag 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. Un valore di AuroraBinlogReplicaLag pari a -1 può anche indicare che il valore di Seconds_Behind_Master non può essere determinato oppure è NULL.

Nota

Versioni precedenti di Aurora MySQL utilizzavano SHOW SLAVE STATUS al posto di SHOW REPLICA STATUS. Se si utilizza una versione 1 o 2 Aurora MySQL, utilizzare SHOW SLAVE STATUS. Utilizzare SHOW REPLICA STATUS per Aurora MySQL versione 3 e successive.

Il parametro AuroraBinlogReplicaLag 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 AuroraBinlogReplicaLag.

La tecnologia di replica di lettura di MySQL è asincrona. Pertanto, è possibile che si verifichino incrementi occasionali del parametro BinLogDiskUsage nell'istanza database di origine e del parametro AuroraBinlogReplicaLag 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.

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

    In Linux, macOS, oppure Unix:

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

    In 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

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 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 delle notifiche di RDS eventi di Amazon. Se viene restituito un messaggio di errore MySQL, controlla l'errore nella documentazione dei messaggi di errore MySQL.

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, segui le fasi descritte in Ignorare l'errore di replica corrente. L'istanza database Aurora MySQL 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 registro binario (binlog), puoi modificare la posizione di riproduzione della replica. Per farlo, utilizza il comando mysql.rds_next_master_log per Aurora MySQL versione 1 e 2. Per farlo, utilizza il comando mysql.rds_next_source_log per Aurora MySQL versione 3 e successive. L'istanza database Aurora MySQL deve eseguire una versione che supporta questo comando per modificare la posizione di riproduzione della replica. Per informazioni sulle versioni, consulta mysql_rds_next_master_log.

  • Se si verifica un problema temporaneo di prestazioni a causa dell'elevato carico DML, è possibile impostare il innodb_flush_log_at_trx_commit parametro su 2 nel gruppo di parametri DB 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.

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, è possibile che si verifichi un errore irreversibile a causa dell'eliminazione dei file di registro binari prima che vengano 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 "ore di conservazione dei file binlog” insieme al numero di ore di conservazione dei file binlog nel cluster di database, fino a 2160 (90 giorni). Il valore predefinito per Aurora MySQL è 24 (1 giorno). Nell'esempio seguente il periodo di retention dei file binlog è impostato su 48 ore.

CALL mysql.rds_set_configuration('binlog retention hours', 48);

La replica in lettura non riesce a inizializzare la struttura dei metadati

Quando hai tentato di avviare la replica, hai 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 quando c'è un problema con la 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 seguenti azioni:

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

Argomento precedente:

Quote e vincoli

Hai bisogno di aiuto?

PrivacyCondizioni del sitoPreferenze cookie
© 2025, Amazon Web Services, Inc. o società affiliate. Tutti i diritti riservati.