Cette page présente les architectures de disponibilité AlloyDB Omni que vous pouvez utiliser pour vous assurer que votre base de données AlloyDB Omni peut être restaurée rapidement, avec peu ou pas de perte de données.
Pour assurer la continuité des activités et minimiser la perte de données, la haute disponibilité et la reprise après sinistre sont des stratégies de protection des données essentielles pour AlloyDB Omni. La haute disponibilité vise à maintenir la disponibilité de la base de données et à minimiser l'objectif de temps de récupération (RTO), tandis que la reprise après sinistre vise à assurer la récupération après des événements catastrophiques et à minimiser l'objectif de point de récupération (RPO).
Le RTO et le RPO sont alignés sur les exigences de l'entreprise et sont définis comme suit :
- Le RTO correspond à la durée maximale pendant laquelle une base de données peut être hors service ou indisponible avant que l'entreprise ne subisse des conséquences inacceptables, comme une perte de revenus ou de productivité.
- Le RPO correspond à la quantité maximale de données qu'une entreprise peut perdre avant que cela n'ait un impact sur ses exigences commerciales. Par exemple, les systèmes d'inventaire qui nécessitent un journal d'audit complet peuvent exiger une absence totale de perte de données.
AlloyDB Omni propose les architectures de référence de disponibilité suivantes, qui offrent des niveaux de disponibilité croissants :
- Disponibilité standard : protège vos données à l'aide de sauvegardes.
- Disponibilité améliorée : protège vos données à l'aide de la réplication zonale dans une région (HA).
- Disponibilité Premium : protège vos données à l'aide de la réplication zonale et régionale (HA et DR).
Mécanismes de disponibilité
Voici les principaux mécanismes qui garantissent la disponibilité :
- Sauvegardes de bases de données
- Réplication de base de données
Sauvegardes de bases de données
Les sauvegardes de bases de données, un aspect fondamental de la protection des données, impliquent la création de copies physiques des fichiers de données de la base de données. Les différents types de sauvegarde (complète, incrémentielle et différentielle) offrent des équilibres différents entre l'objectif de point de récupération (RPO), la taille et la durée de la sauvegarde, et le temps de restauration.
Pour assurer une récupération efficace et minimiser la perte de données en cas de défaillance du système, une stratégie de sauvegarde robuste doit inclure des sauvegardes de la base de données et des fichiers journaux WAL (Write-Ahead Log). Il est essentiel de sauvegarder régulièrement (généralement tous les jours) les fichiers de données. Vous devez également sauvegarder les fichiers WAL, qui enregistrent les modifications apportées à la base de données et sont essentiels pour la récupération à un moment précis et pour maintenir l'intégrité des données lors de la restauration.
Réplication de base de données
PostgreSQL propose des serveurs répliqués pour une fiabilité accrue. Ces réplicas sont classés comme des secours tièdes, qui n'acceptent pas les connexions d'application, ou des secours à chaud, qui fonctionnent en mode lecture seule. Les modifications apportées à la base de données principale sont appliquées en continu à l'instance répliquée pour que ses données restent à jour. Si la base de données principale échoue, l'instance répliquée est promue au statut principal et assume les responsabilités de la base de données principale.
Les répliques de base de données peuvent être placées dans la même zone ou le même centre de données que l'instance principale, dans une zone différente, dans une région différente ou dans une combinaison de ces emplacements. Plus l'instance répliquée est éloignée de la base de données principale, plus la latence est importante lors de l'envoi des modifications nécessaires pour maintenir les instances répliquées à jour. Pour les déploiements dans des lieux éloignés afin d'atténuer les défaillances à grande échelle, telles que les défaillances régionales, la réplication des données est généralement effectuée de manière asynchrone. Cette approche permet d'éviter la dégradation des performances qui peut se produire dans de telles configurations.
Dans les déploiements à haute disponibilité, les réplicas sont généralement déployés à proximité de la base de données principale. Par exemple, les réplicas déployés dans une autre zone du même centre de données offrent des RTO faibles et des RPO proches de zéro. En revanche, dans les configurations de reprise après sinistre, les réplicas sont déployés dans des centres de données ou des régions distincts, en fonction du niveau de protection requis contre les pannes. Cette approche entraîne un RPO plus élevé (car la réplication peut être asynchrone) et un RTO variable.
Le tableau suivant récapitule les mécanismes utilisés pour les architectures de référence de disponibilité AlloyDB Omni :
| Fonctionnalité | Standard | Amélioré | Premium |
|---|---|---|---|
| Sauvegarde | ✔ | ✔ | ✔ |
| Instance répliquée zonale | ❌ | ✔ | ✔ |
| Instance répliquée interzone | ❌ | ✔ | ✔ |
| Instance répliquée régionale | ❌ | ❌ | ✔ |
Tableau 1. Mécanismes de disponibilité AlloyDB Omni compatibles
Scénarios de défaillance et de récupération de base de données
Une défaillance de la base de données peut se produire aux niveaux suivants :
- Défaillance d'une instance (nœud ou serveur) : la base de données elle-même est défaillante.
- Défaillance du serveur : le serveur qui héberge la base de données échoue.
- Défaillance zonale : l'ensemble du centre de données hébergeant le serveur tombe en panne.
- Défaillance d'une région : l'ensemble de la région contenant plusieurs centres de données (zones de disponibilité) est indisponible, par exemple en raison d'une inondation ou d'un tremblement de terre de forte magnitude.
La probabilité et le risque de catastrophe diminuent lorsque le nombre d'événements diminue et que le coût de la prévention de ces événements augmente. Les entreprises doivent déterminer leur tolérance au risque et choisir d'accepter les perturbations potentielles ou d'investir dans des architectures plus résilientes pour minimiser les risques.
Le tableau suivant récapitule les scénarios de récupération compatibles avec les architectures de référence AlloyDB Omni :
| Type de sinistre | Standard | Amélioré | Premium |
|---|---|---|---|
| Défaillance de la VM/de l'instance | ✔ | ✔ | ✔ |
| Défaillance de nœud/serveur | ✔ | ✔ | ✔ |
| Défaillance de la zone | ❌ | ✔ | ✔ |
| Défaillance régionale | ❌ | ❌ | ✔ |
Tableau 2. Scénarios de récupération compatibles
Tenez compte des objectifs commerciaux de votre base de données AlloyDB Omni, comme un besoin critique de plusieurs 9 (99,99 %) de disponibilité et une absence de perte de données lors de la récupération pour les applications stratégiques. L'objectif des architectures de référence de disponibilité est de répondre aux exigences RTO et RPO.
AlloyDB Omni propose des architectures de disponibilité standards, améliorées et premium pour protéger les bases de données contre les pannes planifiées et non planifiées, en s'adaptant aux différents besoins des entreprises. Par exemple, les environnements de développement peuvent utiliser une protection de base avec des sauvegardes, tandis que les applications critiques peuvent utiliser des configurations de haute disponibilité et de reprise après sinistre.
Étapes suivantes
En savoir plus sur les architectures de référence de disponibilité AlloyDB Omni :
- Protéger vos données à l'aide de sauvegardes (disponibilité standard)
- Protégez vos données à l'aide de la réplication zonale dans une région (disponibilité améliorée).
- Protégez vos données à l'aide de la réplication zonale et régionale (disponibilité Premium).