Lakebase Reprise après sinistre (DR)
La reprise après sinistre est en aperçu privé. Pendant l'aperçu privé, cette fonctionnalité est disponible uniquement pour la réplication interrégionale sur AWS. Pour activer la reprise après sinistre pour votre compte, demandez à votre administrateur de Workspace de contacter votre représentant de compte Databricks.
Pendant l'aperçu privé, la reprise après sinistre n'est pas destinée à un usage en production.
La reprise après sinistre (DR) de Lakebase réplique les données de votre projet vers un Workspace secondaire dans une région différente, protégeant contre les pannes de région complètes, y compris les interruptions, plutôt que contre une seule panne de compute ou une panne de zone de disponibilité (AZ). Lakebase propose actuellement une réplication périodique, qui synchronise vos données vers une autre région sans avoir à exécuter de compute supplémentaire. Le mode périodique est destiné aux cas d'usage où vous devez vous protéger contre les pannes régionales, mais votre cas d'usage n'est pas aussi sensible à l'indisponibilité régionale (par exemple, des fenêtres RPO de l'ordre des minutes). Vous devez manuellement Trigger un basculement si vous souhaitez promouvoir un projet secondaire pour qu'il devienne primaire, bien que vous puissiez choisir de créer des scripts pour ce comportement.
Cette page explique le fonctionnement de la reprise après sinistre de Lakebase. Pour l'activer et Trigger un basculement ou un retour sur incident, consultez Gérer la reprise après sinistre.
Pendant l'aperçu privé, vous gérez la récupération après sinistre depuis les paramètres du projet dans l'UI. Les APIs de reprise après sinistre sont disponibles, mais sont sujettes à modification.
Comment fonctionne la récupération après sinistre
La reprise après sinistre associe le Workspace principal de votre projet à un Workspace secondaire dans une autre région, formant un groupe de réplication. Lakebase réplique périodiquement les données validées du primaire vers le secondaire. Le compute secondaire reste inactif jusqu'à un basculement, de sorte que vous ne payez pas pour une veille permanente. La réplication se produit au niveau de la couche de stockage, de sorte que le compute secondaire n'a pas besoin d'être exécuté pour recevoir les données répliquées.
Lakebase expose une métrique de décalage de réplication qui indique dans quelle mesure le secondaire est en retard par rapport au primaire. Le décalage vous indique la quantité de données que vous perdriez si vous basculiez maintenant, et c'est ainsi que vous confirmez que la réplication a entièrement rattrapé son retard (RPO=0) avant un retour sur incident planifié.
Reprise après sinistre vs. haute disponibilité
La reprise après sinistre et la haute disponibilité protègent contre différents domaines de défaillance, et la plupart des charges de travail de production utilisent les deux. La haute disponibilité maintient le compute redondant en fonctionnement, de sorte qu'une panne de compute ou de zone de disponibilité ne met pas votre base de données hors ligne. La reprise après sinistre conserve une copie répliquée de vos données dans une autre région, afin que vous puissiez reprendre vos opérations Lakebase en cas de défaillance régionale.
Vous pouvez combiner la haute disponibilité et la reprise après sinistre pour les applications de production et critiques afin de créer un modèle de déploiement plus résilient pour votre projet Lakebase.
Haute disponibilité | Récupération après sinistre | |
|---|---|---|
Protège contre | Défaillance de compute ou de zone de disponibilité au sein d'une région | Défaillances régionales, y compris les pannes |
Portée | Au sein des zones de disponibilité d'une région | Entre les régions |
Ressource redondante | Instances de compute en veille, déjà exécutées dans d'autres zones | Une copie de données répliquées dans un Workspace secondaire |
compute de secours | Toujours actif, prêt à prendre le relais instantanément | Mode périodique : inactif jusqu'au basculement, vous ne payez donc pas pour le compute en veille |
Perte de données lors du basculement | Aucun (RPO = 0), la réplication est synchrone | Les données sont réservées dans la région primaire ; elles peuvent être incohérentes jusqu'à ce qu'elles soient réconciliées ultérieurement via les Branch de récupération. |
Déclencheur | Automatic | Manuel (vous pouvez choisir de l'automatiser, selon vos exigences) |
Impact de l'application | Reconnectez-vous à la même chaîne de connexion | Reconnectez-vous en utilisant la chaîne de connexion de la nouvelle région principale. |
Votre configuration de haute disponibilité est copiée dans le projet secondaire dans le cadre du groupe de réplication, de sorte que la haute disponibilité est préservée après un basculement. Vous n'avez pas besoin de le reconfigurer sur le nouveau principal.
Basculement et retour arrière
Le basculement transfère les écritures du primaire vers le secondaire et promeut le secondaire au rang de nouveau primaire. Le primaire d'origine cesse d'accepter les écritures. Étant donné que chaque région a ses propres points de terminaison, le nouveau primaire a une chaîne de connexion différente. Après un basculement, mettez à jour votre application pour utiliser la chaîne de connexion du nouveau primaire, ainsi qu'un nouveau jeton d'authentification, avant de reprendre le trafic.
Le basculement est toujours manuel. Étant donné que la réplication est périodique, les données dans le secondaire peuvent être en retard par rapport au primaire, donc à tout moment, elles peuvent ne pas contenir les transactions les plus récemment validées. La promouvoir est donc une décision commerciale : vous choisissez de reprendre le service sur une copie légèrement obsolète et acceptez que les transactions récentes soient reportées vers une Branch de récupération jusqu'à ce que vous les rapprochiez. Lakebase ne fait pas ce compromis pour vous, donc un administrateur de projet Lakebase déclenche Trigger chaque basculement.
Le retour sur incident utilise le même mécanisme de basculement, exécuté en sens inverse, une fois que la région primaire d'origine se rétablit et rejoint le groupe de réplication en tant que secondaire. Pour atteindre un RPO=0 lors du retour sur incident, arrêtez d'abord le trafic d'écriture sur le primaire actuel, afin que la réplication puisse entièrement rattraper son retard avant le retour sur incident.
Branch de récupération
Si une région devient indisponible avant que toutes les transactions ne se répliquent vers le secondaire, ces transactions non répliquées sont préservées. Lakebase préserve la chronologie divergente en tant que Branch de récupération sur le primaire d'origine. Les Branch de récupération restent masquées jusqu'à ce qu'une divergence soit détectée, et deviennent accessibles après le retour arrière, lorsque le primaire d'origine redevient en ligne. Lakebase affiche ensuite une notification vous permettant d'inspecter la chronologie divergente. Vous décidez quand réconcilier les données, et Lakebase ne Merge ni ne supprime jamais automatiquement une Branch de récupération.
Pour inspecter et réconcilier une Branch de récupération, consultez Inspecter et réconcilier les Branches de récupération.
Ce qui n'est pas pris en charge
Le tableau suivant répertorie les fonctionnalités et les configurations qui sont limitées ou non encore disponibles durant l'aperçu privé. Certaines sont prévues pour une version ultérieure, et d'autres ne relèvent pas du champ d'application de la reprise après sinistre.
Fonctionnalité | Statut |
|---|---|
CLI et API | Les APIs en préversion sont disponibles, mais susceptibles de modifications pendant l'aperçu privé. |
Réplicas en lecture inter-régions | Pas encore disponible. Le compute du secondaire reste inactif en mode périodique et ne peut pas traiter les lectures tant qu'un basculement n'est pas effectué. |
Basculement (basculement contrôlé avec RPO=0) | Pas encore pris en charge. Vous devez planifier un basculement contrôlé. |
Endpoint global | Pas encore pris en charge. Vous devez gérer la connexion aux endpoints régionaux après un basculement. |
Réplication inter-Workspace dans la même région | Non pris en charge. Le primaire et le secondaire doivent se trouver dans des régions différentes. |
PrivateLink | Pas encore pris en charge. Le trafic de réplication entre les Workspaces primaire et secondaire transite par l'internet public, chiffré en transit. |
Intégrations Lakehouse sur basculement
Les tables synchronisées et les pipelines Lakebase CDF se terminent lors du basculement et ne reprennent pas automatiquement. Reconfigurez-les manuellement après un basculement. Les données qu'ils gèrent se comportent différemment :
- Tables synchronisées (lakehouse vers Lakebase). Les données synchronisées sont répliquées vers le projet secondaire, elles sont donc présentes sur le nouveau primaire après le basculement. Seul le pipeline doit être reconfiguré.
- Lakebase CDF (de Lakebase vers le lakehouse). Les données Delta ne sont pas répliquées, car la reprise après sinistre ne réplique pas les tables Delta.
Ressources supplémentaires
- Gérer la reprise après sinistre pour activer la reprise après sinistre et Trigger un basculement
- Haute disponibilité pour le basculement automatique intrarégional
- Database Branch pour comprendre comment les branches de récupération sont liées aux branches régulières