j'ai compris

Agile controller: Fiabilité de la base de données

publié il y a  2021-2-17 15:08:30 117 0 0 0 0

Fiabilité de la base de données

Les données de compte local et les données de configuration de service de l' Agile Controller-Campus sont toutes enregistrées dans la base de données. Par conséquent, la base de données doit utiliser une conception de haute fiabilité pour éviter les pannes de service sur le Campus Agile Controller .

L' Agile Controller-Campus prend en charge les bases de données Microsoft SQL Server et GaussDB, qui fournissent respectivement la mise en miroir de la base de données et le mode actif / veille de la base de données pour garantir la fiabilité de la base de données.

Fiabilité de la base de données SQL Server

La mise en miroir de bases de données nécessite au moins trois serveurs SQL (bases de données principale, miroir et témoin).

  • Base de données principale : une instance de base de données SQL Server en cours d'utilisation, également appelée base de données de base. La base de données principale est responsable du traitement des demandes de lecture d'application et d'écriture de données.

  • Base de données miroir : une instance de base de données SQL Server indépendante de la base de données principale. Le serveur SQL écrit les données dans la base de données principale et la base de données miroir en même temps pour la sauvegarde des données. Les données de la base de données miroir ne sont accessibles que lorsque le service est basculé vers la base de données miroir en cas de défaillance de la base de données principale.

  • Base de données témoin : une autre instance de base de données SQL Server indépendante. La base de données témoin détermine quand la récupération des données est effectuée.

c_plan_0041_fig01.png

La mise en miroir de bases de données conserve deux copies d'une base de données, qui doivent résider sur différentes instances de serveur du moteur de base de données SQL Server. En règle générale, les instances de serveur résident sur des ordinateurs situés à des emplacements différents. Le démarrage de la mise en miroir de bases de données établit une session de mise en miroir de bases de données entre les instances de serveur.

Une instance de serveur agit en tant que serveur principal et sert les clients. L'autre instance de serveur agit comme un serveur de secours ou à chaud (serveur miroir) en fonction de la configuration et de l'état de la session de mise en miroir de la base de données. Lorsque la session de mise en miroir de bases de données est synchronisée, la mise en miroir de bases de données fournit un serveur de secours qui prend en charge le basculement rapide sans perte de données des transactions validées. Lorsque la session de mise en miroir de la base de données n'est pas synchronisée, le serveur miroir agit généralement comme un serveur de secours (avec une perte de données possible).

Les serveurs principal et miroir communiquent et coopèrent en tant que partenaires dans une session de mise en miroir de bases de données. Les deux partenaires remplissent des rôles complémentaires: principal et miroir. À tout moment, un partenaire joue le rôle principal et l'autre joue le rôle de miroir. Le partenaire qui possède le rôle principal est appelé serveur principal et sa copie de la base de données est la base de données principale actuelle. Le partenaire qui possède le rôle miroir est appelé serveur miroir et sa copie de la base de données est la base de données miroir actuelle. Lorsque la mise en miroir de bases de données est déployée dans un environnement de production, la base de données principale est la base de données de production.

La mise en miroir de bases de données doit refaire rapidement toutes les opérations d'insertion, de mise à jour et de suppression qui se produisent sur la base de données principale sur la base de données miroir. La restauration est effectuée en envoyant un flux d'enregistrements de journaux de transactions actifs au serveur miroir, qui applique les enregistrements de journaux à la base de données miroir dans l'ordre, aussi rapidement que possible. Contrairement à la réplication qui fonctionne au niveau logique, la mise en miroir de la base de données fonctionne au niveau de l'enregistrement de journal physique. Depuis SQL Server 2008, le serveur principal compresse le flux des enregistrements du journal des transactions avant de l'envoyer au serveur miroir. Cette compression du journal se produit dans toutes les sessions de mise en miroir. La mise en miroir de la base de données permet le basculement automatique du service vers la base de données miroir en cas de défaillance de la base de données principale.

Dans un environnement de mise en miroir de bases de données, les bases de données peuvent normalement fournir des services uniquement lorsque deux des bases de données principale, miroir et témoin sont dans un état normal. Lors de la planification, il est recommandé que trois bases de données soient déployées sur différents serveurs physiques ou machines virtuelles (VM) pour garantir le fonctionnement normal des services de base de données en cas de défaillance du serveur. S'ils sont déployés sur le même serveur, tous les programmes de base de données sont affectés en cas de défaillance du serveur.

Fiabilité de la base de données GaussDB

La base de données GaussDB offre la capacité de fiabilité en mode actif / veille. La fiabilité de la base de données GaussDB nécessite un nœud maître et un nœud de secours. Les deux nœuds utilisent l'adresse floatIP pour fournir des services en externe. Le composant OMMHA de fiabilité de la base de données surveille les rôles des nœuds actifs et de secours pour implémenter le basculement actif / veille lorsque la communication entre les nœuds actifs et en veille est anormale. Les composants internes SM et SC de l'Agile Controller-Campus utilisent l'adresse floatIP pour accéder à la base de données GaussDB. Le basculement entre les nœuds GaussDB actifs et en veille n'est pas affecté.

L'OMMHA peut basculer automatiquement entre les bases de données GaussDB actives et en veille. La base de données GaussDB et OMMHA peuvent être utilisées ensemble pour fournir la solution de fiabilité GaussDB. Lorsque le nœud actif est défectueux, la base de données GaussDB est rapidement basculée vers le nœud de secours pour le traitement du service.

c_plan_0041_fig02.png

  • La base de données active est le nœud actif dans la relation actif / veille. Il fournit le service d'accès en lecture / écriture pour la base de données et synchronise les données avec la base de données de secours pour mettre en œuvre la sauvegarde des données.

  • La base de données de secours est le nœud de secours dans la relation actif / veille. Il est en lecture seule et n'est pas accessible par des applications externes. (La lecture et l'écriture ne sont pas prises en charge.) Il est utilisé pour recevoir les données de l'hôte et sauvegarder les données sur le nœud actif en temps réel. Lorsqu'une exception se produit sur le nœud actif (inaccessible et ne répond pas aux demandes de service), le nœud GaussDB de secours est commuté sur le nœud actif pour assurer un accès au service normal.

L'OMMHA est un logiciel HA développé par le HUAWEI OS Competence Center et fournit un mécanisme HA universel. Le composant OMMHA est déployé lorsque la base de données GaussDB est déployée. Sur les nœuds GaussDB actifs et en veille, si le nœud actif est défectueux (panne de l'hôte, interruption de la liaison de pulsation, panne de la carte réseau IR, échec de montage de l'adresse floatIP, ou la ressource critique surveillée est anormale.), Le composant OMMHA commute l'adresse floatIP et surveillé les ressources critiques vers le nœud de secours afin que le nœud de secours prenne le relais du système de fiabilité. L'OMMHA surveille le processus GaussDB toutes les 40s et surveille l'adresse floatIP toutes les 10s.


  • x
  • Standard:

Commentaire

Connectez-vous pour répondre. Se connecter | Enregistrer
envoyer

Remarque : Afin de protéger vos droits et intérêts légitimes, ceux de la communauté et des tiers, ne divulguez aucun contenu qui pourrait présenter des risques juridiques pour toutes les parties. Le contenu interdit comprend, sans toutefois s'y limiter, le contenu politiquement sensible, le contenu lié à la pornographie, aux jeux d'argent, à l'abus et au trafic de drogues, le contenu qui peut divulguer ou enfreindre la propriété intellectuelle d'autrui, y compris les secrets professionnels, les marques commerciales, les droits d'auteur et les brevets, ainsi que la vie privée personnelle. Ne partagez pas votre nom d'utilisateur ou votre mot de passe avec d'autres personnes. Toutes les opérations effectuées à partir de votre compte seront considérées comme vos propres actions, et toutes les conséquences en découlant vous seront imputées. Pour plus de détails, voir « Accord utilisateur ».

My Followers

Connectez-vous pour participer à la communication et au partage

S'identifier

Bloquer
Êtes-vous sûr de bloquer cet utilisateur?
Les utilisateurs de votre liste noire ne peuvent ni commenter votre publication,ni vous mentionner, ni vous envoyer de messages privés.
Rappel
Veuillez lier votre numéro de téléphone pour obtenir un bonus d'invitation.