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, 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.
L'objectif de temps de récupération et l'RPO sont alignés sur les exigences de l'entreprise et sont définis comme suit :
- L'objectif de temps de récupération 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, telles qu'une perte de revenus ou de productivité.
- 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 une piste d'audit complète peuvent exiger une perte de données nulle.
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 (haute disponibilité).
- Disponibilité premium : protège vos données à l'aide de la réplication zonale et régionale (haute disponibilité et reprise après sinistre).
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. Différents types de sauvegarde (complète, incrémentielle et différentielle) offrent des équilibres variables entre l'objectif de point de récupération, la taille et la durée de la sauvegarde, et le temps de restauration.
Pour garantir 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 à la fois des sauvegardes de base de données et des sauvegardes de fichiers journaux WAL (Write-Ahead Log). Les sauvegardes régulières (généralement quotidiennes) des fichiers de données sont essentielles. Vous devez également sauvegarder les fichiers journaux 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 le maintien de 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 instances répliquées sont classées comme des instances de secours chaudes, qui n'acceptent pas les connexions d'application, ou des instances de secours froides, 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 les données de cette dernière soient à jour. En cas de défaillance de la base de données principale, l'instance répliquée est promue au statut principal et assume les responsabilités de la base de données principale.
Les instances répliquées 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 autre zone, dans une autre région 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 de modifications pour maintenir les instances répliquées à jour. Pour les déploiements sur des sites distants afin d'atténuer les défaillances à grande échelle, telles que les pannes régionales, la réplication des données est généralement effectuée de manière asynchrone. Cette approche évite la dégradation des performances qui peut se produire dans de telles configurations.
Dans les déploiements à haute disponibilité, les instances répliquées sont généralement déployées à proximité de la base de données principale. Par exemple, les instances répliquées déployées dans une autre zone du même centre de données offrent des objectifs de temps de récupération faibles et des RPO proches de zéro. En revanche, dans les configurations de reprise après sinistre, les instances répliquées sont déployées 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 objectif de temps de récupération variable.
Le tableau suivant récapitule les mécanismes utilisés pour les architectures de référence de disponibilité AlloyDB Omni :
| Fonctionnalité | Standard | Enhanced | Premium |
|---|---|---|---|
| Sauvegarde | ✔ | ✔ | ✔ |
| Instance répliquée zonale | ❌ | ✔ | ✔ |
| Instance répliquée interzonale | ❌ | ✔ | ✔ |
| Instance répliquée régionale | ❌ | ❌ | ✔ |
Tableau 1. Mécanismes de disponibilité AlloyDB Omni compatibles
Défaillances de base de données et scénarios de récupération
Une défaillance de base de données peut se produire aux niveaux suivants :
- Défaillance d'instance (nœud ou serveur) : la base de données elle-même échoue.
- 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 échoue.
- Défaillance régionale : 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 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 catastrophe | Standard | Enhanced | Premium |
|---|---|---|---|
| Défaillance de VM/d'instance | ✔ | ✔ | ✔ |
| Défaillance de nœud/de serveur | ✔ | ✔ | ✔ |
| Défaillance de 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, tels que le besoin critique de plusieurs 9 (99,99 %) de disponibilité et d'une perte de données nulle lors de la récupération pour les applications critiques. L'objectif des architectures de référence de disponibilité est de répondre aux exigences en termes d'objectif de temps de récupération et d'RPO.
AlloyDB Omni propose des architectures de disponibilité standard, améliorée 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 de l'entreprise. 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.
Étape suivante
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éger vos données à l'aide de la réplication zonale dans une région (disponibilité améliorée).
- Protéger vos données à l'aide de la réplication zonale et régionale (disponibilité premium).