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à.
Test di Amazon Aurora PostgreSQL mediante query Fault Injection
Puoi testare la tolleranza ai guasti del tuo cluster di database Aurora PostgreSQL utilizzando query fault injection. Le query di errore di iniezione vengono emesse come comandi SQL per un'istanza Amazon Aurora. Le query fault injection consentono di arrestare l'istanza in maniera anomala per poter testare il failover e il ripristino. È anche possibile simulare errore della replica di Aurora Replica, errore del disco e congestione del disco. Le query di fault injection sono supportate da tutte le versioni di Aurora PostgreSQL disponibili, come riportato di seguito.
Aurora PostgreSQL versioni 12, 13, 14 e successive
Aurora PostgreSQL versione 11.7 e versioni successive
Aurora PostgreSQL versione 10.11 e versioni successive
Argomenti
Quando una query fault injection specifica un arresto anomalo, impone un arresto anomalo dell'istanza database di Aurora PostgreSQL. Le altre query fault injection generano simulazioni di eventi di errore, ma non causano l'evento. Quando invii una query fault injection, specifichi anche la durata della simulazione dell'evento di errore.
Puoi inviare una query fault injection a una delle istanze di replica Aurora eseguendo la connessione all'endpoint per la replica Aurora. Per ulteriori informazioni, consulta Connessioni endpoint Amazon Aurora.
Test dell'arresto anomalo di un'istanza
Puoi forzare un arresto anomalo di un'istanza Aurora PostgreSQL utilizzando la funzione query fault injection aurora_inject_crash().
Per questa query fault injection, non si verifica alcun failover. Se desideri testare un failover, puoi scegliere l'azione dell'istanza di failover per il tuo cluster DB nella console RDS o utilizzare il failover-db-clusterAWS CLI comando o l'operazione API FailoverDBCluster RDS.
Sintassi
SELECT aurora_inject_crash ('instance' | 'dispatcher' | 'node');
Opzioni
Questa query fault injection accetta uno dei seguenti tipi di arresto anomalo. Il tipo di arresto anomalo non rileva la distinzione tra maiuscole e minuscole:
- 'instance'
-
Viene simulato un arresto anomalo del database compatibile con PostgreSQL per l'istanza Amazon Aurora.
- 'dispatcher'.
-
Viene simulato un arresto anomalo del dispatcher sull'istanza primaria per il cluster di database Aurora. Il dispatcher scrive gli aggiornamenti sul volume del cluster per un cluster di database Amazon Aurora.
- 'node'
-
Viene simulato un arresto anomalo del database compatibile con PostgreSQL e del dispatcher per l'istanza Amazon Aurora.
Test di un errore di replica Aurora
Puoi simulare l'errore di una replica Aurora mediante la funzione query fault injection aurora_inject_replica_failure().
Un errore di replica Aurora blocca la replica nella replica Aurora o in tutte le repliche Aurora nel cluster di database in base alla percentuale specificata per l'intervallo di tempo specificato. Al termine di tale periodo, le repliche Aurora interessate sono automaticamente sincronizzate con l'istanza primaria.
Sintassi
SELECT aurora_inject_replica_failure( percentage_of_failure, time_interval, 'replica_name' );
Opzioni
Questa query fault injection accetta i seguenti parametri:
- percentage_of_failure
-
La percentuale di repliche da bloccare durante l'evento di errore. Può essere un valore tra 0 e 100. Se specifichi 0, non viene bloccata alcuna replica. Se specifichi 100, vengono bloccate tutte le repliche.
- time_interval
-
L'intervallo di tempo per simulare l'errore di replica Aurora. L'intervallo è in secondi. Ad esempio, se il valore è 20, la simulazione viene eseguita per 20 secondi.
Nota
Fai attenzione quando specifichi l'intervallo di tempo per l'evento di errore della replica Aurora. Se specifichi un intervallo troppo lungo e l'istanza di scrittura scrive una grande quantità di dati durante l'evento di errore, il cluster database Aurora potrebbe ritenere che si è verificato un arresto anomalo della replica Aurora e quindi sostituirla.
- replica_name
-
La replica Aurora in cui inserire la simulazione dell'errore. Specifica il nome della replica Aurora per simulare un errore di una singola replica Aurora. Specifica una stringa vuota per simulare errori per tutte le repliche Aurora nel cluster database.
Per identificare i nomi delle repliche, vedere la colonna
server_iddella funzioneaurora_replica_status(). Ad esempio:postgres=> SELECT server_id FROM aurora_replica_status();
Test di un errore del disco
Puoi simulare un errore del disco per un cluster database Aurora PostgreSQL mediante la funzione query fault injection aurora_inject_disk_failure().
Durante la simulazione di un errore del disco, il cluster di database Aurora PostgreSQL contrassegna in modo aleatorio i segmenti del disco come difettosi. Le richieste a tali segmenti sono bloccate per la durata della simulazione.
Sintassi
SELECT aurora_inject_disk_failure( percentage_of_failure, index, is_disk, time_interval );
Opzioni
Questa query fault injection accetta i seguenti parametri:
- percentage_of_failure
-
La percentuale del disco da contrassegnare come difettosa durante l'evento di errore. Può essere un valore tra 0 e 100. Se specifichi 0, nessuna parte del disco è contrassegnata come difettosa. Se specifichi 100, tutto il disco è contrassegnato come difettoso.
- index
-
Un blocco di dati logico specifico nel quale simulare l'evento di errore. Se viene superato l'intervallo di blocchi logici o di dati dei nodi di storage disponibili, viene generato un errore che indica il valore di indice massimo che puoi specificare. Per evitare questo errore, consulta Visualizzazione dello stato del volume per un cluster di database Aurora PostgreSQL.
- is_disk
-
Indica se l'errore di inserimento è in un blocco logico o in un nodo di storage. Se si specifica true, significa che gli errori di inserimento sono in un blocco logico. Se si specifica false, significa che gli errori di inserimento sono in un nodo di storage.
- time_interval
-
La quantità di tempo necessaria per simulare l'errore del disco. L'intervallo è in secondi. Ad esempio, se il valore è 20, la simulazione viene eseguita per 20 secondi.
Test di una congestione del disco
È possibile simulare una congestione del disco per un cluster Aurora PostgreSQL DB utilizzando la funzione di query di fault injection. aurora_inject_disk_congestion()
Durante la simulazione della congestione del disco, il cluster di database Aurora PostgreSQL contrassegna in modo aleatorio i segmenti del disco come congestionati. Le richieste a tali segmenti vengono ritardate di un periodo di tempo compreso tra il ritardo minimo e quello massimo specificati per la durata della simulazione.
Sintassi
SELECT aurora_inject_disk_congestion( percentage_of_failure, index, is_disk, time_interval, minimum, maximum );
Opzioni
Questa query fault injection accetta i seguenti parametri:
- percentage_of_failure
-
La percentuale del disco da contrassegnare come congestionata durante l'evento di errore. Questo è un doppio valore compreso tra 0 e 100. Se specifichi 0, nessuna parte del disco è contrassegnata come congestionata. Se specifichi 100, tutto il disco è contrassegnato come congestionato.
- index
-
Un blocco di dati logico o nodo storage specifico nel quale simulare l'evento di errore.
Se viene superato l'intervallo di blocchi logici o di dati dei nodi di storage disponibili, viene generato un errore che indica il valore di indice massimo che puoi specificare. Per evitare questo errore, consulta Visualizzazione dello stato del volume per un cluster di database Aurora PostgreSQL.
- is_disk
-
Indica se l'errore di inserimento è in un blocco logico o in un nodo di storage. Se si specifica true, significa che gli errori di inserimento sono in un blocco logico. Se si specifica false, significa che gli errori di inserimento sono in un nodo di storage.
- time_interval
-
La quantità di tempo necessaria per simulare la congestione del disco. L'intervallo è in secondi. Ad esempio, se il valore è 20, la simulazione viene eseguita per 20 secondi.
- minimum, maximum
-
Il valore minimo e massimo del ritardo di congestione in millisecondi. I valori validi sono compresi tra 0,0 e 100,0 millisecondi. I segmenti del disco contrassegnati come congestionati vengono ritardati per un periodo di tempo aleatorio compreso nell'intervallo del valore minimo e massimo per la durata della simulazione. Il valore massimo deve essere maggiore del valore minimo.
