Utiliser les groupes de basculement automatique pour permettre le basculement transparent et coordonné de plusieurs bases de donnéesUse auto-failover groups to enable transparent and coordinated failover of multiple databases

S’APPLIQUE À : Azure SQL Database Azure SQL Managed Instance

Les groupes de basculement automatique vous permettent de gérer la réplication et le basculement d’un groupe de bases de données sur un serveur, ou de toutes les bases de données d’une instance gérée vers une autre région.The auto-failover groups feature allows you to manage the replication and failover of a group of databases on a server or all databases in a managed instance to another region. Il s’agit d’une abstraction déclarative sur la fonctionnalité de géoréplication active existante, conçue pour simplifier le déploiement et la gestion des bases de données géorépliquées à l’échelle.It is a declarative abstraction on top of the existing active geo-replication feature, designed to simplify deployment and management of geo-replicated databases at scale. Vous pouvez déclencher le basculement manuellement, ou le déléguer au service Azure via une stratégie définie par l’utilisateur.You can initiate failover manually or you can delegate it to the Azure service based on a user-defined policy. Cette dernière option vous permet de récupérer automatiquement plusieurs bases de données associées dans une région secondaire, après une défaillance grave ou tout autre événement non planifié entraînant une perte totale ou partielle de la disponibilité de l’instance SQL Database ou SQL Managed Instance dans la région primaire.The latter option allows you to automatically recover multiple related databases in a secondary region after a catastrophic failure or other unplanned event that results in full or partial loss of the SQL Database or SQL Managed Instance availability in the primary region. Un groupe de basculement peut inclure une ou plusieurs bases de données, généralement utilisées par la même application.A failover group can include one or multiple databases, typically used by the same application. En outre, vous pouvez utiliser les bases de données secondaires accessibles en lecture pour décharger les charges de travail de requêtes en lecture seule.Additionally, you can use the readable secondary databases to offload read-only query workloads. Comme les groupes de basculement automatique impliquent de nombreuses bases de données, celles-ci doivent être configurées sur le serveur primaire.Because auto-failover groups involve multiple databases, these databases must be configured on the primary server. Les groupes de basculement automatique prennent en charge la réplication de toutes les bases de données du groupe vers une seule instance ou un seul serveur secondaire situé dans une autre région.Auto-failover groups support replication of all databases in the group to only one secondary server or instance in a different region.

Notes

Si vous souhaitez disposer de plusieurs instances Azure SQL Database secondaires dans la même région ou dans des régions différentes, utilisez la géo-réplication active.If you want multiple Azure SQL Database secondaries in the same or different regions, use active geo-replication.

Lorsque vous utilisez des groupes de basculement automatique avec une stratégie de basculement automatique, toute panne qui affecte une ou plusieurs des bases de données du groupe donne lieu à un basculement automatique.When you are using auto-failover groups with automatic failover policy, any outage that impacts one or several of the databases in the group results in automatic failover. En général, il s’agit d’incidents qui ne peuvent pas être corrigés automatiquement par les opérations de haute disponibilité automatiques intégrées.Typically these are incidents that cannot be self-mitigated by the built-in automatic high availability operations. Les déclencheurs de basculement peuvent être, par exemple, un incident provoqué par un anneau de locataire SQL Database ou un anneau de contrôle ayant cessé de fonctionner en raison d’une fuite de mémoire du noyau du système d’exploitation sur plusieurs nœuds de calcul, ou encore un incident causé par un ou plusieurs anneaux de locataire en panne, car un câble réseau incorrect a été coupé au cours d’une désactivation de routine du matériel.The examples of failover triggers include an incident caused by a SQL Database tenant ring or control ring being down due to an OS kernel memory leak on several compute nodes, or an incident caused by one or more tenant rings being down because a wrong network cable was cut during routine hardware decommissioning. Pour plus d’informations, consultez Haute disponibilité de SQL Database.For more information, see SQL Database High Availability.

En outre, les groupes de basculement automatique fournissent des points de terminaison d’écouteur de lecture-écriture et de lecture seule qui restent inchangés pendant les basculements.In addition, auto-failover groups provide read-write and read-only listener end-points that remain unchanged during failovers. Que vous utilisiez l’activation manuelle ou automatique du basculement, ce dernier bascule toutes les bases de données secondaires du groupe en bases de données primaires.Whether you use manual or automatic failover activation, failover switches all secondary databases in the group to primary. Une fois le basculement des bases de données terminé, l’enregistrement DNS est automatiquement mis à jour pour rediriger les points de terminaison vers la nouvelle région.After the database failover is completed, the DNS record is automatically updated to redirect the endpoints to the new region. Pour en savoir plus sur les données d’objectif de point et de délai de récupération, voir Vue d’ensemble de la continuité des activités.For the specific RPO and RTO data, see Overview of Business Continuity.

Lorsque vous utilisez des groupes de basculement automatique avec une stratégie de basculement automatique, toute panne qui affecte les bases de données sur un serveur ou une instance gérée donne lieu à un basculement automatique.When you are using auto-failover groups with automatic failover policy, any outage that impacts databases on a server or managed instance results in automatic failover. Vous pouvez gérer le groupe de basculement automatique à l’aide des méthodes suivantes :You can manage auto-failover group using:

Après le basculement, assurez-vous que les exigences d’authentification de votre serveur et de votre base de données ou de votre instance sont configurées sur la nouvelle base de données primaire.After failover, ensure the authentication requirements for your database and server, or instance are configured on the new primary. Pour plus d’informations, consultez Gestion de la sécurité de la base de données SQL Azure après la récupération d’urgence.For details, see SQL Database security after disaster recovery.

Pour assurer vraiment la continuité des activités, l’ajout d’une redondance de base de données entre les centres de données n’est qu’une partie de la solution.To achieve real business continuity, adding database redundancy between datacenters is only part of the solution. La récupération d’une application (service) de bout en bout après une défaillance catastrophique implique la récupération de tous les composants constituant le service et tous les services dépendants.Recovering an application (service) end-to-end after a catastrophic failure requires recovery of all components that constitute the service and any dependent services. En voici quelques exemples : logiciel client (il peut s’agir par exemple d’un navigateur avec un code JavaScript personnalisé), serveurs web frontaux, ressources de stockage et DNS.Examples of these components include the client software (for example, a browser with a custom JavaScript), web front ends, storage, and DNS. Il est essentiel que tous les composants résistent aux mêmes défaillances et redeviennent disponibles dans l’objectif de délai de récupération (RTO) de votre application.It is critical that all components are resilient to the same failures and become available within the recovery time objective (RTO) of your application. Par conséquent, vous devez identifier tous les services dépendants et comprendre les garanties et les fonctionnalités qu’ils fournissent.Therefore, you need to identify all dependent services and understand the guarantees and capabilities they provide. Ensuite, vous devez prendre les mesures appropriées pour vous assurer que votre service fonctionne pendant le basculement des services dont il dépend.Then, you must take adequate steps to ensure that your service functions during the failover of the services on which it depends. Pour plus d’informations sur la conception de solutions pour la récupération d’urgence, consultez la page Designing Cloud Solutions for Disaster Recovery Using active geo-replication (Conception de solutions cloud pour la récupération d’urgence à l’aide de la géo-réplication active).For more information about designing solutions for disaster recovery, see Designing Cloud Solutions for Disaster Recovery Using active geo-replication.

Terminologie et fonctionnalitésTerminology and capabilities

  • Groupe de basculement (FOG)Failover group (FOG)

    Un groupe de basculement est un groupe nommé de bases de données gérées par un même serveur ou dans une instance gérée, et qui peut basculer entièrement vers une autre région lorsqu’une partie ou la totalité des bases de données primaires devient indisponible en raison d’une panne dans la région primaire.A failover group is a named group of databases managed by a single server or within a managed instance that can fail over as a unit to another region in case all or some primary databases become unavailable due to an outage in the primary region. Lorsqu’il est créé pour une instance SQL Managed Instance, un groupe de basculement contient toutes les bases de données utilisateur de l’instance. Ainsi, il n’est possible de configurer qu’un seul groupe de basculement par instance.When it's created for SQL Managed Instance, a failover group contains all user databases in the instance and therefore only one failover group can be configured on an instance.

    Important

    Le nom du groupe de basculement doit être unique à l’échelle globale dans le domaine .database.windows.net.The name of the failover group must be globally unique within the .database.windows.net domain.

  • ServeursServers

    Avec les serveurs, une partie ou la totalité des bases de données utilisateur d’un même serveur peut être placée dans un groupe de basculement.With servers, some or all of the user databases on a server can be placed in a failover group. En outre, un serveur prend en charge plusieurs groupes de basculement sur un seul serveur.Also, a server supports multiple failover groups on a single server.

  • PrimairePrimary

    Le serveur ou l’instance gérée qui héberge les bases de données primaires dans le groupe de basculement.The server or managed instance that hosts the primary databases in the failover group.

  • SecondaireSecondary

    Le serveur ou l’instance gérée qui héberge les bases de données secondaires dans le groupe de basculement.The server or managed instance that hosts the secondary databases in the failover group. Le serveur logique secondaire ne peut pas être situé dans la même région que le serveur logique primaire.The secondary cannot be in the same region as the primary.

  • Ajouter des bases de données uniques au groupe de basculementAdding single databases to failover group

    Vous pouvez placer plusieurs bases de données uniques sur le même serveur, dans le même groupe de basculement.You can put several single databases on the same server into the same failover group. Si vous ajoutez une base de données unique au groupe de basculement, une base de données secondaire de la même édition et de la même taille de calcul est automatiquement créée sur le serveur secondaireIf you add a single database to the failover group, it automatically creates a secondary database using the same edition and compute size on secondary server. que vous avez spécifié à la création du groupe de basculement.You specified that server when the failover group was created. Si vous ajoutez une base de données qui présente déjà une base de données secondaire dans le serveur secondaire, ce lien de géoréplication est hérité par le groupe.If you add a database that already has a secondary database in the secondary server, that geo-replication link is inherited by the group. Lors de l’ajout d’une base de données qui présente déjà une base de données secondaire sur un serveur qui ne fait pas partie du groupe de basculement, une nouvelle base de données secondaire est créée sur le serveur secondaire.When you add a database that already has a secondary database in a server that is not part of the failover group, a new secondary is created in the secondary server.

    Important

    Assurez-vous que le serveur secondaire ne dispose pas d’une base de données portant le même nom, sauf s’il s’agit d’une base de données secondaire existante.Make sure that the secondary server doesn't have a database with the same name unless it is an existing secondary database. Dans les groupes de basculement d’une instance SQL Managed Instance, toutes les bases de données utilisateur sont répliquées.In failover groups for SQL Managed Instance, all user databases are replicated. Vous ne pouvez pas choisir un sous-ensemble de bases de données utilisateur pour la réplication dans le groupe de basculement.You cannot pick a subset of user databases for replication in the failover group.

  • Ajouter des bases de données d’un pool élastique au groupe de basculementAdding databases in elastic pool to failover group

    Vous pouvez placer une partie ou la totalité des bases de données d’un pool élastique dans le même groupe de basculement.You can put all or several databases within an elastic pool into the same failover group. Si la base de données primaire se trouve dans un pool élastique, la base de données secondaire est automatiquement créée dans le pool élastique du même nom (pool secondaire).If the primary database is in an elastic pool, the secondary is automatically created in the elastic pool with the same name (secondary pool). Vérifiez que le serveur secondaire contient un pool élastique portant exactement le même nom et offrant une capacité disponible suffisante pour héberger les bases de données secondaires qui seront créées par le groupe de basculement.You must ensure that the secondary server contains an elastic pool with the same exact name and enough free capacity to host the secondary databases that will be created by the failover group. Si vous ajoutez une base de données dans le pool qui présente déjà une base de données secondaire dans le pool secondaire, ce lien de géoréplication est hérité par le groupe.If you add a database in the pool that already has a secondary database in the secondary pool, that geo-replication link is inherited by the group. Si vous ajoutez une base de données qui présente déjà une base de données secondaire sur un serveur ne faisant pas partie du groupe de basculement, une nouvelle base de données secondaire est créée dans le pool secondaire.When you add a database that already has a secondary database in a server that is not part of the failover group, a new secondary is created in the secondary pool.

  • Amorçage initialInitial Seeding

    Lorsque vous ajoutez des bases de données, des pools élastiques ou des instances gérées à un groupe de basculement, il y a d’abord une phase d’amorçage initiale avant le démarrage de la réplication des données.When adding databases, elastic pools, or managed instances to a failover group, there is an initial seeding phase before data replication starts. La phase d’amorçage initiale est l’opération la plus longue et la plus coûteuse.The initial seeding phase is the longest and most expensive operation. Une fois l’amorçage initial terminé, les données sont synchronisées, puis seules les modifications de données ultérieures sont répliquées.Once initial seeding completes, data is synchronized, and then only subsequent data changes are replicated. Le temps nécessaire à la réalisation de l’amorçage initial dépend de la taille de vos données, du nombre de bases de données répliquées et de la vitesse de la liaison entre les entités dans le groupe de basculement.The time it takes for the initial seed to complete depends on the size of your data, number of replicated databases, and the speed of the link between the entities in the failover group. Dans des circonstances normales, la vitesse d’amorçage possible peut atteindre 500 Go par heure pour SQL Database, et 360 Go par heure pour SQL Managed Instance.Under normal circumstances, possible seeding speed is up to 500 GB an hour for SQL Database, and up to 360 GB an hour for SQL Managed Instance. L’amorçage est effectué pour toutes les bases de données en parallèle.Seeding is performed for all databases in parallel.

    Pour SQL Managed Instance, prenez en compte la vitesse de la liaison Express Route entre les deux instances lors de l’estimation de la durée de la phase d’amorçage initiale.For SQL Managed Instance, consider the speed of the Express Route link between the two instances when estimating the time of the initial seeding phase. Si la vitesse de la liaison entre les deux instances est plus lente que nécessaire, la durée de l’amorçage risque d’être sensiblement perturbée.If the speed of the link between the two instances is slower than what is necessary, the time to seed is likely be notably impacted. Vous pouvez utiliser la vitesse d’amorçage indiquée, ainsi que le nombre de bases de données, la taille totale des données et la vitesse de liaison pour estimer la durée de la phase d’amorçage initiale avant le début de la réplication des données.You can use the stated seeding speed, number of databases, total size of data, and the link speed to estimate how long the initial seeding phase will take before data replication starts. Par exemple, pour une base de données individuelle de 100 Go, la phase d’amorçage initiale prendrait environ 1,2 heure si la liaison est en mesure d’envoyer (push) 84 Go par heure, et si aucune autre base de données n’est en cours d’amorçage.For example, for a single 100 GB database, the initial seed phase would take about 1.2 hours if the link is capable of pushing 84 GB per hour, and if there are no other databases being seeded. Si la liaison ne peut transférer que 10 Go par heure, l’amorçage d’une base de données de 100 Go prendra environ 10 heures.If the link can only transfer 10 GB per hour, then seeding a 100 GB database will take about 10 hours. S’il faut répliquer plusieurs bases de données, l’amorçage est effectué en parallèle et, lorsqu’il est associé à une vitesse de liaison lente, la phase d’amorçage initiale peut prendre beaucoup plus de temps. Cela est particulièrement vrai si l’amorçage parallèle des données de toutes les bases de données est supérieur à la bande passante de liaison disponible.If there are multiple databases to replicate, seeding will be executed in parallel, and, when combined with a slow link speed, the initial seeding phase may take considerably longer, especially if the parallel seeding of data from all databases exceeds the available link bandwidth. Si la bande passante réseau entre deux instances est limitée et que vous ajoutez plusieurs instances gérées à un groupe de basculement, ajoutez-les de manière successive, une par une.If the network bandwidth between two instances is limited and you are adding multiple managed instances to a failover group, consider adding multiple managed instances to the failover group sequentially, one by one. Étant donné une référence SKU de passerelle de taille appropriée entre les deux instances managées, si la bande passante du réseau d’entreprise le permet, il est possible d’atteindre des vitesses allant jusqu’à 360 Go par heure.Given an appropriately sized gateway SKU between the two managed instances, and if corporate network bandwidth allows it, it's possible to achieve speeds as high as 360 GB an hour.

  • Zone DNSDNS zone

    ID unique qui est généré automatiquement lorsqu’une instance SQL Managed Instance est créée.A unique ID that is automatically generated when a new SQL Managed Instance is created. Un certificat multidomaine (SAN) est approvisionné pour cette instance afin d’authentifier les connexions clientes effectuées auprès de toutes les instances présentes dans la même zone DNS.A multi-domain (SAN) certificate for this instance is provisioned to authenticate the client connections to any instance in the same DNS zone. Les deux instances gérées d’un même groupe de basculement doivent partager la zone DNS.The two managed instances in the same failover group must share the DNS zone.

    Notes

    Il n’est pas nécessaire de disposer d’un ID de zone DNS pour les groupes de basculement créés pour SQL Database.A DNS zone ID is not required for failover groups created for SQL Database.

  • Écouteur en lecture-écriture du groupe de basculementFailover group read-write listener

    Un enregistrement DNS CNAME qui pointe vers l’URL du serveur primaire actuel.A DNS CNAME record that points to the current primary's URL. Il est généré automatiquement lorsque le groupe de basculement est créé, et permet à la charge de travail en lecture-écriture de se reconnecter en toute transparence à la base de données primaire lorsqu’elle est modifiée après le basculement.It is created automatically when the failover group is created and allows the read-write workload to transparently reconnect to the primary database when the primary changes after failover. Lorsque le groupe de basculement est créé sur un serveur, l’enregistrement DNS CNAME pour l’URL de l’écouteur est formé comme suit : <fog-name>.database.windows.net.When the failover group is created on a server, the DNS CNAME record for the listener URL is formed as <fog-name>.database.windows.net. Lorsque le groupe de basculement est créé sur une instance SQL Managed Instance, l’enregistrement DNS CNAME pour l’URL de l’écouteur est formé comme suit : <fog-name>.<zone_id>.database.windows.net.When the failover group is created on a SQL Managed Instance, the DNS CNAME record for the listener URL is formed as <fog-name>.<zone_id>.database.windows.net.

  • Écouteur en lecture seule du groupe de basculementFailover group read-only listener

    Enregistrement DNS CNAME formé pour l’écouteur en lecture seule pointant vers l’URL du serveur secondaire.A DNS CNAME record formed that points to the read-only listener that points to the secondary's URL. Il est créé automatiquement lorsque le groupe de basculement est créé et permet à la charge de travail SQL en lecture seule de se connecter en toute transparence à la base de données secondaire à l’aide des règles d’équilibrage de charge spécifiées.It is created automatically when the failover group is created and allows the read-only SQL workload to transparently connect to the secondary using the specified load-balancing rules. Lorsque le groupe de basculement est créé sur un serveur, l’enregistrement DNS CNAME pour l’URL de l’écouteur est formé comme suit : <fog-name>.secondary.database.windows.net.When the failover group is created on a server, the DNS CNAME record for the listener URL is formed as <fog-name>.secondary.database.windows.net. Lorsque le groupe de basculement est créé sur une instance SQL Managed Instance, l’enregistrement DNS CNAME pour l’URL de l’écouteur est formé comme suit : <fog-name>.secondary.<zone_id>.database.windows.net.When the failover group is created on a SQL Managed Instance, the DNS CNAME record for the listener URL is formed as <fog-name>.secondary.<zone_id>.database.windows.net.

  • Stratégie de basculement automatiqueAutomatic failover policy

    Par défaut, un groupe de basculement est configuré avec une stratégie de basculement automatique.By default, a failover group is configured with an automatic failover policy. Azure déclenche le basculement dès que la défaillance est détectée et que la période de grâce est arrivée à expiration.Azure triggers failover after the failure is detected and the grace period has expired. Le système doit vérifier que la panne ne peut pas être atténuée par l’infrastructure de haute disponibilité intégrée en raison de l’échelle de l’impact.The system must verify that the outage cannot be mitigated by the built-in high availability infrastructure due to the scale of the impact. Si vous souhaitez contrôler le workflow de basculement à partir de l’application ou manuellement, vous pouvez désactiver le basculement automatique.If you want to control the failover workflow from the application or manually, you can turn off automatic failover.

    Notes

    Compte tenu du fait que la vérification de l’étendue de la panne et que la rapidité avec laquelle elle peut être atténuée impliquent des actions humaines de la part de l’équipe des opérations, la période de grâce ne peut pas être fixée en dessous d’une heure.Because verification of the scale of the outage and how quickly it can be mitigated involves human actions by the operations team, the grace period cannot be set below one hour. Cette limitation s’applique à toutes les bases de données du groupe de basculement, quel que soit l’état de la synchronisation de leurs données.This limitation applies to all databases in the failover group regardless of their data synchronization state.

  • Stratégie de basculement en lecture seuleRead-only failover policy

    Par défaut, le basculement de l’écouteur en lecture seule est désactivé.By default, the failover of the read-only listener is disabled. Il garantit que les performances du serveur principal ne sont pas affectées lorsque le serveur secondaire est hors connexion.It ensures that the performance of the primary is not impacted when the secondary is offline. Toutefois, cela signifie également que les sessions en lecture seule ne seront pas en mesure de se connecter tant que le serveur secondaire n’aura pas été récupérée.However, it also means the read-only sessions will not be able to connect until the secondary is recovered. Si vous ne pouvez pas tolérer des temps d’arrêt pour les sessions en lecture seule et que vous pouvez utiliser le serveur principal pour le trafic en lecture seule et en lecture-écriture au prix d’une dégradation potentielle des performances du serveur principal, vous pouvez activer le basculement pour l’écouteur en lecture seule en configurant la propriété AllowReadOnlyFailoverToPrimary.If you cannot tolerate downtime for the read-only sessions and can use the primary for both read-only and read-write traffic at the expense of the potential performance degradation of the primary, you can enable failover for the read-only listener by configuring the AllowReadOnlyFailoverToPrimary property. Dans ce cas, le trafic en lecture seule est automatiquement redirigé vers le serveur principal si le serveur secondaire est indisponible.In that case, the read-only traffic will be automatically redirected to the primary if the secondary is not available.

    Notes

    La propriété AllowReadOnlyFailoverToPrimary n’a d’effet que si la stratégie de basculement automatique est activée et qu’un basculement automatique a été déclenché par Azure.The AllowReadOnlyFailoverToPrimary property only has effect if automatic failover policy is enabled and an automatic failover has been triggered by Azure. Dans ce cas, si la propriété est définie sur True, le nouveau serveur principal servira les sessions en lecture-écriture et en lecture seule.In that case, if the property is set to True, the new primary will serve both read-write and read-only sessions.

  • Basculement planifiéPlanned failover

    Le basculement planifié effectue une synchronisation complète entre les bases de données primaire et secondaire avant que la seconde ne bascule dans le rôle primaire.Planned failover performs full synchronization between primary and secondary databases before the secondary switches to the primary role. Cela empêche toute perte de données.This guarantees no data loss. Le basculement planifié des appareils est utilisé dans les scénarios suivants :Planned failover is used in the following scenarios:

    • Simuler des récupérations d’urgence en production lorsque la perte de données n’est pas acceptablePerform disaster recovery (DR) drills in production when the data loss is not acceptable
    • Déplacer les bases de données vers une autre régionRelocate the databases to a different region
    • Renvoyer les bases de données vers la région primaire une fois la panne éliminée (restauration automatique).Return the databases to the primary region after the outage has been mitigated (failback).
  • Basculement non planifiéUnplanned failover

    Un basculement non planifié ou forcé fait immédiatement basculer la base de données secondaire vers le rôle primaire sans synchronisation avec la base de données primaire.Unplanned or forced failover immediately switches the secondary to the primary role without any synchronization with the primary. Cette opération entraîne une perte de données.This operation will result in data loss. Le basculement non planifié est utilisé comme méthode de récupération pendant les pannes, lorsque la base de données primaire n’est pas accessible.Unplanned failover is used as a recovery method during outages when the primary is not accessible. Lorsque la base de données primaire d’origine est de nouveau en ligne, elle se reconnecte sans synchronisation et devient une nouvelle base de données secondaire.When the original primary is back online, it will automatically reconnect without synchronization and become a new secondary.

  • Basculement manuelManual failover

    Vous pouvez lancer manuellement le basculement à tout moment, quelle que soit la configuration du basculement automatique.You can initiate failover manually at any time regardless of the automatic failover configuration. Si la stratégie de basculement automatique n’est pas configurée, un basculement manuel est nécessaire pour récupérer les bases de données dans le groupe de basculement vers le serveur secondaire.If automatic failover policy is not configured, manual failover is required to recover databases in the failover group to the secondary. Vous pouvez lancer un basculement forcé ou convivial (avec synchronisation complète des données).You can initiate forced or friendly failover (with full data synchronization). Ce dernier peut être utilisé pour déplacer le serveur primaire dans la région secondaire.The latter could be used to relocate the primary to the secondary region. Une fois le basculement terminé, les enregistrements DNS sont automatiquement mis à jour pour garantir la connexion au nouveau serveur principal.When failover is completed, the DNS records are automatically updated to ensure connectivity to the new primary.

  • Période de grâce avec perte de donnéesGrace period with data loss

    Comme les bases de données primaires et secondaires sont synchronisées avec la réplication asynchrone, le basculement peut entraîner une perte de données.Because the primary and secondary databases are synchronized using asynchronous replication, the failover may result in data loss. Vous pouvez personnaliser la stratégie de basculement automatique en fonction de la tolérance de votre application aux pertes de données.You can customize the automatic failover policy to reflect your application’s tolerance to data loss. En configurant GracePeriodWithDataLossHours, vous pouvez contrôler le délai observé par le système avant d’initialiser le basculement qui est susceptible d’entraîner une perte de données.By configuring GracePeriodWithDataLossHours, you can control how long the system waits before initiating the failover that is likely to result data loss.

  • Plusieurs groupes de basculementMultiple failover groups

    Vous pouvez configurer plusieurs groupes de basculement pour la même paire de serveurs afin de contrôler l’étendue des basculements.You can configure multiple failover groups for the same pair of servers to control the scope of failovers. Chaque groupe bascule indépendamment.Each group fails over independently. Si votre application mutualisée fait appel à des pools élastiques, vous pouvez utiliser cette fonctionnalité pour combiner des bases de données primaires et secondaires dans chaque pool.If your multi-tenant application uses elastic pools, you can use this capability to mix primary and secondary databases in each pool. De cette manière, vous pouvez réduire l’impact d’une panne à la moitié seulement des locataires.This way you can reduce the impact of an outage to only half of the tenants.

    Notes

    SQL Managed Instance ne prend pas en charge plusieurs groupes de basculement.SQL Managed Instance does not support multiple failover groups.

AutorisationsPermissions

Les autorisations pour un groupe de basculement sont gérées via un contrôle d’accès en fonction du rôle Azure (Azure RBAC).Permissions for a failover group are managed via Azure role-based access control (Azure RBAC). Le rôle Contributeur SQL Server dispose des autorisations nécessaires pour gérer des groupes de basculement.The SQL Server Contributor role has all the necessary permissions to manage failover groups.

Créer un groupe de basculementCreate failover group

Pour créer un groupe de basculement, vous devez disposer d’un accès en écriture Azure RBAC aux serveurs principal et secondaire ainsi qu’à toutes les bases de données du groupe de basculement.To create a failover group, you need Azure RBAC write access to both the primary and secondary servers, and to all databases in the failover group. Pour une instance SQL Managed Instance, vous devez disposer d’un accès en écriture Azure RBAC aux instances SQL Managed Instance principale et secondaire. Toutefois, les autorisations d’accès aux bases de données individuelles ne sont pas pertinentes dans la mesure où les bases de données SQL Managed Instance individuelles ne peuvent pas être ajoutées ou supprimées d’un groupe de basculement.For a SQL Managed Instance, you need Azure RBAC write access to both the primary and secondary SQL Managed Instance, but permissions on individual databases are not relevant, because individual SQL Managed Instance databases cannot be added to or removed from a failover group.

Mettre à jour un groupe de basculementUpdate a failover group

Pour mettre à jour un groupe de basculement, vous devez disposer d’un accès en écriture Azure RBAC au groupe de basculement et à toutes les bases de données du serveur principal ou de l’instance gérée actuels.To update a failover group, you need Azure RBAC write access to the failover group, and all databases on the current primary server or managed instance.

Faire basculer un groupe de basculementFail over a failover group

Pour faire basculer un groupe de basculement, vous devez disposer d’un accès en écriture Azure RBAC au groupe de basculement sur le nouveau serveur principal ou la nouvelle instance gérée.To fail over a failover group, you need Azure RBAC write access to the failover group on the new primary server or managed instance.

Meilleures pratiques pour SQL DatabaseBest practices for SQL Database

Le groupe de basculement automatique doit être configuré sur le serveur primaire, qu’il connectera au serveur secondaire dans une autre région Azure.The auto-failover group must be configured on the primary server and will connect it to the secondary server in a different Azure region. Les groupes peuvent inclure une partie ou la totalité des bases de données dans ces serveurs.The groups can include all or some databases in these servers. Le diagramme suivant illustre la configuration standard d’une application cloud géoredondante avec plusieurs bases de données et un groupe de basculement automatique.The following diagram illustrates a typical configuration of a geo-redundant cloud application using multiple databases and auto-failover group.

Le diagramme montre une configuration standard d’une application cloud géoredondante utilisant plusieurs bases de données et un groupe de basculement automatique.

Notes

Voir Ajouter une base de données Azure SQL Database à un groupe de basculement pour obtenir un didacticiel détaillé sur l’ajout d’une base de données SQL Database à un groupe de basculement.See Add SQL Database to a failover group for a detailed step-by-step tutorial adding a database in SQL Database to a failover group.

Quand vous concevez un service en pensant à la continuité d’activité, suivez ces instructions générales :When designing a service with business continuity in mind, follow these general guidelines:

Utilisation d’un ou plusieurs groupes de basculement pour gérer le basculement de plusieurs bases de donnéesUsing one or several failover groups to manage failover of multiple databases

Un ou plusieurs groupes de basculement peuvent être créés entre deux serveurs situés dans des régions différentes (serveurs principal et serveur secondaire).One or many failover groups can be created between two servers in different regions (primary and secondary servers). Chaque groupe peut inclure une ou plusieurs bases de données qui sont récupérées ensemble dans le cas où une partie ou la totalité des bases de données primaires deviennent indisponibles en raison d’une panne dans la région principale.Each group can include one or several databases that are recovered as a unit in case all or some primary databases become unavailable due to an outage in the primary region. Le groupe de basculement crée une base de données géo-secondaire avec le même objectif de service que la base de données primaire.The failover group creates geo-secondary database with the same service objective as the primary. Si vous ajoutez une relation de géoréplication existante au groupe de basculement, vérifiez que la base de données géosecondaire est configurée avec le même niveau de service et la même taille de calcul que la base de données primaire.If you add an existing geo-replication relationship to the failover group, make sure the geo-secondary is configured with the same service tier and compute size as the primary.

Important

La création de groupes de basculement entre deux serveurs dans différents abonnements n’est actuellement pas prise en charge pour Azure SQL Database.Creating failover groups between two servers in different subscriptions is not currently supported for Azure SQL Database. Le fait de déplacer le serveur principal ou secondaire vers un autre abonnement après la création du groupe de basculement peut entraîner des défaillances au niveau des requêtes de basculement et d’autres opérations.If you move the primary or secondary server to a different subscription after the failover group has been created, it could result in failures of the failover requests and other operations.

Utilisation d’un écouteur en lecture-écriture pour la charge de travail OLTPUsing read-write listener for OLTP workload

Quand vous effectuez des opérations OLTP, utilisez <fog-name>.database.windows.net, car l’URL du serveur et les connexions sont automatiquement dirigées vers le serveur principal.When performing OLTP operations, use <fog-name>.database.windows.net as the server URL and the connections are automatically directed to the primary. L’URL ne change pas après le basculement.This URL does not change after the failover. Notez que le basculement implique la mise à jour de l’enregistrement DNS de façon à ce que les connexions clients soient redirigées vers le nouveau serveur primaire seulement après l’actualisation du cache DNS.Note the failover involves updating the DNS record so the client connections are redirected to the new primary only after the client DNS cache is refreshed.

Utilisation d’un écouteur en lecture seule pour une charge de travail en lecture seuleUsing read-only listener for read-only workload

Si vous avez une charge de travail en lecture seule isolée logiquement et qui est tolérante à une certaine obsolescence des données, vous pouvez utiliser la base de données secondaire dans l’application.If you have a logically isolated read-only workload that is tolerant to certain staleness of data, you can use the secondary database in the application. Pour les sessions en lecture seule, utilisez <fog-name>.secondary.database.windows.net, car l’URL du serveur et la connexion sont automatiquement dirigées vers le serveur principal.For read-only sessions, use <fog-name>.secondary.database.windows.net as the server URL and the connection is automatically directed to the secondary. Il est également recommandé d’indiquer dans la tentative de lecture de la chaîne de connexion à l’aide de ApplicationIntent=ReadOnly.It is also recommended that you indicate in connection string read intent by using ApplicationIntent=ReadOnly.

Préparation à une détérioration des performancesPreparing for performance degradation

Une application Azure classique fait appel à plusieurs services Azure et inclut plusieurs composants.A typical Azure application uses multiple Azure services and consists of multiple components. Le basculement automatique du groupe de basculement est déclenché en fonction de l’état des seuls composants Azure SQL.The automated failover of the failover group is triggered based on the state the Azure SQL components alone. Il peut arriver que les autres services Azure de la région primaire ne soient pas affectés par la panne et que leurs composants soient toujours disponibles dans cette région.Other Azure services in the primary region may not be affected by the outage and their components may still be available in that region. Une fois que les bases de données primaires ont basculé vers la région de récupération d’urgence, la latence entre les composants dépendants peut augmenter.Once the primary databases switch to the DR region, the latency between the dependent components may increase. Pour éviter les conséquences négatives d’une latence plus élevée sur les performances de l’application, vérifiez que tous les composants de l’application sont redondants dans la région de récupération d’urgence et suivez ces consignes de sécurité réseau.To avoid the impact of higher latency on the application's performance, ensure the redundancy of all the application's components in the DR region and follow these network security guidelines.

Préparation à une perte de donnéesPreparing for data loss

Si une panne est détectée, Azure patiente pendant la période que vous avez spécifiée avec GracePeriodWithDataLossHours.If an outage is detected, Azure waits for the period you specified by GracePeriodWithDataLossHours. La valeur par défaut est 1 heure.The default value is 1 hour. Si vous ne pouvez pas vous permettre de perdre des données, veillez à définir dans la commande GracePeriodWithDataLossHours un nombre suffisamment grand, par exemple, 24 heures.If you cannot afford data loss, make sure to set GracePeriodWithDataLossHours to a sufficiently large number, such as 24 hours. Utilisez le basculement de groupe manuel pour effectuer une restauration automatique du serveur secondaire au serveur primaire.Use manual group failover to fail back from the secondary to the primary.

Important

Les pools élastiques disposant de 800 DTU au maximum et de plus de 250 bases de données utilisant la géoréplication peuvent rencontrer des problèmes, notamment des basculements planifiés plus longs et une dégradation des performances.Elastic pools with 800 or fewer DTUs and more than 250 databases using geo-replication may encounter issues including longer planned failovers and degraded performance. Ces problèmes sont davantage susceptibles de se produire pour les charges de travail intensives en écriture, quand les points de terminaison de géoréplication sont géographiquement très éloignés, ou quand plusieurs points de terminaison secondaires sont utilisés pour chaque base de données.These issues are more likely to occur for write intensive workloads, when geo-replication endpoints are widely separated by geography, or when multiple secondary endpoints are used for each database. Les symptômes de ces problèmes sont signalés quand le décalage de la géoréplication augmente au fil du temps.Symptoms of these issues are indicated when the geo-replication lag increases over time. Ce décalage peut être surveillé avec sys.dm_geo_replication_link_status.This lag can be monitored using sys.dm_geo_replication_link_status. Si ces problèmes se produisent, l’atténuation des risques inclut l’augmentation du nombre de DTU du pool ou la réduction du nombre de bases de données géorépliquées dans ce même pool.If these issues occur, then mitigations include increasing the number of pool DTUs, or reducing the number of geo-replicated databases in the same pool.

Changement de la région secondaire du groupe de basculementChanging secondary region of the failover group

Pour illustrer la séquence de changement, nous partons du principe que le serveur A est le serveur principal, que le serveur B est le serveur secondaire existant et que le serveur C est le nouveau serveur secondaire dans la troisième région.To illustrate the change sequence, we will assume that server A is the primary server, server B is the existing secondary server, and server C is the new secondary in the third region. Pour faire la transition, suivez ces étapes :To make the transition, follow these steps:

  1. Sur le serveur C, créez des bases de données secondaires supplémentaires de chaque base de données du serveur A en utilisant la géoréplication active.Create additional secondaries of each database on server A to server C using active geo-replication. Chaque base de données présente sur le serveur A dispose alors de deux bases de données secondaires, une sur le serveur B et l’autre sur le serveur C. Les bases de données primaires restent ainsi protégées durant la transition.Each database on server A will have two secondaries, one on server B and one on server C. This will guarantee that the primary databases remain protected during the transition.
  2. Supprimez le groupe de basculement.Delete the failover group. À ce stade, les connexions échouent.At this point the logins will be failing. La raison en est que les alias SQL des écouteurs du groupe de basculement ont été supprimés et que la passerelle ne reconnaît pas le nom du groupe de basculement.This is because the SQL aliases for the failover group listeners have been deleted and the gateway will not recognize the failover group name.
  3. Recréez le groupe de basculement en utilisant le même nom entre les serveurs A et C. À ce stade, les connexions n’échouent plus.Re-create the failover group with the same name between servers A and C. At this point the logins will stop failing.
  4. Ajoutez toutes les bases de données primaires du serveur A au nouveau groupe de basculement.Add all primary databases on server A to the new failover group.
  5. Supprimez le serveur B. Toutes les bases de données de B sont alors supprimées automatiquement.Drop server B. All databases on B will be deleted automatically.

Changement de la région primaire du groupe de basculementChanging primary region of the failover group

Pour illustrer la séquence de changement, nous partons du principe que le serveur A est le serveur principal, que le serveur B est le serveur secondaire existant et que le serveur C est le nouveau serveur principal dans la troisième région.To illustrate the change sequence, we will assume server A is the primary server, server B is the existing secondary server, and server C is the new primary in the third region. Pour faire la transition, suivez ces étapes :To make the transition, follow these steps:

  1. Effectuez un basculement planifié pour faire du serveur B le serveur principal. Le serveur A devient alors le nouveau serveur secondaire.Perform a planned failover to switch the primary server to B. Server A will become the new secondary server. Le basculement peut occasionner un temps d’arrêt de plusieurs minutes.The failover may result in several minutes of downtime. Sa durée effective dépend de la taille du groupe de basculement.The actual time will depend on the size of failover group.
  2. Sur le serveur C, créez des bases de données secondaires supplémentaires de chaque base de données du serveur B en utilisant la géoréplication active.Create additional secondaries of each database on server B to server C using active geo-replication. Chaque base de données présente sur le serveur B dispose alors de deux bases de données secondaires, une sur le serveur A et l’autre sur le serveur C. Les bases de données primaires restent ainsi protégées durant la transition.Each database on server B will have two secondaries, one on server A and one on server C. This will guarantee that the primary databases remain protected during the transition.
  3. Supprimez le groupe de basculement.Delete the failover group. À ce stade, les connexions échouent.At this point the logins will be failing. La raison en est que les alias SQL des écouteurs du groupe de basculement ont été supprimés et que la passerelle ne reconnaît pas le nom du groupe de basculement.This is because the SQL aliases for the failover group listeners have been deleted and the gateway will not recognize the failover group name.
  4. Recréez le groupe de basculement en utilisant le même nom entre les serveurs B et C. À ce stade, les connexions n’échouent plus.Re-create the failover group with the same name between servers B and C. At this point the logins will stop failing.
  5. Ajoutez toutes les bases de données primaires du serveur B au nouveau groupe de basculement.Add all primary databases on B to the new failover group.
  6. Procédez à un basculement planifié du groupe de basculement pour interchanger B et C. Le serveur C devient alors le serveur principal et B le serveur secondaire.Perform a planned failover of the failover group to switch B and C. Now server C will become the primary and B - the secondary. Toutes les bases de données secondaires du serveur A sont automatiquement liées aux bases de données primaires de C. Comme à l’étape 1, le basculement peut occasionner un temps d’arrêt de plusieurs minutes.All secondary databases on server A will be automatically linked to the primaries on C. As in step 1, the failover may result in several minutes of downtime.
  7. Supprimez le serveur A. Toutes les bases de données de A sont alors supprimées automatiquement.Drop the server A. All databases on A will be deleted automatically.

Important

Une fois le groupe de basculement supprimé, les enregistrements DNS des points de terminaison de l’écouteur sont également supprimés.When the failover group is deleted, the DNS records for the listener endpoints are also deleted. À ce stade, il n’est pas entièrement exclu que quelqu’un d’autre crée un groupe de basculement ou un alias de serveur sous le même nom, ce qui vous empêchera de l’utiliser à nouveau.At that point, there is a non-zero probability of somebody else creating a failover group or server alias with the same name, which will prevent you from using it again. Pour limiter ce risque, évitez d’utiliser des noms de groupe de basculement génériques.To minimize the risk, don't use generic failover group names.

Meilleures pratiques pour SQL Managed InstanceBest practices for SQL Managed Instance

Le groupe de basculement automatique doit être configuré sur l’instance primaire, qu’il connectera à l’instance secondaire dans une autre région Azure.The auto-failover group must be configured on the primary instance and will connect it to the secondary instance in a different Azure region. Toutes les bases de données de l’instance seront répliquées sur l’instance secondaire.All databases in the instance will be replicated to the secondary instance.

Le diagramme suivant illustre la configuration standard d’une application cloud géoredondante avec une instance managée et un groupe de basculement automatique.The following diagram illustrates a typical configuration of a geo-redundant cloud application using managed instance and auto-failover group.

Diagramme du basculement automatique

Notes

Voir Ajouter une instance gérée à un groupe de basculement pour obtenir un didacticiel détaillé sur l’ajout d’une instance SQL Managed Instance afin d’utiliser un groupe de basculement.See Add managed instance to a failover group for a detailed step-by-step tutorial adding a SQL Managed Instance to use failover group.

Si votre application utilise une instance SQL Managed Instance en tant que couche Données, suivez ces recommandations générales lors de la conception des éléments en rapport avec la continuité d’activité :If your application uses SQL Managed Instance as the data tier, follow these general guidelines when designing for business continuity:

Création de l’instance secondaireCreating the secondary instance

Pour garantir une connectivité ininterrompue à l’instance SQL Managed Instance principale après le basculement, les instances principale et secondaire doivent se trouver dans la même zone DNS.To ensure non-interrupted connectivity to the primary SQL Managed Instance after failover both the primary and secondary instances must be in the same DNS zone. Cela garantit que le même certificat multidomaine (SAN) peut être utilisé pour authentifier les connexions clientes avec les deux instances du groupe de basculement.It will guarantee that the same multi-domain (SAN) certificate can be used to authenticate the client connections to either of the two instances in the failover group. Lorsque votre application est prête pour le déploiement en production, créez une instance SQL Managed Instance secondaire dans une autre région et assurez-vous qu’elle partage la même zone DNS que l’instance SQL Managed Instance principale.When your application is ready for production deployment, create a secondary SQL Managed Instance in a different region and make sure it shares the DNS zone with the primary SQL Managed Instance. Vous pouvez y parvenir en spécifiant le paramètre facultatif au moment de la création.You can do it by specifying the optional parameter during creation. Si vous utilisez PowerShell ou l’API REST, le nom du paramètre facultatif est DNS Zone Partner, et le nom du champ facultatif correspondant dans le portail Azure est Instance managée principale.If you are using PowerShell or the REST API, the name of the optional parameter is DNS Zone Partner, and the name of the corresponding optional field in the Azure portal is Primary Managed Instance.

Important

La première instance gérée créée dans le sous-réseau détermine la zone DNS pour toutes les instances suivantes de ce même sous-réseau.The first managed instance created in the subnet determines DNS zone for all subsequent instances in the same subnet. Cela signifie que deux instances d'un même sous-réseau ne peuvent pas appartenir à des zones DNS différentes.This means that two instances from the same subnet cannot belong to different DNS zones.

Pour plus d’informations sur la création de l’instance SQL Managed Instance secondaire dans la même zone DNS que l’instance principale, voir Créer une instance managée secondaire.For more information about creating the secondary SQL Managed Instance in the same DNS zone as the primary instance, see Create a secondary managed instance.

Utilisation de régions jumelées géographiquementUsing geo-paired regions

Déployez les deux instances managées dans des régions jumelées pour des raisons de performances.Deploy both managed instances to paired regions for performance reasons. Les instances managées résidant dans des régions jumelées géographiquement offrent des performances nettement meilleures que celles résidant dans des régions non jumelées.Managed instances residing in geo-paired regions have much better performance compared to unpaired regions.

Activation du trafic de réplication entre deux instancesEnabling replication traffic between two instances

Étant donné que chaque instance est isolée dans son propre réseau virtuel, le trafic bidirectionnel entre ces réseaux virtuels doit être autorisé.Because each instance is isolated in its own VNet, two-directional traffic between these VNets must be allowed. Voir Passerelle VPN AzureSee Azure VPN gateway

Création d’un groupe de basculement entre des instances gérées d’abonnements différentsCreating a failover group between managed instances in different subscriptions

Vous pouvez créer un groupe de basculement entre des instances managées SQL dans deux abonnements différents, à condition que les abonnements soient associés au même abonné Azure Active Directory.You can create a failover group between SQL Managed Instances in two different subscriptions, as long as subscriptions are associated to the same Azure Active Directory Tenant. Lorsque vous utilisez l’API PowerShell, vous pouvez le faire en spécifiant le paramètre PartnerSubscriptionId pour l’instance SQL Managed Instance secondaire.When using PowerShell API, you can do it by specifying the PartnerSubscriptionId parameter for the secondary SQL Managed Instance. Lors de l’utilisation de l’API REST, chaque ID d’instance inclus dans le paramètre properties.managedInstancePairs peut avoir son propre subscriptionID.When using REST API, each instance ID included in the properties.managedInstancePairs parameter can have its own subscriptionID.

Important

Le Portail Azure ne prend pas en charge la création de groupes de basculement sur différents abonnements.Azure portal does not support the creation of failover groups across different subscriptions. De plus, pour les groupes de basculement existants sur différents abonnements et/ou groupes de ressources, le basculement ne peut pas être initié manuellement à l’aide du portail à partir de l’instance SQL Managed Instance principale.Also, for the existing failover groups across different subscriptions and/or resource groups, failover cannot be initiated manually via portal from the primary SQL Managed Instance. Initiez-le plutôt à partir de l’instance géosecondaire.Initiate it from the geo-secondary instance instead.

Gestion du basculement vers une instance secondaireManaging failover to secondary instance

Le groupe de basculement gère le basculement de toutes les bases de données dans l’instance SQL Managed Instance.The failover group will manage the failover of all the databases in the SQL Managed Instance. Lorsqu’un groupe est créé, chaque base de données dans l’instance est automatiquement géorépliquée sur l’instance SQL Managed Instance secondaire.When a group is created, each database in the instance will be automatically geo-replicated to the secondary SQL Managed Instance. Vous ne pouvez pas utiliser les groupes de basculement pour initier le basculement partiel d’un sous-ensemble de bases de données.You cannot use failover groups to initiate a partial failover of a subset of the databases.

Important

Si une base de données est supprimée de l’instance SQL Managed Instance principale, elle est également abandonnée automatiquement sur l’instance SQL Managed Instance géorépliquée secondaire.If a database is removed from the primary SQL Managed Instance, it will also be dropped automatically on the geo-secondary SQL Managed Instance.

Utilisation d’un écouteur en lecture-écriture pour la charge de travail OLTPUsing read-write listener for OLTP workload

Quand vous effectuez des opérations OLTP, utilisez <fog-name>.zone_id.database.windows.net, car l’URL du serveur et les connexions sont automatiquement dirigées vers le serveur principal.When performing OLTP operations, use <fog-name>.zone_id.database.windows.net as the server URL and the connections are automatically directed to the primary. L’URL ne change pas après le basculement.This URL does not change after the failover. Le basculement implique la mise à jour de l’enregistrement DNS de façon à ce que les connexions clients soient redirigées vers le nouveau serveur primaire seulement après l’actualisation du cache DNS.The failover involves updating the DNS record, so the client connections are redirected to the new primary only after the client DNS cache is refreshed. Étant donné que l’instance secondaire partage la même zone DNS que l’instance principale, l’application cliente peut se reconnecter à l’aide du même certificat SAN.Because the secondary instance shares the DNS zone with the primary, the client application will be able to reconnect to it using the same SAN certificate.

Utilisation d’un écouteur en lecture seule pour se connecter à l’instance secondaireUsing read-only listener to connect to the secondary instance

Si vous avez une charge de travail en lecture seule isolée logiquement et qui est tolérante à une certaine obsolescence des données, vous pouvez utiliser la base de données secondaire dans l’application.If you have a logically isolated read-only workload that is tolerant to certain staleness of data, you can use the secondary database in the application. Pour vous connecter directement à l’instance géorépliquée secondaire, utilisez <fog-name>.secondary.<zone_id>.database.windows.net, car l’URL du serveur et la connexion sont automatiquement dirigées vers l’instance géorépliquée secondaire.To connect directly to the geo-replicated secondary, use <fog-name>.secondary.<zone_id>.database.windows.net as the server URL and the connection is made directly to the geo-replicated secondary.

Notes

Dans les niveaux de service Premium, Critique pour l’entreprise et Hyperscale, Azure SQL Database prend en charge l’utilisation de réplicas en lecture seule pour exécuter des charges de travail de requête en lecture seule, en utilisant la capacité d’un ou de plusieurs réplicas en lecture seule et le paramètre ApplicationIntent=ReadOnly dans la chaîne de connexion.In Premium, Business Critical, and Hyperscale service tiers, SQL Database supports the use of read-only replicas to run read-only query workloads using the capacity of one or more read-only replicas, using the ApplicationIntent=ReadOnly parameter in the connection string. Lorsque vous avez configuré une instance géorépliquée secondaire, vous pouvez utiliser cette fonction pour vous connecter à un réplica en lecture seule à l’emplacement primaire ou à l’emplacement géorépliqué.When you have configured a geo-replicated secondary, you can use this capability to connect to either a read-only replica in the primary location or in the geo-replicated location.

  • Pour vous connecter à un réplica en lecture seule à l’emplacement primaire, utilisez ApplicationIntent=ReadOnly et <fog-name>.<zone_id>.database.windows.net.To connect to a read-only replica in the primary location, use ApplicationIntent=ReadOnly and <fog-name>.<zone_id>.database.windows.net.
  • Pour vous connecter à un réplica en lecture seule à l’emplacement secondaire, utilisez ApplicationIntent=ReadOnly et <fog-name>.secondary.<zone_id>.database.windows.net.To connect to a read-only replica in the secondary location, use ApplicationIntent=ReadOnly and <fog-name>.secondary.<zone_id>.database.windows.net.

Préparation à une détérioration des performancesPreparing for performance degradation

Une application Azure classique fait appel à plusieurs services Azure et inclut plusieurs composants.A typical Azure application uses multiple Azure services and consists of multiple components. Le basculement automatique du groupe de basculement est déclenché en fonction de l’état des seuls composants Azure SQL.The automated failover of the failover group is triggered based on the state the Azure SQL components alone. Il peut arriver que les autres services Azure de la région primaire ne soient pas affectés par la panne et que leurs composants soient toujours disponibles dans cette région.Other Azure services in the primary region may not be affected by the outage and their components may still be available in that region. Une fois que les bases de données primaires ont basculé vers la région secondaire, la latence entre les composants dépendants peut augmenter.Once the primary databases switch to the secondary region, the latency between the dependent components may increase. Pour éviter les conséquences négatives d’une latence plus élevée sur les performances de l’application, vérifiez que tous les composants de l’application sont redondants dans la région secondaire et basculez les composants de l’application en même temps que la base de données.To avoid the impact of higher latency on the application's performance, ensure the redundancy of all the application's components in the secondary region and fail over application components together with the database. Au moment de la configuration, suivez les instructions de sécurité réseau pour garantir la connectivité à la base de données dans la région secondaire.At configuration time, follow network security guidelines to ensure connectivity to the database in the secondary region.

Préparation à une perte de donnéesPreparing for data loss

Si une panne est détectée, un basculement en lecture-écriture est déclenché dans le cas où il n’y a à notre connaissance pas de perte de données.If an outage is detected, a read-write failover is triggered if there is zero data loss, to the best of our knowledge. Dans le cas contraire, le basculement est différé pendant la période que vous spécifiez à l’aide du paramètre GracePeriodWithDataLossHours.Otherwise, failover is deferred for the period you specify using GracePeriodWithDataLossHours. Si vous avez spécifié GracePeriodWithDataLossHours, attendez-vous à une perte de données.If you specified GracePeriodWithDataLossHours, be prepared for data loss. En général, en cas de panne, Azure favorise la disponibilité.In general, during outages, Azure favors availability. Si vous ne pouvez pas vous permettre de perdre des données, veillez à définir dans le paramètre GracePeriodWithDataLossHours un nombre suffisamment grand (par exemple, 24 heures), ou désactivez le basculement automatique.If you cannot afford data loss, make sure to set GracePeriodWithDataLossHours to a sufficiently large number, such as 24 hours, or disable automatic failover.

La mise à jour DNS de l’écouteur en lecture-écriture se produit immédiatement après que le basculement est initié.The DNS update of the read-write listener will happen immediately after the failover is initiated. Cette opération n’entraîne aucune perte de données.This operation will not result in data loss. Toutefois, le processus de basculement des rôles des bases de données peut prendre jusqu’à 5 minutes dans des conditions normales.However, the process of switching database roles can take up to 5 minutes under normal conditions. En attendant, certaines bases de données de la nouvelle instance principale resteront en lecture seule.Until it is completed, some databases in the new primary instance will still be read-only. Si un basculement est initié à l’aide de PowerShell, l’opération permettant de basculer le rôle de réplica principal est synchrone.If a failover is initiated using PowerShell, the operation to switch the primary replica role is synchronous. S’il est initié à l’aide du portail Azure, l’interface utilisateur indiquera la progression.If it is initiated using the Azure portal, the UI will indicate completion status. S’il est démarré à l’aide de l’API REST, utilisez le mécanisme d’interrogation standard d’Azure Resource Manager pour en surveiller la progression.If it is initiated using the REST API, use standard Azure Resource Manager’s polling mechanism to monitor for completion.

Important

Utilisez le basculement de groupe manuel pour redéplacer les bases de données primaires à leur emplacement d’origine.Use manual group failover to move primaries back to the original location. Lorsque la panne ayant provoqué le basculement est résolue, vous pouvez déplacer vos bases de données primaires vers leur emplacement d’origine.When the outage that caused the failover is mitigated, you can move your primary databases to the original location. Pour ce faire, vous devez effectuer le basculement manuel du groupe.To do that you should initiate the manual failover of the group.

Changement de la région secondaire du groupe de basculementChanging secondary region of the failover group

Supposons que l’instance A est l’instance principale, que l’instance B est l’instance secondaire existante et que l’instance C est la nouvelle instance secondaire dans la troisième région.Let's assume that instance A is the primary instance, instance B is the existing secondary instance, and instance C is the new secondary instance in the third region. Pour faire la transition, suivez ces étapes :To make the transition, follow these steps:

  1. Créez l’instance C avec la même taille que A et dans la même zone DNS.Create instance C with same size as A and in the same DNS zone.
  2. Supprimez le groupe de basculement entre les instances A et B. À ce stade, les connexions échouent, car les alias SQL des écouteurs du groupe de basculement ont été supprimés et la passerelle ne reconnaît pas le nom du groupe de basculement.Delete the failover group between instances A and B. At this point the logins will be failing because the SQL aliases for the failover group listeners have been deleted and the gateway will not recognize the failover group name. Les bases de données secondaires sont déconnectées des bases de données primaires et deviennent des bases de données en lecture-écriture.The secondary databases will be disconnected from the primaries and will become read-write databases.
  3. Créez un groupe de basculement avec le même nom entre l’instance A et l’instance C. Suivez les instructions du didacticiel relatif au groupe de basculement avec SQL Managed Instance.Create a failover group with the same name between instance A and C. Follow the instructions in failover group with SQL Managed Instance tutorial. Il s’agit d’une opération de taille de données qui se termine dès lors que toutes les bases de données de l’instance A ont été amorcées et synchronisées.This is a size-of-data operation and will complete when all databases from instance A are seeded and synchronized.
  4. Si vous n’en avez plus besoin, supprimez l’instance B pour éviter des frais inutiles.Delete instance B if not needed to avoid unnecessary charges.

Notes

Après l’étape 2 et tant que l’étape 3 n’est par terminée, les bases de données de l’instance A restent non protégées contre une défaillance irrémédiable de l’instance A.After step 2 and until step 3 is completed the databases in instance A will remain unprotected from a catastrophic failure of instance A.

Changement de la région primaire du groupe de basculementChanging primary region of the failover group

Supposons que l’instance A est l’instance principale, que l’instance B est l’instance secondaire existante et que l’instance C est la nouvelle instance principale dans la troisième région.Let's assume instance A is the primary instance, instance B is the existing secondary instance, and instance C is the new primary instance in the third region. Pour faire la transition, suivez ces étapes :To make the transition, follow these steps:

  1. Créez l’instance C avec la même taille que B et dans la même zone DNS.Create instance C with same size as B and in the same DNS zone.
  2. Connectez-vous à l’instance B et basculez manuellement pour passer de l’instance principale à l’instance B. L’instance A devient automatiquement la nouvelle instance secondaire.Connect to instance B and manually failover to switch the primary instance to B. Instance A will become the new secondary instance automatically.
  3. Supprimez le groupe de basculement entre les instances A et B. À ce stade, les connexions échouent, car les alias SQL des écouteurs du groupe de basculement ont été supprimés et la passerelle ne reconnaît pas le nom du groupe de basculement.Delete the failover group between instances A and B. At this point the logins will be failing because the SQL aliases for the failover group listeners have been deleted and the gateway will not recognize the failover group name. Les bases de données secondaires sont déconnectées des bases de données primaires et deviennent des bases de données en lecture-écriture.The secondary databases will be disconnected from the primaries and will become read-write databases.
  4. Créez un groupe de basculement avec le même nom entre l’instance A et l’instance C. Suivez les instructions du tutoriel Groupe de basculement avec instance gérée.Create a failover group with the same name between instance A and C. Follow the instructions in the failover group with managed instance tutorial. Il s’agit d’une opération de taille de données qui se termine dès lors que toutes les bases de données de l’instance A ont été amorcées et synchronisées.This is a size-of-data operation and will complete when all databases from instance A are seeded and synchronized.
  5. Si vous n’en avez plus besoin, supprimez l’instance A pour éviter des frais inutiles.Delete instance A if not needed to avoid unnecessary charges.

Attention

Après l’étape 3 et tant que l’étape 4 n’est par terminée, les bases de données de l’instance A restent non protégées contre une défaillance irrémédiable de l’instance A.After step 3 and until step 4 is completed the databases in instance A will remain unprotected from a catastrophic failure of instance A.

Important

Une fois le groupe de basculement supprimé, les enregistrements DNS des points de terminaison de l’écouteur sont également supprimés.When the failover group is deleted, the DNS records for the listener endpoints are also deleted. À ce stade, il n’est pas entièrement exclu que quelqu’un d’autre crée un groupe de basculement ou un alias de serveur sous le même nom, ce qui vous empêchera de l’utiliser à nouveau.At that point, there is a non-zero probability of somebody else creating a failover group or server alias with the same name, which will prevent you from using it again. Pour limiter ce risque, évitez d’utiliser des noms de groupe de basculement génériques.To minimize the risk, don't use generic failover group names.

Activer les scénarios dépendant des objets des bases de données systèmeEnable scenarios dependent on objects from the system databases

Les bases de données système ne sont pas répliquées vers l’instance secondaire dans un groupe de basculement.System databases are not replicated to the secondary instance in a failover group. Pour activer les scénarios dépendant d’objets des bases de données système, assurez-vous de créer ces objets sur l’instance secondaire.To enable scenarios that depend on objects from the system databases, on the secondary instance, make sure to create the same objects on the secondary. Par exemple, si vous envisagez d’utiliser les mêmes connexions sur l’instance secondaire, veillez à les créer avec un ID de sécurité identique.For example, if you plan to use the same logins on the secondary instance, make sure to create them with the identical SID.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Groupes de basculement et sécurité réseauFailover groups and network security

Pour certaines applications, les règles de sécurité nécessitent que l’accès réseau à la couche Données soit limité à un ou plusieurs composants comme une machine virtuelle, un service web, etc. Cette exigence présente quelques défis pour la conception de la continuité d’activité et l’utilisation des groupes de basculement.For some applications the security rules require that the network access to the data tier is restricted to a specific component or components such as a VM, web service etc. This requirement presents some challenges for business continuity design and the use of the failover groups. Tenez compte des options suivantes lors de l’implémentation d’un accès restreint.Consider the following options when implementing such restricted access.

Utilisation de groupes de basculement et de règles de réseau virtuelUsing failover groups and virtual network rules

Si vous utilisez des règles et points de terminaison de service de réseau virtuel pour restreindre l’accès à votre base de données dans SQL Database ou SQL Managed Instance, n’oubliez pas que chaque point de terminaison de service de réseau virtuel s’applique à une seule région Azure.If you are using Virtual Network service endpoints and rules to restrict access to your database in SQL Database or SQL Managed Instance, be aware that each virtual network service endpoint applies to only one Azure region. Le point de terminaison ne permet pas à d’autres régions d’accepter les communications provenant du sous-réseau.The endpoint does not enable other regions to accept communication from the subnet. Par conséquent, seules les applications client déployées dans la même région peuvent se connecter à la base de données primaire.Therefore, only the client applications deployed in the same region can connect to the primary database. Comme le basculement entraîne la redirection des sessions du client SQL Database vers un serveur dans une autre région (secondaire), ces sessions échouent si elles proviennent d’un client situé en dehors de cette région.Since the failover results in the SQL Database client sessions being rerouted to a server in a different (secondary) region, these sessions will fail if originated from a client outside of that region. Pour cette raison, la stratégie de basculement automatique ne peut pas être activée si les instances ou serveurs participants sont inclus dans les règles de réseau virtuel.For that reason, the automatic failover policy cannot be enabled if the participating servers or instances are included in the Virtual Network rules. Pour prendre en charge le basculement manuel, effectuez les étapes suivantes :To support manual failover, follow these steps:

  1. Provisionnez les copies redondantes des composants front-end de votre application (service web, machines virtuelles, etc.) dans la région secondaireProvision the redundant copies of the front-end components of your application (web service, virtual machines etc.) in the secondary region
  2. Configurez les règles de réseau virtuel individuellement pour les serveurs primaire et secondaireConfigure the virtual network rules individually for primary and secondary server
  3. Activez le basculement frontend à l’aide d’une configuration Traffic ManagerEnable the front-end failover using a Traffic manager configuration
  4. Lancez un basculement manuel quand la panne est détectée.Initiate manual failover when the outage is detected. Cette option est optimisée pour les applications qui requièrent une latence constante entre le frontend et la couche Données, et prend en charge la récupération quand le frontend et/ou la couche Données sont affectés par la panne.This option is optimized for the applications that require consistent latency between the front-end and the data tier and supports recovery when either front end, data tier or both are impacted by the outage.

Notes

Si vous utilisez l’écouteur en lecture seule pour équilibrer une charge de travail en lecture seule, vérifiez que cette charge de travail est exécutée dans une machine virtuelle ou une autre ressource dans la région secondaire pour qu’elle puisse se connecter à la base de données secondaire.If you are using the read-only listener to load-balance a read-only workload, make sure that this workload is executed in a VM or other resource in the secondary region so it can connect to the secondary database.

Utiliser des groupes de basculement et des règles de pare-feuUse failover groups and firewall rules

Si votre plan de continuité d’activité nécessite un basculement à l’aide de groupes avec basculement automatique, vous pouvez restreindre l’accès à votre base de données dans SQL Database, à l’aide des règles de pare-feu classiques.If your business continuity plan requires failover using groups with automatic failover, you can restrict access to your database in SQL Database by using the traditional firewall rules. Pour prendre en charge le basculement automatique, effectuez les étapes suivantes :To support automatic failover, follow these steps:

  1. Créez une adresse IP publique.Create a public IP
  2. Créez un équilibreur de charge public et affectez-lui l’adresse IP publique.Create a public load balancer and assign the public IP to it.
  3. Créez un réseau virtuel et les machines virtuelles pour vos composants frontend.Create a virtual network and the virtual machines for your front-end components
  4. Créez un groupe de sécurité réseau et configurez les connexions entrantes.Create network security group and configure inbound connections.
  5. Vérifiez que les connexions sortantes sont ouvertes pour Azure SQL Database à l’aide de la balise de service « Sql ».Ensure that the outbound connections are open to Azure SQL Database by using ‘Sql’ service tag.
  6. Créez une règle de pare-feu SQL Database pour autoriser le trafic entrant à partir de l’adresse IP publique que vous créez à l’étape 1.Create a SQL Database firewall rule to allow inbound traffic from the public IP address you create in step 1.

Pour plus d’informations sur la configuration de l’accès sortant et l’adresse IP à utiliser dans les règles de pare-feu, voir Connexions sortantes de l’équilibreur de charge.For more information on how to configure outbound access and what IP to use in the firewall rules, see Load balancer outbound connections.

La configuration ci-dessus garantit que le basculement automatique ne bloque pas les connexions à partir des composants frontend et part du principe que l’application peut tolérer la plus longue latence entre le frontend et la couche Données.The above configuration will ensure that the automatic failover will not block connections from the front-end components and assumes that the application can tolerate the longer latency between the front end and the data tier.

Important

Pour garantir la continuité d’activité en cas de pannes régionales, vous devez vérifier la redondance géographique pour les composants frontend et les bases de données.To guarantee business continuity for regional outages you must ensure geographic redundancy for both front-end components and the databases.

Activation de la géoréplication entre les instances gérées et leurs réseaux virtuelsEnabling geo-replication between managed instances and their VNets

Lorsque vous configurez un groupe de basculement entre les instances SQL Managed Instance primaire et secondaire dans deux régions différentes, chaque instance est isolée et utilise un réseau virtuel indépendant.When you set up a failover group between primary and secondary SQL Managed Instances in two different regions, each instance is isolated using an independent virtual network. Pour autoriser le trafic de réplication entre ces réseaux virtuels, vérifiez que les conditions préalables suivantes sont satisfaites :To allow replication traffic between these VNets ensure these prerequisites are met:

  • Les deux instances SQL Managed Instance doivent se trouver dans différentes régions Azure.The two instances of SQL Managed Instance need to be in different Azure regions.

  • Ces deux instances doivent avoir le même niveau de service et la même capacité de stockage.The two instances of SQL Managed Instance need to be the same service tier, and have the same storage size.

  • Votre instance SQL Managed Instance secondaire doit être vide (aucune base de données utilisateur).Your secondary instance of SQL Managed Instance must be empty (no user databases).

  • Les réseaux virtuels utilisés par les instances SQL Managed Instance doivent être connectés via une passerelle VPN ou Express Route.The virtual networks used by the instances of SQL Managed Instance need to be connected through a VPN Gateway or Express Route. Lorsque deux réseaux virtuels se connectent via un réseau local, assurez-vous qu’il n’existe pas de ports de blocage de règle de pare-feu 5022 et 11000-11999.When two virtual networks connect through an on-premises network, ensure there is no firewall rule blocking ports 5022, and 11000-11999. L’appairage de réseaux virtuels mondiaux est pris en charge avec la limitation décrite dans la note ci-dessous.Global VNet Peering is supported with the limitation described in the note below.

    Important

    Le 22/09/2020, nous avons annoncé l’appairage de réseaux virtuels mondiaux pour les clusters virtuels nouvellement créés.On 9/22/2020 we announced global virtual network peering for newly created virtual clusters. Cela signifie que l’appairage de réseaux virtuels mondiaux est pris en charge pour les instances managées SQL créées dans des sous-réseaux vides après la date d’annonce, ainsi que pour toutes les instances managées ultérieures, créées dans ces sous-réseaux.That means that global virtual network peering is supported for SQL Managed Instances created in empty subnets after the announcement date, as well for all the subsequent managed instances created in those subnets. Pour toutes les autres instances managées SQL, la prise en charge de l’appairage est limitée aux réseaux de la même région en raison des contraintes de l’appairage de réseaux virtuels mondiaux.For all the other SQL Managed Instances peering support is limited to the networks in the same region due to the constraints of global virtual network peering. Consultez également la section appropriée de l’article Forum Aux Questions sur les réseaux virtuel Azure pour plus d’informations.See also the relevant section of the Azure Virtual Networks frequently asked questions article for more details.

  • Les adresses IP des deux réseaux virtuels SQL Managed Instance ne peuvent pas se chevaucher.The two SQL Managed Instance VNets cannot have overlapping IP addresses.

  • Vous devez configurer vos groupes de sécurité réseau (NSG) de telle sorte que les ports 5022 et la plage 11000 à 12000 soient ouverts en entrée et en sortie pour les connexions provenant du sous-réseau de l’autre instance gérée.You need to set up your Network Security Groups (NSG) such that ports 5022 and the range 11000~12000 are open inbound and outbound for connections from the subnet of the other managed instance. Ceci est destiné à autoriser le trafic de réplication entre les instances.This is to allow replication traffic between the instances.

    Important

    La configuration incorrecte des règles de groupes de sécurité réseau bloque les opérations de copie sur les bases de données.Misconfigured NSG security rules leads to stuck database copy operations.

  • L’instance SQL Managed Instance secondaire est configurée avec l’ID de zone DNS approprié.The secondary SQL Managed Instance is configured with the correct DNS zone ID. La zone DNS est une propriété d’une instance SQL Managed Instance et d’un cluster virtuel sous-jacent, et son ID est inclus dans l’adresse du nom d’hôte.DNS zone is a property of a SQL Managed Instance and underlying virtual cluster, and its ID is included in the host name address. L’ID de zone est généré sous forme de chaîne aléatoire lors de la création de la première instance SQL Managed Instance de chaque réseau virtuel. De plus, le même ID est attribué à toutes les autres instances dans le même sous-réseau.The zone ID is generated as a random string when the first SQL Managed Instance is created in each VNet and the same ID is assigned to all other instances in the same subnet. Une fois attribué, la zone DNS ne peut pas être modifiée.Once assigned, the DNS zone cannot be modified. Les instances SQL Managed Instance d’un même groupe de basculement doivent partager la zone DNS.SQL Managed Instances included in the same failover group must share the DNS zone. Pour cela, vous devez transmettre l’ID de zone de l’instance principale en tant que valeur du paramètre DnsZonePartner lors de la création de l’instance secondaire.You accomplish this by passing the primary instance's zone ID as the value of DnsZonePartner parameter when creating the secondary instance.

    Notes

    Pour accéder à un didacticiel détaillé sur la configuration des groupes de basculement avec SQL Managed Instance, voir Add a SQL Managed Instance to a failover group (Ajouter une instance SQL Managed Instance à un groupe de basculement).For a detailed tutorial on configuring failover groups with SQL Managed Instance, see add a SQL Managed Instance to a failover group.

Mise à niveau ou rétrogradation d’une base de données primaireUpgrading or downgrading a primary database

Vous pouvez augmenter ou diminuer la taille de calcul d’une base de données primaire (au sein du même niveau de service, mais pas entre les niveaux Usage général et Critique pour l’entreprise) sans déconnecter les bases de données secondaires.You can upgrade or downgrade a primary database to a different compute size (within the same service tier, not between General Purpose and Business Critical) without disconnecting any secondary databases. Lors d’une mise à niveau, nous vous recommandons de mettre à niveau toutes les bases de données secondaires dans un premier temps, avant de mettre à niveau la base de données primaire.When upgrading, we recommend that you upgrade all of the secondary databases first, and then upgrade the primary. Lors du passage à une version antérieure, inversez l’ordre : faites tout d’abord passer la base de données primaire à une version antérieure, puis toutes les bases de données secondaires dans un second temps.When downgrading, reverse the order: downgrade the primary first, and then downgrade all of the secondary databases. Lorsque vous passez la base de données à un niveau de service supérieur ou inférieur, cette recommandation est appliquée.When you upgrade or downgrade the database to a different service tier, this recommendation is enforced.

Cette séquence est recommandée dans le but spécifique d’éviter le problème de surcharge des bases de données secondaires avec une référence SKU inférieure. Celles-ci doivent alors être alimentées à nouveau lors de la mise à niveau ou du passage à une version antérieure.This sequence is recommended specifically to avoid the problem where the secondary at a lower SKU gets overloaded and must be re-seeded during an upgrade or downgrade process. Vous pouvez également éviter le problème en attribuant un accès en lecture seule à la base de données primaire, ce qui peut cependant nuire à toutes les charges de travail en lecture-écriture qui y sont associées.You could also avoid the problem by making the primary read-only, at the expense of impacting all read-write workloads against the primary.

Notes

Si vous avez créé une base de données secondaire dans le cadre de la configuration des groupes de basculement, il n’est pas conseillé de faire passer cette base de données à une version antérieure.If you created a secondary database as part of the failover group configuration it is not recommended to downgrade the secondary database. En effet, votre couche Données pourrait manquer de capacité pour traiter votre charge de travail normale après l’activation du basculement.This is to ensure your data tier has sufficient capacity to process your regular workload after failover is activated.

Prévention de la perte de données critiquesPreventing the loss of critical data

En raison de la latence élevée des réseaux étendus, la copie continue utilise un mécanisme de réplication asynchrone.Due to the high latency of wide area networks, continuous copy uses an asynchronous replication mechanism. La perte de certaines données reste donc inévitable en cas de défaillance.Asynchronous replication makes some data loss unavoidable if a failure occurs. Or, pour certaines applications, une perte de données est inacceptable.However, some applications may require no data loss. Pour protéger ces mises à jour critiques, un développeur d’applications peut appeler la procédure système sp_wait_for_database_copy_sync immédiatement après la validation de la transaction.To protect these critical updates, an application developer can call the sp_wait_for_database_copy_sync system procedure immediately after committing the transaction. L’appel de sp_wait_for_database_copy_sync bloque le thread appelant jusqu’à ce que la dernière transaction validée ait été transmise à la base de données secondaire.Calling sp_wait_for_database_copy_sync blocks the calling thread until the last committed transaction has been transmitted to the secondary database. Toutefois, il n’attend pas que les transactions transmises soient relues et validées sur la base de données secondaire.However, it does not wait for the transmitted transactions to be replayed and committed on the secondary. sp_wait_for_database_copy_sync est limité à un lien de copie continue spécifique.sp_wait_for_database_copy_sync is scoped to a specific continuous copy link. Tout utilisateur disposant de droits de connexion à la base de données primaire peut appeler cette procédure.Any user with the connection rights to the primary database can call this procedure.

Notes

sp_wait_for_database_copy_sync empêche la perte de données après un basculement, mais il ne garantit pas la synchronisation complète pour l’accès en lecture.sp_wait_for_database_copy_sync prevents data loss after failover, but does not guarantee full synchronization for read access. Le délai causé par un appel de procédure sp_wait_for_database_copy_sync peut être significatif et dépend de la taille du journal des transactions au moment de l’appel.The delay caused by a sp_wait_for_database_copy_sync procedure call can be significant and depends on the size of the transaction log at the time of the call.

Groupes de basculement et limite de restauration dans le tempsFailover groups and point-in-time restore

Pour plus d’informations sur l’utilisation de la limite de restauration dans le temps avec les groupes de basculement, voir Limite de restauration dans le temps.For information about using point-in-time restore with failover groups, see Point in Time Recovery (PITR).

Limitations des groupes de basculementLimitations of failover groups

Notez les limitations suivantes :Be aware of the following limitations:

  • Il n’est pas possible de créer des groupes de basculement entre deux serveurs ou instances au sein des mêmes régions Azure.Failover groups cannot be created between two servers or instances in the same Azure regions.
  • Les groupes de basculement ne peuvent pas être renommés.Failover groups cannot be renamed. Vous devrez supprimer le groupe puis le recréer sous un autre nom.You will need to delete the group and re-create it with a different name.
  • Le renommage d’une base de données n’est pas pris en charge pour les instances situées dans un groupe de basculement.Database rename is not supported for instances in failover group. Vous devez supprimer temporairement le groupe de basculement pour pouvoir renommer une base de données.You will need to temporarily delete failover group to be able to rename a database.
  • Les bases de données système ne sont pas répliquées vers l’instance secondaire dans un groupe de basculement.System databases are not replicated to the secondary instance in a failover group. Par conséquent, les scénarios qui dépendent des objets des bases de données système ne peuvent pas être appliqués sur l’instance secondaire, à moins que ces objets ne soient créés manuellement sur cette dernière.Therefore, scenarios that depend on objects from the system databases will be impossible on the secondary instance unless the objects are manually created on the secondary.

Gestion par programmation des groupes de basculementProgrammatically managing failover groups

Comme indiqué plus haut, les groupes de basculement automatique et la géo-réplication active peuvent aussi être gérés par programme à l’aide d’Azure PowerShell et de l’API REST.As discussed previously, auto-failover groups and active geo-replication can also be managed programmatically using Azure PowerShell and the REST API. Les tableaux ci-dessous décrivent l’ensemble des commandes disponibles.The following tables describe the set of commands available. La géoréplication active comprend un ensemble d’API Azure Resource Manager pour la gestion, notamment l’API REST Azure SQL Database et les applets de commande Azure PowerShell.Active geo-replication includes a set of Azure Resource Manager APIs for management, including the Azure SQL Database REST API and Azure PowerShell cmdlets. Ces API nécessitent l’utilisation de groupes de ressources et la prise en charge du contrôle d’accès en fonction du rôle (RBAC).These APIs require the use of resource groups and support Azure role-based access control (Azure RBAC). Pour plus d’informations sur l’implémentation de rôles d’accès, consultez la page sur le contrôle d’accès en fonction du rôle Azure (RBAC Azure).For more information on how to implement access roles, see Azure role-based access control (Azure RBAC).

Gérer un basculement SQL DatabaseManage SQL Database failover

Applet de commandeCmdlet DescriptionDescription
New-AzSqlDatabaseFailoverGroupNew-AzSqlDatabaseFailoverGroup Cette commande crée un groupe de basculement et l’enregistre dans les serveurs primaire et secondaireThis command creates a failover group and registers it on both primary and secondary servers
Remove-AzSqlDatabaseFailoverGroupRemove-AzSqlDatabaseFailoverGroup Supprime un groupe de basculement du serveurRemoves a failover group from the server
Get-AzSqlDatabaseFailoverGroupGet-AzSqlDatabaseFailoverGroup Récupère la configuration d’un groupe de basculementRetrieves a failover group's configuration
Set-AzSqlDatabaseFailoverGroupSet-AzSqlDatabaseFailoverGroup Modifie la configuration d’un groupe de basculementModifies configuration of a failover group
Switch-AzSqlDatabaseFailoverGroupSwitch-AzSqlDatabaseFailoverGroup Déclenche le basculement d’un groupe de basculement vers le serveur secondaireTriggers failover of a failover group to the secondary server
Add-AzSqlDatabaseToFailoverGroupAdd-AzSqlDatabaseToFailoverGroup Ajoute une ou plusieurs bases de données à un groupe de basculementAdds one or more databases to a failover group

Gérer un basculement SQL Managed InstanceManage SQL Managed Instance failover

Applet de commandeCmdlet DescriptionDescription
New-AzSqlDatabaseInstanceFailoverGroupNew-AzSqlDatabaseInstanceFailoverGroup Cette commande crée un groupe de basculement et l’enregistre dans les instances principale et secondaireThis command creates a failover group and registers it on both primary and secondary instances
Set-AzSqlDatabaseInstanceFailoverGroupSet-AzSqlDatabaseInstanceFailoverGroup Modifie la configuration d’un groupe de basculementModifies configuration of a failover group
Get-AzSqlDatabaseInstanceFailoverGroupGet-AzSqlDatabaseInstanceFailoverGroup Récupère la configuration d’un groupe de basculementRetrieves a failover group's configuration
Switch-AzSqlDatabaseInstanceFailoverGroupSwitch-AzSqlDatabaseInstanceFailoverGroup Déclenche le basculement d’un groupe de basculement vers l’instance secondaireTriggers failover of a failover group to the secondary instance
Remove-AzSqlDatabaseInstanceFailoverGroupRemove-AzSqlDatabaseInstanceFailoverGroup Supprime un groupe de basculementRemoves a failover group

Étapes suivantesNext steps