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’enregistreur de votre cluster Aurora sans redémarrer les instances de lecteur dans le cluster de bases 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 de lecteur une par une, en commençant uniquement une fois le redémarrage de l’instance principale 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 bases de données principaux est disponible dans Aurora MySQL 2.10 et versions ultérieures. La disponibilité en lecture pour les clusters de bases de données secondaires est disponible dans Aurora MySQL 3.06 et versions ultérieures.
Pour Aurora PostgreSQL, cette fonctionnalité est disponible par défaut dans les versions suivantes :
15.2 et versions 15 ultérieures
Versions 14.7 et 14 ultérieures
Versions 13.10 et 13 ultérieures
12.14 et versions 12 ultérieures
Pour plus d’informations sur la fonctionnalité de disponibilité en lecture dans Aurora PostgreSQL, consultez Amélioration de la disponibilité en lecture des réplicas Aurora.
Avant cette fonctionnalité, le redémarrage de l’instance principale entraînait un redémarrage de chaque instance de lecteur au même moment. 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 le cluster de bases de données Aurora avec disponibilité en lecture est différente pour les bases de données globales Aurora dans les versions d’Aurora MySQL anté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 Aurora PostgreSQL 12.16, 13.12, 14.9, 15.4 et versions ultérieures.
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 cluster Aurora MySQL, vous pouvez mettre à jour des paramètres de cluster tels que binlog_format et innodb_purge_threads sur l’instance d’enregistreur avant les instances de 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 instructions SQL ou la sortie de requête, vous devrez peut-être redémarrer immédiatement les instances de 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 cluster Aurora MySQL, consultez Paramètres de niveau cluster.
Pour obtenir la liste de tous les paramètres de cluster Aurora PostgreSQL, consultez Paramètres de niveau cluster d’Aurora PostgreSQL.
Astuce
Aurora MySQL peut encore redémarrer certaines instances de lecteur avec l’instance d’enregistreur si votre cluster traite une application à haut débit.
La réduction du nombre de redémarrages s’applique également lors des opérations de basculement. Lors d’un basculement, Aurora MySQL redémarre uniquement l’instance de base de données du scripteur et la cible de basculement. D’autres instances de base 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.
