Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Redémarrage d'un cluster Aurora avec disponibilité en lecture
Grâce à la fonctionnalité de disponibilité en lecture, vous pouvez redémarrer l'instance d'écriture de votre cluster Aurora sans redémarrer les instances de lecteur du cluster de base de données principal ou secondaire. Cela peut contribuer à maintenir une haute disponibilité du cluster pour les opérations de lecture pendant que vous redémarrez l'instance d'enregistreur. Vous pouvez redémarrer les instances de lecteur plus tard, selon un calendrier qui vous convient. Par exemple, dans un cluster de production, vous pouvez redémarrer les instances du lecteur une par une, en commençant uniquement lorsque le redémarrage de l'instance principale est terminé. Pour chaque instance de base de données que vous redémarrez, suivez la procédure décrite dans Redémarrage d'une instance de base de données au sein d'un cluster Aurora.
La fonctionnalité de disponibilité en lecture pour les clusters de base de données principaux est disponible dans Aurora My SQL version 2.10 et versions ultérieures. La disponibilité en lecture pour les clusters de base de données secondaires est disponible dans Aurora My SQL version 3.06 et supérieure.
Pour Aurora Postgre, SQL cette fonctionnalité est disponible par défaut dans les versions suivantes :
Versions 15.2 et 15 ultérieures
Versions 14.7 et 14 ultérieures
Versions 13.10 et 13 ultérieures
Versions 12.14 et 12 ultérieures
Pour plus d'informations sur la fonctionnalité de disponibilité de lecture d'Aurora PostgreSQL, consultezAmélioration de la disponibilité en lecture des réplicas Aurora.
Avant cette fonctionnalité, le redémarrage de l'instance principale entraînait le redémarrage simultané de chaque instance de lecteur. Si votre cluster Aurora exécute une version plus ancienne, utilisez plutôt la procédure de redémarrage dans Redémarrage d'un cluster Aurora sans disponibilité en lecture.
Note
La modification du comportement de redémarrage dans les clusters de base de données Aurora avec disponibilité en lecture est différente pour les bases de données globales Aurora dans SQL les versions d'Aurora My inférieures à 3.06. Si vous redémarrez l'instance d'enregistreur pour le cluster principal dans une base de données globale Aurora, les instances de lecteur du cluster principal restent disponibles. Toutefois, les instances de base de données de tous les clusters secondaires redémarrent en même temps.
Une version limitée de la fonctionnalité améliorée de disponibilité en lecture est prise en charge par les bases de données globales Aurora pour les SQL versions 12.16, 13.12, 14.9, 15.4 et supérieures d'Aurora Postgre.
Vous redémarrez fréquemment le cluster après avoir apporté des modifications aux groupes de paramètres du cluster. Vous modifiez les paramètres en suivant les procédures décrites dans Groupes de paramètres pour Amazon Aurora. Supposons que vous redémarriez l'instance de base de données d'enregistreur dans un cluster Aurora pour appliquer des modifications aux paramètres du cluster. Certaines ou toutes les instances de base de données de lecteur peuvent continuer à utiliser les anciens paramètres. Toutefois, les différents paramètres de paramètres n'affectent pas l'intégrité des données du cluster. Tous les paramètres de cluster qui affectent l'organisation des fichiers de données sont uniquement utilisés par l'instance de base de données d'enregistreur.
Par exemple, dans un SQL cluster Aurora My, vous pouvez mettre à jour les paramètres du cluster tels que binlog_format et innodb_purge_threads sur l'instance du rédacteur avant les instances du lecteur. Seule l'instance d'enregistreur écrit des journaux binaires et purge les enregistrements d'annulation. Pour les paramètres qui modifient la façon dont les requêtes interprètent les SQL instructions ou les résultats des requêtes, vous devrez peut-être prendre soin de redémarrer immédiatement les instances du lecteur. Vous procédez de cette façon pour éviter tout comportement inattendu de l'application lors des requêtes. Par exemple, supposons que vous modifiiez le paramètre lower_case_table_names et que vous redémarriez l'instance d'enregistreur. Dans ce cas, il se peut que les instances de lecteur ne puissent pas accéder à une table récemment créée tant qu'elles n'ont pas toutes été redémarrées.
Pour obtenir la liste de tous les paramètres du SQL cluster Aurora My, consultezParamètres de niveau cluster.
Pour obtenir la liste de tous les paramètres du SQL cluster Aurora Postgre, consultezParamètres de niveau cluster d'Aurora PostgreSQL.
Astuce
Aurora My SQL peut toujours redémarrer certaines instances de lecteur en même temps que l'instance d'écriture si votre cluster traite une charge de travail à haut débit.
La réduction du nombre de redémarrages s'applique également lors des opérations de basculement. Aurora My SQL ne redémarre l'instance de base de données Writer et la cible de basculement que lors d'un basculement. D'autres instances de bases de données de lecteur dans le cluster restent disponibles pour continuer le traitement des requêtes par le biais de connexions au point de terminaison du lecteur. Vous pouvez donc améliorer la disponibilité lors d'un basculement en disposant de plusieurs instances de base de données de lecteur dans un cluster.
