Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La continuité d’activité dans Azure Database pour PostgreSQL fait référence aux mécanismes, stratégies et procédures qui permettent à votre entreprise de continuer à fonctionner face à une interruption, en particulier à son infrastructure informatique. Dans la plupart des cas, Azure Database pour PostgreSQL gère les événements perturbateurs qui peuvent se produire dans l’environnement cloud et maintient vos applications et processus métier en cours d’exécution. Toutefois, certains événements ne peuvent pas être gérés automatiquement, tels que :
- Un utilisateur supprime ou met à jour accidentellement une ligne dans une table.
- Un tremblement de terre entraîne une panne de courant et désactive temporairement une zone de disponibilité ou une région.
- Mise à jour corrective de base de données requise pour corriger un bogue ou un problème de sécurité.
Azure Database pour PostgreSQL fournit des fonctionnalités qui protègent les données et atténuent les temps d’arrêt de vos bases de données stratégiques pendant les événements de temps d’arrêt planifiés et non planifiés. Reposant sur l’infrastructure Azure qui offre une résilience et une disponibilité robustes, Azure Database pour PostgreSQL dispose de fonctionnalités de continuité d’activité qui fournissent une autre protection contre les pannes, répondent aux exigences de temps de récupération et réduisent l’exposition aux pertes de données. Lorsque vous concevez vos applications, tenez compte de la tolérance de temps d’arrêt - l’objectif de temps de récupération (RTO) et l’exposition à la perte de données - l’objectif de point de récupération (RPO). Par exemple, votre base de données vitale pour l’entreprise impose une durée de bon fonctionnement plus stricte qu’une base de données de test.
Le tableau suivant illustre les fonctionnalités qui Azure Database pour PostgreSQL offres.
| Fonctionnalité | Description | Considérations |
|---|---|---|
| Sauvegardes automatiques | Une instance de serveur flexible Azure Database pour PostgreSQL effectue automatiquement des sauvegardes quotidiennes de vos fichiers de base de données et sauvegarde en continu les journaux des transactions. Vous pouvez conserver les sauvegardes de 7 jours jusqu’à 35 jours. Vous pouvez restaurer votre serveur de base de données à n’importe quel point dans le temps au cours de la période de conservation de votre sauvegarde. Le RTO dépend du volume des données à restaurer ainsi que du temps nécessaire à la récupération des journaux. Il peut s’agir de quelques minutes jusqu’à 12 heures. Pour plus d’informations, consultez Concepts – Sauvegarde et restauration. | Les données de sauvegarde restent dans la région. |
| Haute disponibilité redondante interzone | Vous pouvez déployer une instance de serveur flexible Azure Database pour PostgreSQL avec une configuration haute disponibilité redondante interzone où les serveurs principaux et de secours sont déployés dans deux zones de disponibilité différentes au sein d’une région. Cette configuration haute disponibilité protège vos bases de données contre les défaillances au niveau de la zone et permet également de réduire les temps d’arrêt de l’application pendant les événements de temps d’arrêt planifiés et non planifiés. Les données du serveur primaire sont répliquées vers le serveur réplica de secours en mode synchrone. En cas d’interruption du serveur primaire, le serveur est automatiquement basculé vers le réplica de secours. Dans la plupart des cas, le RTO devrait être inférieur à 120 secondes. Le RPO est supposé être égal à zéro (aucune perte de données). Pour plus d’informations, consultez Concepts - Haute disponibilité. | Prise en charge dans les niveaux de calcul à usage général et à mémoire optimisée. Disponible uniquement dans les régions où plusieurs zones sont disponibles. |
| Haute disponibilité dans la même zone | Vous pouvez déployer une instance de serveur flexible Azure Database pour PostgreSQL avec la même configuration de haute disponibilité de zone où les serveurs principaux et de secours sont déployés dans la même zone de disponibilité dans une région. Cette configuration haute disponibilité protège vos bases de données contre les défaillances au niveau du nœud et permet également de réduire les temps d’arrêt de l’application pendant les événements de temps d’arrêt planifiés et non planifiés. Les données du serveur primaire sont répliquées vers le serveur réplica de secours en mode synchrone. En cas d’interruption du serveur primaire, le serveur est automatiquement basculé vers le réplica de secours. Dans la plupart des cas, le RTO devrait être inférieur à 120 secondes. Le RPO est supposé être égal à zéro (aucune perte de données). Pour plus d’informations, consultez [Concepts – Haute disponibilité]/azure/reliability/reliability-postgresql-flexible-server. | Prise en charge dans les niveaux de calcul à usage général et à mémoire optimisée. |
| Disques managés Premium | Les fichiers de base de données sont stockés dans un stockage managé Premium durable et fiable. Ce stockage fournit une redondance des données avec trois copies du réplica stockés dans une zone de disponibilité avec des fonctionnalités de récupération automatique des données. Pour plus d’informations, consultez la Documentation sur la fonctionnalité Disques managés. | Données stockées dans une zone de disponibilité. |
| Sauvegarde redondante interzone | Les sauvegardes d’instance de serveur flexible Azure Database pour PostgreSQL sont automatiquement stockées en toute sécurité dans un stockage redondant interzone dans une région, si la région prend en charge les zones de disponibilité. Lors d’une défaillance au niveau de la zone où votre serveur est approvisionné et si votre serveur n’est pas configuré avec redondance de zone, vous pouvez toujours restaurer votre base de données à l’aide du dernier point de restauration dans une autre zone. Pour plus d’informations, consultez Concepts – Sauvegarde et restauration. | Applicable uniquement dans les régions où plusieurs zones sont disponibles. |
| Sauvegarde géoredondante | Les sauvegardes d’instance de serveur flexible Azure Database pour PostgreSQL sont copiées dans une région distante. Cette fonctionnalité aide à la situation de récupération d’urgence en cas de panne de la région du serveur principal. | Cette fonctionnalité est actuellement activée dans les régions sélectionnées. Elle accepte un RTO plus long et un RPO plus élevé en fonction de la taille des données à restaurer et de l’ampleur de la récupération à effectuer. |
| Réplica en lecture | Des réplicas en lecture interrégion peuvent être déployés pour protéger vos bases de données contre les défaillances au niveau de la région. Les répliques en lecture sont mises à jour de manière asynchrone à l'aide de la technologie de réplication physique de PostgreSQL et peuvent présenter un décalage par rapport au serveur principal. Pour en savoir plus, consultez Concepts – Réplicas en lecture. | Prise en charge dans les niveaux de calcul à usage général et à mémoire optimisée. |
Le tableau suivant compare le RTO et le RPO dans un scénario de charge de travail classique :
| Capacité | Burstable | Référence SKU de production (usage général/mémoire optimisée) |
|---|---|---|
| Limite de restauration dans le temps à partir de la sauvegarde | N’importe quel point de restauration dans la période de rétention RTO – Variable RPO < 5 minutes |
N’importe quel point de restauration dans la période de rétention RTO – Variable RPO < 5 minutes |
| Géo-restauration à partir de sauvegardes répliquées géographiquement | RTO – Variable RPO < 1 h |
RTO – Variable RPO < 1 h |
| Réplicas en lecture | Non applicable | RTO – Quelques minutes* RPO - Généralement compris entre 30 secondes et 5 minutes* |
| Disponibilité élevée | Non applicable | RTO < 120 secondes RPO = 0 |
Événements de temps d’arrêt planifiés
Le tableau suivant décrit certains scénarios de maintenance planifiée courants. Ces événements provoquent généralement quelques minutes de temps d’arrêt, mais ils ne provoquent pas de perte de données.
| Scénario | Processus |
|---|---|
| Mise à l’échelle du calcul (initiée par l’utilisateur) | Pendant l’opération de mise à l’échelle du calcul, le processus permet aux points de contrôle actifs de terminer, de vider les connexions clientes, d’annuler toutes les transactions non validées, de détacher le stockage, puis d’arrêter. Le processus provisionne une nouvelle instance de serveur flexible Azure Database pour PostgreSQL avec le même nom de serveur de base de données, mais avec la configuration de calcul mise à l’échelle. Le processus attache le stockage au nouveau serveur et démarre la base de données, qui effectue la récupération si nécessaire avant d’accepter les connexions clientes. |
| Mise à l’échelle du stockage (initiée par l’utilisateur) | Lorsque vous lancez une opération de mise à l’échelle du stockage, le processus permet aux points de contrôle actifs de terminer, de vider les connexions clientes et d’annuler toutes les transactions non validées. Après cela, le processus arrête le serveur. Le processus met à l’échelle le stockage à la taille souhaitée, puis l’attache au nouveau serveur. Le processus effectue une récupération si nécessaire avant d’accepter les connexions clientes. Notez qu’un scale-down de la taille de stockage n’est pas pris en charge. |
| Déploiement de nouveaux logiciels (initiés par Azure) | Le service déploie automatiquement de nouvelles fonctionnalités ou correctifs de bogues dans le cadre de la maintenance planifiée. Vous pouvez planifier le moment où ces activités se produisent. Pour plus d’informations, consultez votre portail. |
| Mises à niveau de version mineure (initiées par Azure) | Le service Azure Database pour PostgreSQL corrige automatiquement la mise à niveau des serveurs de base de données pour la version mineure déterminée par Azure. Cette mise à jour corrective se produit dans le cadre de la maintenance planifiée du service. Le processus redémarre automatiquement le serveur de base de données avec la nouvelle version mineure. Pour plus d’informations, consultez la documentation. Vous pouvez également consulter votre portail. |
Lorsque vous configurez l’instance de serveur flexible Azure Database pour PostgreSQL avec une haute disponibilité, le service effectue d’abord la mise à l’échelle et les opérations de maintenance sur le serveur de secours. Pour plus d’informations, consultez [Concepts – Haute disponibilité]/azure/reliability/reliability-postgresql-flexible-server.
Réduction des temps d’arrêt non planifiés
Des temps d’arrêt non planifiés peuvent se produire suite à des interruptions imprévues, telles qu’une panne matérielle sous-jacente, des problèmes de mise en réseau et des bogues logiciels. Si le serveur de base de données configuré avec une haute disponibilité tombe de façon inattendue, le service active le réplica de secours et les clients peuvent reprendre leurs opérations. Si vous ne configurez pas le serveur avec haute disponibilité, le service provisionne automatiquement un nouveau serveur de base de données en cas d’échec de la tentative de redémarrage. Bien que vous ne puissiez pas éviter les temps d'arrêt non planifiés, Azure Database pour PostgreSQL permet d'atténuer le temps d'arrêt en effectuant automatiquement des opérations de récupération sans nécessiter d'intervention humaine.
Bien que l’équipe d’ingénierie s’efforce continuellement de fournir une haute disponibilité, il existe des moments où Azure Database pour PostgreSQL entraîne une panne qui provoque l’indisponibilité des bases de données et a donc un impact sur votre application. Lorsque la surveillance du service détecte les problèmes qui provoquent des erreurs de connectivité, des échecs ou des problèmes de performances étendus, le service déclare automatiquement une panne pour vous informer.
Panne de service
Si une instance de serveur flexible Azure Database pour PostgreSQL tombe en panne, vous trouverez plus d’informations sur la panne dans les emplacements suivants :
- bannière du portail Azure : si votre abonnement est affecté, les notifications du portail Azure affichent une alerte de panne pour un problème de service.
- Aide + support ou support + résolution des problèmes : lorsque vous créez un ticket de support à partir de l’aide + support ou support + résolution des problèmes, le portail inclut des informations sur les problèmes qui affectent vos ressources. Sélectionnez Afficher les détails sur la panne pour plus d’informations et un résumé de l’impact. La page Nouvelle demande de support inclut également une alerte.
- Intégrité du service : la page Intégrité du service dans le portail Azure contient des informations sur l’état du centre de données Azure globalement. Recherchez « Intégrité du service » dans la barre de recherche dans le portail Azure, puis affichez les problèmes de service dans la catégorie événements actifs. Vous pouvez également afficher l’intégrité des ressources individuelles dans la page Intégrité des ressources de n’importe quelle ressource sous le menu Aide. La capture d’écran suivante de la page Service Health montre des informations sur un problème de service actif en Asie du Sud-Est.
- Notification par e-mail : si vous configurez des alertes, vous recevez une notification par e-mail lorsqu’une panne de service a un impact sur votre abonnement et votre ressource. Les e-mails proviennent de «azure-noreply@microsoft.com ». Le corps de l’e-mail commence par « L’alerte du journal d’activité ... a été déclenchée par un problème de service pour l’abonnement Azure... ». Pour plus d'informations sur les alertes relatives à l'état des services, consultez Recevoir des alertes du journal d'activité via les notifications de service Azure à l'aide du portail Azure.
Important
Comme son nom l’indique, les espaces de table temporaires dans PostgreSQL sont utilisés pour les objets temporaires, tout comme pour d’autres opérations de base de données internes, telles que le tri. Par conséquent, ne créez pas d’objets de schéma utilisateur dans un espace de table temporaire, car la durabilité de ces objets après le redémarrage du serveur, les basculements haute disponibilité et les événements similaires ne sont pas garantis.
Temps d’arrêt non planifié : scénarios d’échec et récupération du service
Le tableau suivant décrit les scénarios d’échec non planifiés courants et le processus de récupération.
| Scénario |
Processus de récupération [Serveurs configurés sans haute disponibilité redondante dans une zone] |
Processus de récupération [Serveurs configurés avec une haute disponibilité redondante dans une zone] |
|---|---|---|
| Panne du serveur de base de données | Si le serveur de base de données tombe en panne, Azure tente de redémarrer le serveur de base de données. Si cette tentative échoue, Azure redémarre le serveur de base de données sur un autre nœud physique. Le temps de récupération (RTO) dépend de différents facteurs, notamment l’activité au moment de l’erreur, comme une transaction volumineuse et le volume de récupération à effectuer pendant le processus de démarrage du serveur de base de données. Les applications qui utilisent les bases de données PostgreSQL doivent détecter et réessayer les connexions supprimées et les transactions ayant échoué. |
Si l’échec du serveur de base de données est détecté, le serveur bascule vers le serveur de secours, ce qui réduit les temps d’arrêt. Pour plus d’informations, consultez [Page Concepts HA]/azure/reliability/reliability-postgresql-flexible-server. Le RTO devrait être de 60 à 120 secondes, sans perte de données. |
| Échec de stockage | Les applications ne voient aucun impact sur les problèmes liés au stockage, tels qu’une défaillance de disque ou une corruption de bloc physique. Étant donné que les données sont stockées en trois copies, l’unité de stockage restante héberge la copie des données. Le bloc de données endommagé est réparé automatiquement, et une nouvelle copie des données est automatiquement créée. | Pour toutes les erreurs rares et non récupérables, comme lorsque l’ensemble du stockage est inaccessible, l’instance de serveur flexible Azure Database pour PostgreSQL bascule vers le réplica de secours pour réduire le temps d’arrêt. Pour plus d’informations, consultez [Page Concepts HA]/azure/reliability/reliability-postgresql-flexible-server. |
| Erreurs logiques ou utilisateur | Pour récupérer des erreurs utilisateur, telles que des tables supprimées accidentellement ou des données incorrectement mises à jour, effectuez une récupération à un point dans le temps (PITR). Lors de l’exécution de l’opération de restauration, spécifiez le point de restauration personnalisé, qui est le moment juste avant l’erreur. Si vous souhaitez restaurer uniquement un sous-ensemble de bases de données ou des tables spécifiques plutôt que toutes les bases de données du serveur de base de données, vous pouvez restaurer le serveur de base de données dans une nouvelle instance, exporter les tables via pg_dump, puis utiliser pg_restore pour restaurer ces tables dans votre base de données. |
Ces erreurs utilisateur ne sont pas couvertes par la haute disponibilité, car toutes les modifications sont répliquées de manière synchrone vers la réplique de secours. Vous devez effectuer une restauration à un instant donné pour récupérer après de telles erreurs. |
| Défaillance de zone de disponibilité | Pour récupérer après une défaillance de zone, effectuez une restauration à un instant donné à l’aide de la sauvegarde et choisissez un point de restauration personnalisé avec l’heure la plus récente afin de restaurer les données les plus récentes. Déployez une nouvelle instance de serveur flexible Azure Database pour PostgreSQL dans une autre zone non affectée. Le temps que prend la restauration dépend de la sauvegarde précédente et du volume des journaux des transactions à récupérer. | Une instance de serveur flexible Azure Database pour PostgreSQL bascule automatiquement vers le serveur de secours dans les 60 à 120 secondes, sans perte de données. Pour plus d’informations, consultez [Page Concepts HA]/azure/reliability/reliability-postgresql-flexible-server. |
| Panne de région | Si votre serveur est configuré avec une sauvegarde géo-redondante, vous pouvez effectuer la géo-restauration dans la région appairée. Azure provisionne et restaure un nouveau serveur à partir des dernières données disponibles qui ont été copiées dans cette région. Vous pouvez également utiliser des réplicas en lecture interrégionaux. En cas de panne dans une région, vous pouvez effectuer une opération de récupération d’urgence en faisant de votre réplica en lecture un serveur en lecture-écriture autonome. Le RPO devrait être de cinq minutes au maximum (perte de données possible), sauf en cas de panne régionale majeure, auquel cas le RPO peut être proche du retard de réplication au moment de la panne. |
Même processus. |
Configurer votre base de données après une récupération suite à une défaillance régionale
- Si vous utilisez la géorestauration ou le géoréplica pour effectuer une récupération à partir d’une panne, assurez-vous que la connectivité au nouveau serveur est correctement configurée afin que la fonction d’application normale puisse reprendre. Suivez les tâches de post-restauration.
- Si vous avez précédemment configuré un paramètre de diagnostic sur le serveur d’origine, veillez à effectuer la même opération sur le serveur cible si nécessaire, comme expliqué dans Configurer et accéder aux journaux d’activité dans Azure Database pour PostgreSQL.
- Pour configurer des alertes de télémétrie, vérifiez que vos paramètres de règle d’alerte existants sont mis à jour pour mapper au nouveau serveur. Pour plus d’informations sur les règles d’alerte, consultez Utiliser le portail Azure pour configurer des alertes sur les métriques pour Azure Database pour PostgreSQL.
Important
Vous pouvez restaurer des serveurs supprimés. Si vous supprimez le serveur, suivez les instructions de restauration d’un serveur supprimé pour récupérer. Utilisez le verrouillage des ressources Azure pour éviter la suppression accidentelle de votre serveur.