Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à :
Azure SQL DatabaseBase de données SQL dans Fabric
Cet article décrit l’architecture d'Azure SQL Database et des bases de données SQL dans Fabric qui assure la disponibilité par le biais de la redondance locale et de la haute disponibilité par le biais de la redondance de zone.
Overview
Azure SQL Database et la base de données SQL dans Fabric fonctionnent tous deux sur la dernière version stable du moteur de base de données SQL Server sur le système d'exploitation Windows avec tous les correctifs applicables. SQL Database gère automatiquement les tâches de maintenance critiques, comme les mises à jour correctives, les sauvegardes, les mises à niveau de Windows et du moteur SQL, ainsi que les événements non planifiés, comme les défaillances sous-jacentes de type matériel, logiciel ou réseau. Quand une base de données ou un pool élastique dans SQL Database est corrigé ou bascule, le temps d’arrêt n’a aucun impact si vous utilisez une logique de nouvelle tentative dans votre application. Pour assurer la disponibilité de vos données, SQL Database bénéficie de fonctionnalités de récupération rapide, même dans les situations les plus critiques. La plupart des utilisateurs ne remarquent pas que les mises à niveau sont effectuées en continu.
Par défaut, Azure SQL Database obtient la disponibilité par le biais de la redondance locale, en vous assurant que votre base de données gère les interruptions telles que :
- Opérations de gestion initiées par le client qui entraînent un bref temps d’arrêt
- Opérations de maintenance de service
- Problèmes liés :
- au rack où les machines qui alimentent votre service sont en cours d’exécution
- à la machine physique qui héberge le moteur de base de données SQL
- au moteur de base de données SQL et autres
- Autres pannes locales non planifiées potentielles
La solution de disponibilité par défaut est conçue pour s’assurer que les données validées ne sont jamais perdues en raison d’échecs, que les opérations de maintenance ont un impact minimal sur votre charge de travail et que la base de données n’est pas un point de défaillance unique dans votre architecture logicielle.
Toutefois, pour réduire l’impact sur vos données en cas de panne dans une zone entière, vous pouvez obtenir une haute disponibilité en activant la redondance de zone. Sans redondance de zone, les basculements se produisent localement au sein du même centre de données, ce qui peut entraîner l'indisponibilité de votre base de données jusqu'à ce que la panne soit résolue. Le seul moyen de récupérer est de recourir à une solution de récupération d'urgence, telle qu'un basculement géographique par le biais d'une géoréplication active, de groupes de basculement ou d'une géo-restauration d'une sauvegarde géo-redondante. Pour plus d’informations, consultez la vue d'ensemble de la continuité d'activité.
Trois modèles d'architecture à haute disponibilité sont disponibles :
- Modèle de stockage étendu basé sur la séparation du calcul et du stockage. Le modèle de stockage distant s’appuie sur la disponibilité et la fiabilité du niveau de stockage distant. Cette architecture cible des applications métier économiques, capables de tolérer une baisse de performances pendant les activités de maintenance.
- Modèle de stockage local basé sur un cluster de processus de moteur de base de données. Le modèle de stockage local s’appuie sur le fait qu’il existe toujours un quorum de nœuds de moteur de base de données disponibles. Cette architecture s’adresse à des applications stratégiques ayant des performances d’E/S supérieures et un taux de transactions élevé. Elle garantit un impact minimal sur les performances de votre charge de travail pendant les activités de maintenance.
- Modèle Hyperscale qui utilise un système distribué de composants hautement disponibles comme les nœuds de calcul, les serveurs de pages, le service de journaux et le stockage persistant. Chaque composant prenant en charge une base de données Hyperscale fournit sa redondance et sa résilience propres en cas de défaillances. Les nœuds de calcul, les serveurs de page et le service de journal s’exécutent sur Azure Service Fabric, qui contrôle l’intégrité de chaque composant et effectue les basculements vers des nœuds sains disponibles quand cela est nécessaire. Le stockage persistant utilise Stockage Azure avec ses fonctionnalités natives de haute disponibilité et de redondance. Pour plus d’informations, consultez Architecture Hyperscale.
Dans chacun des trois modèles de disponibilité, SQL Database prend en charge les options de redondance locale et de redondance interzone. La redondance locale assure la résilience au sein d’un centre de données, tandis que la redondance zonale améliore davantage la résilience en protégeant contre les pannes d’une zone de disponibilité au sein d’une région.
Le tableau suivant présente les options de disponibilité en fonction des niveaux de service :
| Niveau de service | Modèle haute disponibilité | Disponibilité localement redondante | Disponibilité redondante interzone |
|---|---|---|---|
| Usage général (vCore) | Stockage distant | Yes | Yes |
| Critique pour l’entreprise (vCore) | Stockage local | Yes | Yes |
| Hyperscale (vCore) | Hyperscale | Yes | Yes |
| De base (DTU) | Stockage distant | Yes | No |
| Norme (DTU) | Stockage distant | Yes | No |
| Premium (DTU) | Stockage local | Yes | Yes |
Pour plus d’informations sur les contrats SLA spécifiques des différents niveaux de service, passez en revue le Contrat de niveau de service (SLA) pour la base de données Azure SQL.
la disponibilité par le biais de la redondance locale
La disponibilité redondante localement est basée sur le stockage de votre base de données et des données sur un stockage localement redondant (LRS) qui copie vos données trois fois dans un centre de données unique de la région primaire et protège vos données en cas de défaillance locale, comme une panne de l'alimentation ou du réseau à petite échelle. Le stockage redondant localement est la solution de redondance la moins coûteuse, mais offrant la durabilité la plus faible par rapport aux autres options. S un sinistre à grande échelle tel qu’un incendie ou une inondation se produit dans une région tous les réplicas d’un compte de stockage utilisant un stockage localement redondant risquent d’être perdus ou irrécupérables. Par conséquent, envisagez une option de stockage plus résiliente pour vos sauvegardes de base de données afin de mieux protéger vos données si vous utilisez l'option de disponibilité localement redondante. Cela ne s’applique pas aux bases de données Hyperscale qui utilisent le même stockage pour les fichiers de données et les sauvegardes.
La disponibilité localement redondante est accessible à toutes les bases de données dans tous les niveaux de service, tandis que l’objectif de point de récupération (RPO) indiquant la quantité de perte de données est égal à zéro.
Niveaux de service De base, Standard et Usage général
Les niveaux de service De base et Standard de la vue d’ensemble du modèle d’achat DTU et le niveau de service Usage général du modèle d’achat vCore utilisent le modèle de disponibilité de stockage distant pour le calcul serverless et provisionné. Le diagramme suivant montre les nœuds avec les couches de calcul et de stockage séparées.
Le modèle de disponibilité du stockage étendu comprend deux couches :
Une couche de calcul sans état, qui exécute le processus du moteur de base de données et contient uniquement des données transitoires et mises en cache comme les bases de données
tempdbetmodelsur le SSD attaché, ainsi que le cache du plan, le pool de mémoires tampons et le pool columnstore en mémoire. Ce nœud sans état est géré par Azure Service Fabric qui initialise le moteur de base de données, contrôle l’intégrité du nœud et effectue le basculement vers un autre nœud si nécessaire.Une couche de données avec état, comprenant les fichiers de base de données (
.mdfet.ldf) stockés dans le service Stockage Blob Azure. Les fonctionnalités de disponibilité et de redondance des données sont intégrées au Stockage Blob Azure. Celle-ci garantit la conservation de chaque enregistrement du fichier journal ou de chaque page du fichier de données, même si le moteur de base de données se bloque.
Chaque fois que le moteur de base de données ou le système d’exploitation est mis à niveau ou qu’un échec est détecté, Azure Service Fabric déplace le processus du moteur de base de données sans état vers un autre nœud de calcul sans état avec une capacité suffisante. Les données conservées dans le Stockage Blob Azure ne sont pas affectées par le déplacement. Les fichiers de données et de journaux sont joints au moteur de base de données qui vient d’être initialisé. Ce processus garantit une haute disponibilité de 99,99 %, mais une charge de travail lourde peut accuser une baisse de performances pendant la transition, car le nouveau processus de moteur de base de données démarre avec le cache à froid.
Niveaux de service Premium et Critique pour l’entreprise
Le niveau de service Premium du modèle d’achat DTU et le niveau de service critique pour l'entreprise du modèle d'achat vCore utilisent le modèle de disponibilité du stockage local, qui intègre les ressources de calcul (processus du moteur de base de données) et de stockage (SSD attaché localement) sur un seul nœud. La haute disponibilité est obtenue en répliquant le calcul et le stockage sur des nœuds supplémentaires.
Les fichiers de base de données sous-jacents (.mdf/.ldf) sont placés sur le stockage SSD attaché, afin de fournir une latence des E/S très faible à votre charge de travail. La haute disponibilité est implémentée au moyen d'une technologie semblable à celles des groupes de disponibilité AlwaysOn de SQL Server. Le cluster comprend un seul réplica principal qui est accessible pour les charges de travail en lecture-écriture des clients, et un maximum de trois réplicas secondaires (de calcul et de stockage) contenant les copies des données. Le réplica principal envoie constamment des modifications aux réplicas secondaires dans l’ordre et garantit que les données sont conservées sur un nombre suffisant de réplicas secondaires avant de valider chaque transaction. Ce processus garantit qu’en cas de blocage du réplica principal ou d’un réplica secondaire accessible en lecture pour une raison quelconque, un réplica entièrement synchronisé est toujours disponible en vue du basculement. Le basculement est initié par Azure Service Fabric. Quand un réplica secondaire devient le nouveau réplica principal, un autre réplica secondaire est créé afin de s’assurer que le cluster dispose d’un nombre suffisant de réplicas pour maintenir le quorum. Une fois le basculement terminé, les connexions Azure SQL sont redirigées automatiquement vers le nouveau réplica principal ou vers le réplica secondaire accessible en lecture.
Le modèle de disponibilité de stockage local offre un avantage supplémentaire : il permet de rediriger les connexions Azure SQL en lecture seule vers l’un des réplicas secondaires. Cette fonctionnalité est appelée Scale-out en lecture. Elle fournit 100 % de capacité de calcul, sans frais supplémentaires, pour décharger depuis le réplica principal des opérations en lecture seule, telles que les charges de travail analytiques.
Niveau de service Hyperscale
L’architecture de niveau de service Hyperscale est décrite dans l’architecture des fonctions distribuées, qui a un diagramme détaillé.
Le modèle de disponibilité dans Hyperscale comprend quatre couches :
Une couche de calcul sans état, qui exécute les processus de moteur de base de données et contient uniquement des données transitoires et mises en cache, comme le cache RBPEX non couvrant, des base de données
tempdbetmodeletc. sur le SSD attaché, ainsi que le cache du plan, le pool de mémoires tampons et le pool columnstore en mémoire. Cette couche sans état comprend le réplica de calcul principal et, éventuellement, un certain nombre de réplicas de calcul secondaires qui peuvent servir de cibles de basculement.Une couche de stockage sans état formée de serveurs de pages. Cette couche est le moteur de stockage distribué des processus de moteur de base de données s’exécutant sur les réplicas de calcul. Chaque serveur de pages contient uniquement des données temporaires et mises en cache, comme le cache RBPEX couvrant sur le disque SSD attaché ainsi que les pages de données mise en cache dans la mémoire. Chaque serveur de pages dispose d’un serveur de pages appairé dans une configuration active-active pour assurer l’équilibrage de charge, la redondance et la haute disponibilité.
Une couche de stockage du journal des transactions avec état formée du nœud de calcul exécutant le processus du service de journal, la zone d’atterrissage du journal des transactions et le stockage durable du journal des transactions. La zone d’atterrissage et le stockage durable utilisent Stockage Azure, qui assure la disponibilité et la redondance du journal des transactions, ce qui garantit la durabilité des données pour les transactions validées.
Une couche de stockage de données avec état avec les fichiers de base de données (.mdf/.ndf) qui sont stockés dans Stockage Azure et mis à jour par les serveurs de pages. Cette couche utilise les fonctionnalités de disponibilité et de redondance des données de Stockage Azure. Cela garantit que chaque page d’un fichier de données est conservée, même si les processus des autres couches de l’architecture Hyperscale se bloquent ou si des nœuds de calcul subissent une défaillance.
Dans toutes les couches Hyperscale, les nœuds de calcul s’exécutent sur Azure Service Fabric, qui contrôle la santé de chaque nœud et assure les basculements vers des nœuds sains disponibles quand cela est nécessaire.
Pour plus d’informations sur la haute disponibilité dans Hyperscale, consultez Haute disponibilité de la base de données dans Hyperscale .
la haute disponibilité via la redondance de zone
Pour les déploiements redondants interzones, Azure SQL Database utilise le nombre de zones de disponibilité Azure dans une région donnée, au moins trois. Les composants de calcul et de stockage s’étendent sur deux ou trois zones, comme sélectionnés par Azure SQL pour une résilience optimale, dans des emplacements physiques distincts avec une puissance indépendante, un refroidissement et une mise en réseau. Azure SQL sélectionne automatiquement le nombre de zones en fonction de la disponibilité régionale et de l’optimisation du service. Votre déploiement n’utilise pas moins de zones que nécessaire pour la résilience.
La disponibilité de la redondance de zone est disponible pour les bases de données des niveaux de service critique pour l'entreprise, usage général et Hyperscale du modèle d'achat vCore, et uniquement pour le niveau de service Premium du modèle d’achat DTU - les niveaux de service De Base et Standard ne prennent pas en charge la redondance de zone.
Bien que chaque niveau de service implémente la redondance de zone différemment, toutes les implémentations garantissent un objectif de point de récupération (RPO) sans perte de données validées lors du basculement si une seule zone de disponibilité au sein d’une région Azure devient indisponible.
Azure SQL optimise automatiquement l’emplacement des zones pour votre déploiement. Toutes les configurations de zone de disponibilité, à l’aide de deux ou trois zones, fournissent les mêmes garanties de niveau de service et de résilience à haute disponibilité.
Niveau de service Usage général
La configuration redondante interzone pour le niveau de service Usage général est proposée à la fois pour le calcul serverless et le calcul provisionné des bases de données dans le modèle d’achat vCore. Cette configuration utilise des Zones de disponibilité Azure pour répliquer les bases de données sur plusieurs emplacements physiques au sein d’une région Azure. En sélectionnant la redondance interzone, vous pouvez rendre vos bases de données uniques serverless et provisionnées à usage général, et vos pools élastiques nouveaux et existants résilients à un plus grand éventail d’échecs, notamment les pannes graves de centre de données, sans aucune modification de la logique d’application.
La configuration redondante interzone pour le niveau Usage général contient deux couches :
- Couche de données avec état avec les fichiers de base de données (.mdf/.ldf) stockés dans ZRS (stockage redondant interzone). À l’aide de ZRS, les fichiers de données et de journaux sont copiés de manière synchrone sur plusieurs zones de disponibilité Azure dans la région primaire. Il s’agit de deux ou trois zones, comme sélectionné par Azure SQL pour une résilience optimale.
- Une couche de calcul sans état, qui exécute le processus sqlservr.exe et contient uniquement des données transitoires et mises en cache comme les bases de données
tempdbetmodelsur le SSD attaché, ainsi que le cache du plan, le pool de mémoires tampons et le pool columnstore en mémoire. Ce nœud sans état est géré par Azure Service Fabric qui initialise sqlservr.exe, contrôle l’intégrité du nœud et effectue le basculement vers un autre nœud si nécessaire. Pour les bases de données redondantes interzones à usage général sans serveur et approvisionnées, les nœuds avec une capacité de rechange sont facilement disponibles dans d’autres zones de disponibilité pour le basculement.
La version redondante interzone de l’architecture de haute disponibilité pour le niveau de service Usage général est illustrée par les diagrammes suivants, dans une région à deux zones ou à trois zones :
| Région à deux zones | Région à trois zones |
|---|---|
|
|
Lorsque le calcul est provisionné sur deux zones de disponibilité :
- La sauvegarde et le stockage sont toujours synchronisés entre trois zones de disponibilité dans la région.
- Le stockage redondant interzone, comme toujours, est synchronisé entre trois zones de disponibilité.
Lorsque le calcul est provisionné sur trois zones de disponibilité :
- La sauvegarde et le stockage sont synchronisés entre trois zones de disponibilité dans la région.
Toutes les régions Azure qui prennent en charge les zones de disponibilité prennent en charge les bases de données générales redondantes par zone.
Pour la disponibilité redondante interzone, le choix d’une fenêtre de maintenance autre que la valeur par défaut est actuellement disponible dans certaines régions. Pour plus d’informations, consultez La disponibilité des fenêtres de maintenance par région pour Azure SQL Database.
La redondance interzone n’est pas disponible pour les niveaux de service De base ni Standard dans le modèle d’achat DTU.
Niveaux de service Premium et Critique pour l’entreprise
Lorsque la redondance de zone est activée pour le niveau de service Premium ou Critique pour l’entreprise, les réplicas sont placés dans différentes zones de disponibilité dans la même région. Pour éliminer un point de défaillance unique, l’anneau de contrôle est également dupliqué sur plusieurs fuseaux horaires sous forme de trois anneaux de passerelle (GW). Le routage vers un anneau de passerelle spécifique est contrôlé par Azure Traffic Manager. Étant donné que la configuration redondante interzone dans les niveaux de service Premium ou Critique pour l’entreprise utilise ses réplicas existants pour les placer dans différentes zones de disponibilité, vous pouvez l’activer sans coûts supplémentaires. En sélectionnant une configuration redondante interzone, vous rendez vos pools élastiques et vos bases de données Premium ou Critique pour l’entreprise résistants à un plus grand éventail d’échecs, notamment les pannes graves de centre de données, sans aucune modification à la logique d’application. Vous pouvez également convertir vos pools élastiques ou vos bases de données Premium ou Critique pour l’entreprise en configuration redondant interzone.
La version redondante interzone de l’architecture de haute disponibilité pour le niveau de service Critique pour l’entreprise est illustrée par les diagrammes suivants, dans une région à deux zones ou à trois zones :
| Région à deux zones | Région à trois zones |
|---|---|
|
|
Lorsque le calcul est provisionné sur deux zones de disponibilité :
- Pour le stockage critique pour l’entreprise, le stockage de disponibilité localement redondant pour les fichiers de données et les fichiers journaux est synchronisé entre deux zones de disponibilité.
- Pour les autres niveaux, la sauvegarde et le stockage sont synchronisés entre trois zones de disponibilité dans la région.
- Le stockage redondant interzone, comme toujours, est synchronisé entre trois zones de disponibilité.
Lorsque le calcul est provisionné sur trois zones de disponibilité :
- Pour le stockage critique pour l’entreprise, le stockage de disponibilité localement redondant pour les données et les fichiers journaux est synchronisé entre trois zones de disponibilité.
- Pour les autres niveaux, la sauvegarde et le stockage sont synchronisés entre trois zones de disponibilité dans la région.
Tenez compte des éléments suivants lors de la configuration de vos bases de données Premium ou Critique pour l’entreprise avec redondance interzone :
- Toutes les régions Azure prenant en charge les zones de disponibilité prennent en charge les bases de données Premium et Critique pour l’entreprise redondantes interzone.
- Pour la disponibilité redondante interzone, le choix d’une fenêtre de maintenance autre que la valeur par défaut est actuellement disponible dans certaines régions. Pour plus d’informations, consultez La disponibilité des fenêtres de maintenance par région pour Azure SQL Database.
Niveau de service Hyperscale
Il est possible de configurer la redondance interzone pour les bases de données du niveau de service Hyperscale. Pour en savoir plus, consultez Créer une base de données Hyperscale redondante interzone.
L’activation de cette configuration garantit la résilience au niveau des zones via la réplication dans des zones de disponibilité pour toutes les couches Hyperscale. En sélectionnant la redondance de zone, vous pouvez rendre vos bases de données Hyperscale résilientes à un ensemble de défaillances beaucoup plus important, notamment les pannes graves du centre de données, sans aucune modification de la logique d’application.
La disponibilité redondante interzone est prise en charge dans les bases de données autonomes Hyperscale et les pools élastiques Hyperscale. Pour plus d’informations, consultez la vue d’ensemble des pools élastiques Hyperscale dans Azure SQL Database.
Les diagrammes suivants illustrent l’architecture sous-jacente pour les bases de données Hyperscale redondantes interzone, dans une région à deux zones ou à trois zones :
| Région à deux zones | Région à trois zones |
|---|---|
|
|
Lorsque le calcul est provisionné sur deux zones de disponibilité :
- La sauvegarde et le stockage sont synchronisés entre trois zones de disponibilité dans la région.
- Le stockage redondant interzone, comme toujours, est synchronisé entre trois zones de disponibilité.
Lorsque le calcul est provisionné sur trois zones de disponibilité :
- La sauvegarde et le stockage sont synchronisés entre trois zones de disponibilité dans la région.
Tenez compte des limitations suivantes :
Toutes les régions Azure prenant en charge les zones de disponibilité prennent en charge la base de données Hyperscale redondante interzone.
- Pour le matériel de série Premium Hyperscale et le matériel de série Premium optimisé en mémoire, la redondance de zone est disponible dans certaines régions. Pour plus d’informations, consultez la disponibilité de la série Premium Hyperscale par région pour Azure SQL Database.
La configuration redondante interzone peut être spécifiée uniquement lors de la création de la base de données. Ce paramètre n’est pas modifiable après le provisionnement de la ressource. Utilisez la copie de base de données, la restauration à un instant dans le passé ou créez un géo-réplica pour mettre à jour la configuration redondante interzone pour une base de données Hyperscale existante. Quand vous utilisez l’une de ces options de mise à jour, si la base de données cible se trouve dans une autre région que la source ou si la redondance du stockage de la sauvegarde de la base de données de la cible diffère de celle de la base de données source, l’opération de copie est une opération à l’échelle des données.
Pour la disponibilité redondante interzone, le choix d’une fenêtre de maintenance autre que la valeur par défaut est actuellement disponible dans certaines régions. Pour plus d’informations, consultez La disponibilité des fenêtres de maintenance par région pour Azure SQL Database.
Il n’existe actuellement aucune option permettant de spécifier la redondance de zone lors de la migration d’une base de données vers Hyperscale à l’aide du Portail Azure. Cependant, la redondance de zone peut être spécifiée avec Azure PowerShell, Azure CLI ou l’API REST lors de la migration d’une base de données existante d’un autre niveau de service de base de données Azure SQL vers Hyperscale. Voici un exemple avec Azure CLI :
az sql db update --resource-group "myRG" --server "myServer" --name "myDB" --edition Hyperscale --zone-redundant true`Au moins un réplica de calcul à haute disponibilité et l’utilisation du stockage de sauvegarde redondant interzone ou géoredondant interzone est nécessaire pour activer la configuration redondante interzone pour Hyperscale.
Disponibilité de la redondance interzone de base de données
Dans Azure SQL Database, un serveur est une construction logique qui joue le rôle d’un point d’administration central pour une collection de bases de données. Au niveau du serveur, vous pouvez administrer des connexions, une méthode d'authentification, des règles de pare-feu, des règles d’audit, des stratégies de détection des menaces et des groupes de basculement. Les données liées à certaines de ces fonctionnalités, telles que les ID de connexion et les règles de pare-feu, sont stockées dans la base de données master. Les données de certains DMV, par exemple sys.resource_stats, sont également stockées dans la base de données master.
Quand une base de données avec une configuration redondante interzone est créée sur un serveur logique, la base de données master associée au serveur devient automatiquement redondante interzone. Cela garantit qu’en cas de panne zonale, les applications utilisant la base de données restent inchangées, car les fonctionnalités dépendant de la base de données master, telles que les ID de connexion et les règles de pare-feu, sont toujours disponibles. Rendre la base de données master redondante interzone est un processus asynchrone qui prendra un certain temps à se terminer en arrière-plan.
Quand aucune des bases de données sur un serveur n’est redondante interzone, ou quand vous créez un serveur vide, la base de données master associée au serveur n’est pas redondante interzone. Pour migrer votre base de données Azure SQL pour utiliser la redondance de zone, suivez les étapes de migration d’Azure SQL Database vers la prise en charge de la zone de disponibilité.
Pour vérifier la ZoneRedundant propriété de la master base de données, utilisez Azure PowerShell ou Azure CLI ou les étapes de l’API REST dans Valider l’état de la zone de disponibilité Azure SQL Database.
Test de résilience aux erreurs de l’application
La haute disponibilité est un élément fondamental de la plateforme SQL Database qui fonctionne de manière transparente pour votre application de base de données. Toutefois, nous avons conscience que vous souhaitez peut-être tester, avant le déploiement en production, la manière dont les opérations de basculement automatique initiées pendant les événements, planifiés ou non, impacteraient une application. Vous pouvez déclencher manuellement un basculement en appelant une API spéciale pour redémarrer une base de données ou un pool élastique. Dans le cas d’une base de données ou d’un pool élastique redondant interzone serverless et provisionnés, l’appel d’API entraînerait la redirection des connexions clientes vers le nouveau réplica principal dans une zone de disponibilité différente de l’ancien. Ainsi, en plus de tester l’impact du basculement sur les sessions de base de données existantes, vous pouvez aussi vérifier s’il a un impact sur les performances de bout en bout en raison des changements de latence réseau. Sachant que l’opération de redémarrage est intrusive et qu’un grand nombre de redémarrages pourrait peser sur la plateforme, un seul appel de basculement est autorisé toutes les 15 minutes pour chaque base de données ou pool élastique.
Pour plus d’informations sur la haute disponibilité et la récupération d’urgence d’Azure SQL Database, consultez la liste de contrôle de haute disponibilité et de récupération d’urgence - Azure SQL Database.
Un basculement peut être initié à l’aide de PowerShell, de l’API REST ou d’Azure CLI :
| Type de déploiement | PowerShell | REST API | Azure CLI | Portail (préversion) |
|---|---|---|---|---|
| Database | Invoke-AzSqlDatabaseFailover | Basculement de base de données | az rest peut permettre d’invoquer un appel d’API REST à partir d’Azure CLI | Paramètres > Maintenance > Redémarrage |
| Pool élastique | Invoke-AzSqlElasticPoolFailover | Basculement de pool élastique | az rest peut permettre d’invoquer un appel d’API REST à partir d’Azure CLI | Paramètres > Maintenance > Redémarrage |
Important
La commande de basculement n’est pas disponible pour les réplicas secondaires lisibles des bases de données Hyperscale.
Conclusion
Azure SQL Database offre une solution de haute disponibilité intégrée en profondeur à la plateforme Azure. Cette solution dépend de Service Fabric pour la détection et la récupération des défaillances, mais aussi du stockage Blob Azure pour la protection des données et des zones de disponibilité pour une meilleure tolérance de panne. Par ailleurs, SQL Database utilise la technologie de groupe de disponibilité Always On de SQL Server pour la synchronisation de données et le basculement. La combinaison de ces technologies permet aux applications de bénéficier pleinement des avantages d’un modèle de stockage mixte et prend en charge les contrats de niveau de service les plus exigeants.