Test d'Amazon Aurora PostgreSQL à l'aide des requêtes d'injection d'erreurs

Vous pouvez tester la tolérance aux pannes de votre cluster de base de données Aurora PostgreSQL à l'aide des requêtes d'injection d'erreurs. Les requêtes d'injection d'erreurs sont émises sous forme de commandes SQL à une instance Amazon Aurora. Les requêtes d'injection de panne vous permettent de créer une panne d'instance afin de tester le basculement et la récupération. Vous pouvez également simuler une panne de réplica Aurora, une panne de disque et une surcharge disque. Les requêtes d'injection de panne sont prises en charge par toutes les versions disponibles d'Aurora PostgreSQL, comme suit.

• Aurora PostgreSQL versions 12, 13, 14, et ultérieures

• Aurora PostgreSQL version 11.7 et ultérieures

• Aurora PostgreSQL version 10.11 et ultérieures

Lorsqu'une requête d'injection d'erreurs spécifie une panne, elle provoque la panne forcée de l'instance de base de données Aurora PostgreSQL. Les autres requêtes d'injection d'erreurs se traduisent par des simulations d'événements d'erreur, mais n'entraînent pas la manifestation de l'événement. Lorsque vous envoyez une requête d'injection d'erreurs, vous pouvez aussi spécifier la durée de la simulation de l'événement d'erreur.

Vous pouvez soumettre une requête d'injection d'erreurs à l'une de vos instances de réplica Aurora en vous connectant au point de terminaison du réplica Aurora. Pour plus d'informations, consultez Gestion des connexions Amazon Aurora.

Test d'un incident d'instance

Vous pouvez forcer l'arrêt d'une instance Aurora PostgreSQL en utilisant la fonction de requête d'injection d'erreurs aurora_inject_crash().

Pour cette requête d'injection d'erreurs, un basculement ne se produit pas. Si vous souhaitez tester un basculement, vous pouvez choisir l'action d'instance Failover pour votre cluster de base de données dans la console RDS, ou utiliser la failover-db-clusterAWS CLI commande ou l'opération d'API FailoverDBCluster RDS.

Syntaxe

SELECT aurora_inject_crash ('instance' | 'dispatcher' | 'node');

Options

Cette requête d'injection d'erreurs accepte l'un des types d'incident suivants. Le type d'incident n'est pas sensible à la casse.

'instance'

Simulation d'un incident de la base de données compatible PostgreSQL pour l'instance Amazon Aurora.

'répartiteur '

Simulation d'un incident lié au répartiteur sur l'instance principale pour le cluster de bases de données Aurora. Le répartiteur écrit les mises à jour sur le volume de cluster d'un cluster de bases de données Amazon Aurora.

'node'

Simulation d'un incident de la base de données compatible PostgreSQL et du répartiteur de l'instance Amazon Aurora.

Test d'une défaillance d'un réplica Aurora

Vous pouvez simuler la défaillance d'un réplica Aurora à l'aide de la fonction de requête d'injection d'erreurs aurora_inject_replica_failure().

Une défaillance du réplica Aurora bloque la réplication vers le réplica Aurora ou tous les réplicas Aurora du cluster de bases de données par le pourcentage spécifié pour l'intervalle de temps spécifié. Une fois l'intervalle de temps écoulé, les réplicas Aurora affectés sont automatiquement synchronisés avec l'instance principale.

Syntaxe

SELECT aurora_inject_replica_failure(
   percentage_of_failure, 
   time_interval, 
   'replica_name'
);

Options

La requête d'injection d'erreurs accepte les paramètres suivants :

percentage_of_failure

Pourcentage de réplications à bloquer pendant l'événement d'échec. La valeur peut être un nombre double compris entre 0 et 100. Si vous spécifiez 0, aucune réplication n'est bloquée. Si vous spécifiez 100, toute la réplication est bloquée.

time_interval

Durée de simulation de l'échec du réplica Aurora. L'intervalle est exprimé en secondes. Par exemple, si la valeur est de 20, la simulation s'exécute pendant 20 secondes.

Note

Soyez vigilant lorsque vous spécifiez l'intervalle de l'événement d'erreur du réplica Aurora. Si vous spécifiez un intervalle trop long et que votre instance d'écriture écrit une importante quantité de données pendant l'événement d'erreur, votre cluster de base de données Aurora peut considérer que votre réplica Aurora est en panne et le remplacer.

replica_name

Réplica Aurora dans lequel injecter la simulation d'échec. Spécifiez le nom d'un réplica Aurora pour simuler un échec du réplica Aurora unique. Spécifiez une chaîne vide pour simuler des échecs de tous les réplicas Aurora du cluster de base de données.

Pour identifier les noms de réplica, veuillez consulter la colonne server_id de la fonction aurora_replica_status(). Exemples :

postgres=> SELECT server_id FROM aurora_replica_status();

Test d'une défaillance disque

Vous pouvez simuler l'échec d'un disque pour un cluster de bases de données Aurora PostgreSQL en utilisant la fonction de requête d'injection d'erreurs aurora_inject_disk_failure().

Pendant la simulation d'un échec du disque, le cluster de base de données Aurora PostgreSQL marque de façon aléatoire les segments disque comme défectueux. Les demandes adressées à ces segments sont bloquées pendant la durée de la simulation.

Syntaxe

SELECT aurora_inject_disk_failure(
   percentage_of_failure, 
   index, 
   is_disk, 
   time_interval
);

Options

La requête d'injection d'erreurs accepte les paramètres suivants :

percentage_of_failure

Pourcentage du disque à marquer comme défaillant pendant l'événement d'échec. La valeur peut être un nombre double compris entre 0 et 100. Si vous spécifiez 0, aucune partie du disque n'est marquée comme défaillante. Si vous spécifiez 100, la totalité du disque est marquée comme défaillante.

index

Bloc de données logique spécifique pour lequel simuler l'événement d'erreur. Si vous dépassez la plage de blocs de données logiques ou de données de nœuds de stockage disponibles, vous recevez une erreur vous indiquant la valeur d'index maximale que vous pouvez spécifier. Pour éviter cette erreur, veuillez consulter Affichage du statut du volume pour un cluster de bases de données Aurora PostgreSQL.

is_disk

Indique si l'échec de l'injection concerne un bloc logique ou un nœud de stockage. Si vous définissez ce paramètre sur true, cela signifie que les échecs d'injection concernent un bloc logique. Si vous le définissez sur false, cela signifie que les échecs d'injection concernent un nœud de stockage.

time_interval

Durée nécessaire pour simuler la panne du disque. L'intervalle est exprimé en secondes. Par exemple, si la valeur est de 20, la simulation s'exécute pendant 20 secondes.

Test d'une surcharge disque

Vous pouvez simuler un encombrement de disque pour un cluster de bases de données Aurora PostgreSQL à l'aide de la fonction de requête d'injection de défauts. aurora_inject_disk_congestion()

Pendant la simulation d'une surcharge du disque, le cluster de base de données Aurora PostgreSQL marque de façon aléatoire les segments disque comme surchargés. Les demandes adressées à ces segments sont retardées entre le délai minimal et le délai maximal spécifiés de la durée de la simulation.

Syntaxe

SELECT aurora_inject_disk_congestion(
   percentage_of_failure, 
   index, 
   is_disk, 
   time_interval, 
   minimum, 
   maximum
);

Options

La requête d'injection d'erreurs accepte les paramètres suivants :

percentage_of_failure

Pourcentage du disque à marquer comme surchargé pendant l'événement d'échec. Il s'agit d'une valeur double comprise entre 0 et 100. Si vous spécifiez 0, aucune partie du disque n'est marquée comme surchargée. Si vous spécifiez 100, la totalité du disque est marquée comme surchargée.

index

Bloc logique spécifique de données ou de nœud de stockage à utiliser pour simuler l'événement d'erreur.

Si vous dépassez la plage de blocs de données logiques ou de données de nœuds de stockage disponibles, vous recevez une erreur vous indiquant la valeur d'index maximale que vous pouvez spécifier. Pour éviter cette erreur, veuillez consulter Affichage du statut du volume pour un cluster de bases de données Aurora PostgreSQL.

is_disk

Indique si l'échec de l'injection concerne un bloc logique ou un nœud de stockage. Si vous définissez ce paramètre sur true, cela signifie que les échecs d'injection concernent un bloc logique. Si vous le définissez sur false, cela signifie que les échecs d'injection concernent un nœud de stockage.

time_interval

Durée nécessaire pour simuler l'encombrement du disque. L'intervalle est exprimé en secondes. Par exemple, si la valeur est de 20, la simulation s'exécute pendant 20 secondes.

minimum, maximum

Durées minimale et maximale du délai de surcharge, en millisecondes. Les valeurs valides vont de 0,0 à 100,0 millisecondes. Les segments de disque marqués comme surchargés sont retardés pendant une durée aléatoire comprise entre la durée minimale et la durée maximale de la simulation. La valeur maximale doit être supérieure à la valeur minimale.