Changement de serveur
En cas d'échec de l'instance principale, l'une des instances secondaires résidant dans un domaine de disponibilité ou de pannes distinct est automatiquement promue en tant qu'instance principale.
Après un basculement, le nom et la position du nouveau fichier journal binaire en cours peuvent être différents de l'ancien fichier principal. Comme les journaux binaires de chaque instance sont gérés indépendamment, chaque transaction enregistrée dans les journaux binaires peut être écrite dans un fichier journal binaire différent et se positionner dans des instances différentes.
Lorsque vous créez un système de base de données, le placement en cours de l'instance principale est identique au placement préféré. Toutefois, en cas de basculement, l'une des instances secondaires est promue en tant qu'instance principale. Le domaine de disponibilité et de pannes de cette nouvelle instance principale est le placement en cours. Le placement préféré de l'instance principale, que vous avez sélectionné lors de la création du système de base de données, reste le même. Dans ce cas, le placement en cours diffère du placement préféré et un message est affiché sur la page Détails du système de base de données :
Current placement (<DomainName>) differs from preferred placement, due to failover or maintenance activity. <DomainName> est le nom du domaine de pannes ou du domaine de disponibilité de l'instance principale en cours.
L'adresse IP de l'adresse de lecture/écriture du système de base de données ne change pas, quel que soit le placement de l'instance principale.
Une fois l'erreur corrigée, l'instance principale d'origine revient au système de base de données en tant qu'instance secondaire. En cas de basculement, l'instance principale d'origine est promue en tant qu'instance principale en cours.
En cas de basculement sur un système de base de données avec un canal de réplication entrante actif, le canal est suspendu jusqu'à la fin du basculement. Une fois le basculement terminé et une nouvelle instance principale promue, le canal reprend automatiquement.
HeatWave Prise en charge des clusters
Pour un système de base de données haute disponibilité avec un cluster HeatWave, lorsque l'instance principale tombe en panne, le service HeatWave détache le cluster HeatWave de l'instance principale en échec. Si la nouvelle instance principale promue se trouve dans le même domaine de disponibilité que l'instance principale en échec, le même cluster HeatWave est réutilisé et il est attaché à la nouvelle instance principale. Si la nouvelle instance principale promue se trouve dans un autre domaine de disponibilité, le cluster HeatWave existant est supprimé. Un cluster HeatWave doit être créé dans le même domaine de disponibilité que la nouvelle instance principale et il est attaché à la nouvelle instance principale. Les données du cluster HeatWave sont automatiquement récupérées à partir de la couche de stockage ou rechargées à partir du système de base de données ou du stockage d'objets Lakehouse.
Evénements de basculement
Lorsqu'un basculement se produit, un événement MySQL - Récupération automatique est émis sur le système de base de données. La propriété additionalDetails.isFailover de l'événement est définie sur true pour indiquer que la récupération automatique est due à un basculement. Reportez-vous à MySQL - Récupération automatique.
Motifs de basculement
Tableau 16-1 Motifs de basculement
| Changement de serveur | Description : |
|---|---|
| Matériel |
|
| MySQL Server |
|