Risoluzione dei problemi per Amazon Aurora

Utilizza le seguenti sezioni per risolvere i problemi relativi alle istanze DB in Amazon e Amazon RDS Aurora.

Per informazioni sui problemi di debug con Amazon RDSAPI, consulta. Risoluzione dei problemi delle applicazioni in Aurora

Impossibile connettersi all'istanza Amazon RDS DB

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 a VPC che consente il traffico in entrata e in uscita dall'istanza DB. Se necessario, aggiungi regole in entrata e in uscita per la situazione particolare al gruppo di sicurezza. È possibile specificare un indirizzo IP, un intervallo di indirizzi IP o un altro gruppo VPC di sicurezza.

  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 dell'intervallo di indirizzamento IP privato automatico (APIPA), utilizzato per l'indirizzamento dei collegamenti locali.

• Accessibilità pubblica: per connettersi all'istanza DB dall'esterno diVPC, ad esempio utilizzando un'applicazione client, all'istanza deve essere assegnato 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 un cluster di DB in un ambiente 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 a AWS Management Console e apri la RDS console Amazon 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 Connettività e sicurezza, annota i valori dell'VPCID sotto VPCe dell'ID di sottorete in Subnet.

  4. Apri la VPC console Amazon all'indirizzo https://console.aws.amazon.com/vpc/.

  5. Nel riquadro di navigazione, scegliere Internet Gateways. Verifica che sia collegato un gateway Internet al tuoVPC. In caso contrario, scegliere Create Internet Gateway (Crea Internet gateway) per crearne uno. Seleziona il gateway Internet, quindi scegli Collega a VPC e segui le istruzioni per collegarlo al tuoVPC.

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

  7. Nella scheda Route Table, verifica che ci sia un percorso 0.0.0.0/0 come destinazione e il gateway Internet VPC corrispondente come destinazione.

     Se ti connetti all'istanza utilizzando il relativo IPv6 indirizzo, verifica che esista un percorso per tutto il IPv6 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 esempioIPv6, scegli Aggiungi percorso, utilizza ::/0 come destinazione e il gateway Internet come destinazione.

     3. Seleziona Salva route.

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

  Per ulteriori informazioni, consulta Lavorare con un cluster di DB 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 Internet Control Message Protocol (ICMP), 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. Puoi farlo modificando l'RDSistanza.

Problemi RDS di sicurezza di Amazon

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 IAM utente in Account AWS. Per informazioni sulla creazione di utenti in AWS IAM Identity Center, consulta Gestire le IAM identità in 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 IAM documentazione.

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 RDS console Amazon modify-db-instance, il AWS CLI comando o utilizzando l'odifyDBInstanceAPIoperazione M. Per ulteriori informazioni sulla modifica di un'istanza database in un cluster di database, consulta Modifica di un'istanza database in un cluster database.

Interruzione o riavvio dell'istanza Amazon RDS DB

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.

Le modifiche ai parametri di Amazon RDS DB 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 DB utilizzando la RDS console. Oppure puoi chiamare esplicitamente l'RebootDBInstanceAPIoperazione. È possibile riavviare senza failover se l'istanza database è in un'implementazione Multi-AZ. Il requisito di riavviare l'istanza DB associata dopo una modifica statica dei parametri aiuta a mitigare il rischio che un'errata configurazione dei parametri influisca sulla 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 .

La memoria liberabile è la memoria ad accesso casuale totale (RAM) su un'istanza DB che può essere messa a disposizione del 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 dell'host, ma anche i processi del sistema operativo ne utilizzano una parteRAM. 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 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, su Aurora My SQL RDS , puoi regolare la dimensione del innodb_buffer_pool_size parametro. Questo parametro è impostato per default sul 75% della memoria fisica. Per ulteriori informazioni sui miei suggerimenti per la SQL risoluzione dei problemi, consulta Come posso risolvere i problemi di scarsa memoria disponibile in un database Amazon RDS for My? SQL

Per Aurora Serverless v2, FreeableMemory rappresenta la quantità di memoria inutilizzata disponibile quando viene eseguito il dimensionamento dell'istanza database di Aurora Serverless v2 fino alla sua 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à attuale è 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'ACUimpostazione 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.

InfattiAurora Serverless v1, puoi modificare l'intervallo di capacità per utilizzarne di piùACUs. Per ulteriori informazioni, consulta Modifica di un cluster di database Aurora Serverless v1.

Aurora I miei problemi di replica SQL

Alcuni problemi relativi SQL alla replica personale si applicano anche ad SQL Aurora My. Puoi diagnosticare e risolvere questi problemi.

Argomenti

• Diagnosi e risoluzione del ritardo tra repliche di lettura
• Diagnosi e risoluzione di un errore di replica di lettura My o SQL
• Errore di replica interrotta

Diagnosi e risoluzione del ritardo tra repliche di lettura

Dopo aver creato una replica di lettura My SQL e aver reso disponibile la replica, RDS Amazon replica innanzitutto le modifiche apportate all'istanza DB di origine dal momento in cui è iniziata l'operazione di creazione della replica di lettura. Durante questa fase, il ritardo di replica per la replica di lettura è maggiore di 0. Puoi monitorare questo ritardo in Amazon CloudWatch visualizzando la RDS metrica Amazon.

La AuroraBinlogReplicaLag metrica riporta il valore del campo del Seconds_Behind_Master comando My. SQL SHOW REPLICA STATUS Per ulteriori informazioni, consulta la sezione SHOWREPLICASTATUSDichiarazione nella SQL documentazione personale.

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 di replica di lettura My o SQL . Un valore di AuroraBinlogReplicaLag pari a -1 può anche indicare che il valore di Seconds_Behind_Master non può essere determinato oppure è NULL.

Nota

Le versioni precedenti di Aurora My venivano SQL utilizzate SHOW SLAVE STATUS al posto di. SHOW REPLICA STATUS Se utilizzi Aurora My SQL versione 1 o 2, usa. SHOW SLAVE STATUS Utilizzare SHOW REPLICA STATUS per Aurora My SQL 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 My SQL è 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 su read replicas e MySQL, consulta i dettagli sull'implementazione della replica nella documentazione My. SQL

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.

• 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, o: Linux 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 di replica di lettura My o SQL

Amazon RDS monitora lo stato di replica delle repliche di lettura. RDSaggiorna il campo Replication State dell'istanza di replica letta indicando Error se la replica si interrompe per qualsiasi motivo. È possibile esaminare i dettagli dell'errore associato generato dai motori My SQL visualizzando il campo Replication Error. 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 SQL di errore My, controlla l'errore nella documentazione Il mio SQL messaggio di errore.

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 max_allowed_packet parametro viene utilizzato per specificare la dimensione massima del linguaggio di manipolazione dei dati (DML) che può essere eseguito 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.

• Utilizzando un motore di archiviazione non transazionale come My. ISAM Le repliche di lettura richiedono un motore di storage transazionale. La replica è supportata solo per i seguenti motori di archiviazione: InnoDB for My SQL o MariaDB.

  Puoi convertire una ISAM tabella My in InnoDB con il seguente comando:

  alter table <schema>.<table_name> engine=innodb;

• Utilizzo di query non deterministiche non sicure come SYSDATE(). Per ulteriori informazioni, vedere Determinazione delle istruzioni sicure e non sicure nella registrazione binaria nella documentazione My. SQL

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 Aurora My SQL DB deve eseguire una versione che includa la mysql_rds_skip_repl_error procedura. 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. Puoi farlo con il mysql.rds_next_master_log comando per Aurora My SQL versione 1 e 2. Puoi farlo con il mysql.rds_next_source_log comando per Aurora My SQL versione 3 e successive. L'istanza Aurora My SQL DB deve eseguire una versione che supporti 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 di un DML carico elevato, è possibile impostare il innodb_flush_log_at_trx_commit parametro su 2 nel gruppo di parametri DB sulla replica di lettura. Ciò può aiutare la replica di lettura a recuperare il ritardo, sebbene riduca temporaneamente l'atomicità, la consistenza, l'isolamento e la durata ()ACID.

• 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 di un problema relativo alla replica di My SQL read.

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 "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). L'impostazione predefinita per Aurora My SQL è 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);