Quels sont les facteurs qui influent sur les temps d'arrêt des clusters de base de données Amazon Aurora ?

Brève description

Vos instances de base de données Amazon Aurora peuvent être indisponibles pour plusieurs raisons. Les principaux facteurs qui influent sur les temps d'arrêt sont les suivants :

• Mises à niveau de la version
• Basculements de clusters de bases de données
• Tâches de maintenance
• Redémarrage d'un cluster ou d'une instance de DB
• Modification de paramètres spécifiques sur votre cluster ou instance de base de données

Résolution

**Remarque :**Si vous recevez des erreurs lors de l'exécution des commandes de l'interface de ligne de commande AWS (AWS CLI), assurez-vous que vous utilisez la version la plus récente de l'interface de ligne de commande AWS.

Mises à niveau de la version

Les mises à niveau des versions du moteur incluent les mises à niveau majeures et mineures. Les mises à niveau des versions majeures et mineures entraînent des interruptions de service pour l'ensemble de votre cluster de base de données Aurora. Avant de mettre à niveau un cluster de base de données de production, il est important de tester le processus de mise à niveau sur un cluster de base de données de test. Vérifiez la durée du processus, puis validez vos applications avant d'effectuer la mise à niveau.

Vous pouvez également utiliser les déploiements bleu/vert d'Amazon Relational Database Service (Amazon RDS) pour mettre à niveau la version majeure ou mineure de votre cluster. Les temps d'arrêt durent généralement moins d'une minute pour les mises à niveau lors de déploiements bleu/vert.

Mises à niveau automatiques des versions mineures

Les mises à niveau automatiques des versions mineures entraînent des interruptions de service pour l'ensemble de votre cluster de base de données Aurora. Ces mises à niveau automatiques des versions mineures sont appliquées pendant la fenêtre de maintenance du cluster. Si vous n'avez pas besoin de cette fonctionnalité, désactivez les mises à niveau automatiques des versions mineures sur vos instances de base de données.

Pour plus d'informations, consultez la section Mise à niveau de la version mineure ou du niveau de correctif d'un cluster de bases de données Aurora MySQL.

Remarque : L'activation de la fonctionnalité de mise à niveau automatique des versions mineures elle-même n'entraîne pas de temps d'arrêt pendant la modification. Le temps d'arrêt se produit uniquement lorsqu'Aurora applique la mise à niveau automatique.

Basculement de clusters de bases de données

Si votre cluster de base de données Aurora possède une ou plusieurs répliques Aurora, la réplique est promue en instance principale lors des événements de basculement. Un bref arrêt se produit et les opérations de lecture et d'écriture échouent à une exception près. Le service est généralement restauré en moins de 120 secondes, et souvent en moins de 60 secondes.

Pour augmenter la disponibilité de votre cluster de base de données, créez une ou plusieurs répliques Aurora dans au moins deux zones de disponibilité (AZ) différentes. Pour plus d'informations, consultez Tolérance aux pannes pour un cluster de base de données Aurora.

Tâches de maintenance pour votre cluster de base de données Aurora

Certaines tâches de maintenance, telles que les mises à jour du système d'exploitation (OS) ou l'application de correctifs aux bases de données, entraînent la mise hors ligne de votre cluster de base de données pendant une courte période. Pour plus d'informations, consultez Maintenance d'un cluster de base de données Amazon Aurora.

Fenêtre de maintenance

Les temps d'arrêt ne se produisent pas de manière inhérente lorsque vous modifiez la fenêtre de maintenance. Toutefois, votre cluster de base de données peut avoir une ou plusieurs actions en attente qui entraînent une interruption de service. Si vous modifiez la fenêtre de maintenance, vous appliquez immédiatement les actions en attente, ce qui entraîne une interruption de service. Pour plus d'informations sur la modification de votre fenêtre de maintenance, consultez Que dois-je savoir à propos de la fenêtre de maintenance Amazon RDS ?

Redémarrage du cluster ou de l'instance de base de données

Le redémarrage d'un cluster de base de données ou d'une instance de base de données entraîne une interruption de service. Le temps requis pour redémarrer chaque instance de base de données de votre cluster dépend de l'activité de la base de données au moment du redémarrage. Les temps d'arrêt dépendent également du processus de restauration de votre moteur de base de données spécifique. Pour plus d'informations, consultez Redémarrage d'un cluster de base de données Amazon Aurora ou d'une instance de base de données Amazon Aurora.

Modification de la classe d'instance de base de données

Lorsque vous modifiez la classe d'instance de base de données de votre instance, un temps d'arrêt se produit sur l'instance de base de données spécifiée, mais pas sur l'ensemble du cluster. Pour plus d'informations sur les classes d'instance, consultez la section Classes d'instance de base de données Aurora.

Attacher un nouveau cluster de base de données ou un nouveau groupe de paramètres de base de données

Lorsque vous modifiez le cluster de base de données ou le groupe de paramètres de base de données associé à votre instance de base de données, les temps d'arrêt ne se produisent pas automatiquement. Toutefois, pour appliquer des modifications à un groupe de paramètres de cluster de bases de données, vous devez redémarrer l'instance de base de données principale du cluster. Pour les groupes de paramètres de base de données, vous devez redémarrer l'instance pour appliquer les modifications. Le redémarrage lui-même entraîne une interruption de service. Pour plus d'informations, consultez Associer un groupe de paramètres de cluster de bases de données à un cluster de bases de données et Utilisation de groupes de paramètres.

Modification de paramètres spécifiques sur votre cluster ou instance de base de données

Modification des paramètres dans un cluster de bases de données ou un groupe de paramètres de base de données

Les paramètres de base de données sont statiques ou dynamiques. Lorsque vous modifiez un paramètre statique dans un cluster de bases de données ou un groupe de paramètres de base de données, le changement de paramètre prend effet après le redémarrage manuel des instances de base de données dans chaque cluster de base de données associé. Un temps d'arrêt se produit pendant le redémarrage.

Toutefois, lorsque vous modifiez un paramètre dynamique dans un cluster de bases de données ou un groupe de paramètres de base de données, les modifications sont immédiatement appliquées à votre cluster de bases de données. L'instance n'est pas redémarrée lorsque vous modifiez les paramètres dynamiques, il n'y a donc pas de temps d'arrêt.

Pour plus d'informations, consultez la section Utilisation de groupes de paramètres.

Modification de l'identifiant de l'instance de base de données

Un temps d'arrêt se produit lorsque vous modifiez l'identifiant de l'instance de base de données car l'instance de base de données est redémarrée.

Modification du port de base de données

Un temps d'arrêt se produit lorsque vous modifiez le port de base de données que vous souhaitez utiliser pour accéder à votre cluster de bases de données. Cela se produit car toutes les instances de base de données du cluster de bases de données redémarrent immédiatement.

Modification de l'autorité de certification

Vous souhaiterez peut-être modifier l'autorité de certification (CA) du certificat de serveur utilisé par votre instance de base de données. Dans ce cas d'utilisation, un arrêt se produit si le moteur de base de données ne prend pas en charge la rotation sans redémarrage. Utilisez la commande describe-db-engine-versions de l'AWS CLI pour vérifier si le moteur de base de données prend en charge la rotation sans redémarrage.

Pour plus d'informations sur les paramètres d'Aurora qui influencent ou non les temps d'arrêt, consultez Paramètres d'Amazon Aurora.

Informations connexes

Réalisation de mises à niveau de versions majeures pour Amazon Aurora MySQL avec un minimum de temps d'arrêt