Décrire la haute disponibilité et la récupération d’urgence pour les déploiements PaaS
PaaS est différent en matière de disponibilité, car vous ne pouvez configurer que les options fournies par Azure.
Pour les options basées sur SQL Server d’Azure SQL Database et d’Azure SQL Managed Instance, les options sont la géoréplication active (Azure SQL Database uniquement) et les groupes de basculement automatique (Azure SQL Database ou Azure SQL Managed Instance).
Azure SQL Database a un contrat de niveau de service, qui garantit la disponibilité de 99,99, ce qui signifie qu’aucun temps d’arrêt ne doit être rencontré. Si un problème survient au niveau du nœud, tel qu'une défaillance matérielle, un mécanisme de basculement intégré s'active. Toutes les modifications transactionnelles apportées à la base de données sont écrites de manière synchrone dans le stockage lors de la validation. En cas d’interruption au niveau du nœud, le serveur de base de données crée automatiquement un autre nœud et attache le stockage de données.
Du point de vue de l’application, vous devez coder la logique de réessai nécessaire car toutes les connexions sont interrompues lors de la mise en service d'un nouveau nœud et toutes les transactions en cours sont perdues. Ce processus est considéré comme une bonne pratique pour les applications cloud, celles-ci devant être conçues pour gérer des défaillances temporaires.
Azure SQL Database et Azure SQL Managed Instance offrent la possibilité de créer des réplicas en lecture. Ces répliques peuvent être utilisées pour des activités telles que la création de rapports, ce qui permet de décharger la charge de travail de la base de données primaire. En outre, les réplicas en lecture améliorent la disponibilité en se trouvant dans différentes régions, ce qui garantit que vos données restent accessibles même si une région rencontre un problème.
Disponibilité des bases de données
Dans Azure SQL Database et Azure SQL Managed Instance, vous ne pouvez pas définir l’état d’une base de données sur OFFLINE et sur EMERGENCY. Si vous y réfléchissez, OFFLINE n’a pas de sens, car vous ne pouvez pas joindre de bases de données. Étant donné que vous ne pouvez pas utiliser EMERGENCY, vous ne pouvez pas effectuer de réparation en mode d’urgence. Vous ne devriez toutefois pas en avoir besoin, car Azure gère et tient à jour le service. D’autres fonctionnalités, comme RESTRICTED_USER et la connexion d’administration dédiée (DAC), sont autorisées dans Azure SQL Database.
La récupération de base de données accélérée (ADR) est intégrée au moteur. Avec la récupération de base de données accélérée, le journal des transactions est tronqué de façon agressive et un magasin de versions persistantes est utilisé. Cette technologie vous permet d’effectuer instantanément une restauration de transaction, résolvant ainsi un problème bien connu avec les transactions durables. Cela permet également Azure SQL de récupérer des bases de données rapidement.
Dans Azure SQL Database et Azure SQL Managed Instance, la récupération de base de données accélérée augmente considérablement la disponibilité générale des bases de données. Il s’agit d’un facteur important dans le contrat SLA. Pour ces raisons, la récupération de base de données accélérée est activée par défaut et ne peut pas être désactivée.
Cohérence des bases de données
Comme vous l’avez appris au début de ce module, plusieurs copies de vos données et de vos sauvegardes existent à la fois localement et dans différentes régions. Régulièrement, des vérifications d'intégrité des opérations de sauvegarde et de restauration sont effectuées. La détection des écritures perdues et des lectures obsolètes est également en place. Vous pouvez exécuter DBCC CHECKDB (pas de réparation) et CHECKSUM est activé par défaut. Dans le back-end, la réparation automatique des pages se produit dès que possible, et il existe un monitoring des alertes d’erreur d’intégrité des données. S’il n’y a aucun impact, la réparation sans notification se produit. En cas d’impact, une notification proactive est fournie.