Présentation de la haute disponibilité
Un système de base de données haute disponibilité se compose de trois instances MySQL : une instance principale et deux instances secondaires. Chaque instance MySQL utilise la même quantité de stockage de volume de blocs, le même nombre d'UC et la même quantité de RAM que celle définie dans la forme choisie. L'instance principale fonctionne en tant qu'adresse de lecture/écriture et vous disposez uniquement d'un accès en lecture/écriture à l'instance principale. Toutes les données que vous écrivez dans l'instance principale sont copiées dans les instances secondaires de manière asynchrone. Les journaux binaires de chaque instance MySQL sont gérés indépendamment les uns des autres. Même si les instances ont les mêmes données, elles peuvent avoir un nombre différent de fichiers journaux binaires avec des noms de fichier différents et éventuellement des tailles différentes.
Les instances secondaires sont placées dans des domaines de disponibilité ou de pannes différents. Les modèles de placement d'instance suivants sont utilisés :
- Plusieurs domaines de disponibilité avec un sous-réseau régional : les trois instances MySQL sont placées dans différents domaines de disponibilité.
- Plusieurs domaines de disponibilité avec un sous-réseau propre à un domaine de disponibilité : les trois instances MySQL sont placées dans différents domaines de pannes du même domaine de disponibilité.
- région à domaine de disponibilité unique : les trois instances MySQL sont placées dans différents domaines de pannes du même domaine de disponibilité.
Les systèmes de base de données haute disponibilité utilisent plus de ressources (CPU, RAM, bande passante réseau) que les systèmes de base de données autonomes. Par conséquent, le débit et la latence diffèrent des systèmes de base de données autonomes.
Si vous activez les sauvegardes automatiques, le service HeatWave crée des sauvegardes de l'instance principale du système de base de données haute disponibilité.
La haute disponibilité utilise la réplication de groupe MySQL pour répliquer les données de l'instance principale vers les instances secondaires. La réplication se produit sur un réseau interne sécurisé, géré et non connecté au sous-réseau VCN que vous avez configuré pour le système de base de données. Des informations limitées sur ce réseau interne sont disponibles dans certaines tables de schéma de performance, et vous ne pouvez ni vous y connecter ni consulter d'autres informations s'y rapportant.
Promotion automatique ou manuelle d'une instance secondaire
- Basculement : en cas d'échec de l'instance principale, le service HeatWave automatiquement promeut l'une des instances secondaires pour qu'elle fonctionne en tant qu'instance principale. La disponibilité des applications client est ainsi rétablie sans perte de données.
- Permutation : le service HeatWave vous permet de promouvoir manuellement l'une des instances secondaires en tant qu'instance principale. C'est ce qu'on appelle la permutation.
Après un basculement ou une permutation, le nom de fichier journal binaire en cours et la position du nouveau fichier principal peuvent être différents de l'ancien. 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.
Lors d'un basculement ou d'une permutation dans un système de base de données haute disponibilité avec un cluster HeatWave, vous pouvez exécuter à nouveau des requêtes sur le cluster HeatWave avec un certain délai.
Placement principal préféré et actuel
- Placement principal préféré : lors de la création d'un système de base de données haute disponibilité, vous pouvez choisir le domaine de disponibilité et de pannes dans lequel placer l'instance principale, qui fonctionne en tant qu'adresse de lecture/écriture. Cette opération est appelée emplacement principal préféré et ne change pas une fois que vous avez créé un système de base de données haute disponibilité, sauf lorsque vous effectuez une permutation. Les instances secondaires sont automatiquement placées dans les deux autres domaines de disponibilité ou de pannes.
- Placement principal en cours : 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 emplacement principal en cours. Le placement principal préféré, que vous avez sélectionné lors de la création du système de base de données, reste le même. L'adresse IP de l'adresse de lecture/écriture ne change pas, quel que soit le placement de l'instance principale.
HeatWave Prise en charge des clusters
Vous pouvez activer le cluster HeatWave sur un système de base de données haute disponibilité. Pour activer le cluster HeatWave, mettez d'abord à jour la forme du système de base de données vers une forme qui prend en charge le cluster HeatWave. Reportez-vous à Formes prises en charge. Lorsque le cluster HeatWave est actif, il est toujours attaché à l'instance principale du système de base de données haute disponibilité. Lorsque le placement en cours de l'instance principale change dans un basculement ou une permutation, le cluster HeatWave doit être détaché de l'instance principale précédente et un cluster HeatWare identique ou nouveau doit être 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.
Si l'instance principale précédente et la nouvelle instance principale se trouvent dans le même domaine de disponibilité, le cluster HeatWave existant peut être réutilisé. Le cluster HeatWave est détaché de l'instance principale précédente et rattaché à la nouvelle instance principale. Cela se produit lorsque le système de base de données se trouve dans une région à un seul domaine de disponibilité ou est connecté à un sous-réseau propre à un domaine de disponibilité dans une région à plusieurs domaines de disponibilité.
Si l'instance principale précédente et la nouvelle instance principale se trouvent dans un domaine de disponibilité différent, le cluster HeatWave existant doit être détaché et 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. Cela se produit lorsque le système de base de données est connecté à un sous-réseau régional dans une région à plusieurs domaines de disponibilité.
Rubriques connexes