Gérer la reprise après sinistre

remarque

La reprise après sinistre est en aperçu privé. Pendant la préversion privée, il est disponible pour la réplication interrégionale sur AWS uniquement, et vous le gérez depuis les paramètres du projet dans l’interface utilisateur. Pour l’activer pour votre compte, demandez à l’administrateur de votre 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.

Ce guide explique comment activer la reprise après sinistre pour un projet, déclencher un basculement ou une restauration après basculement, et inspecter les branches de récupération. Pour plus d’informations sur le fonctionnement de la reprise après sinistre et sur ses différences avec la haute disponibilité, consultez Reprise après sinistre.

Seul un administrateur de projet Lakebase (une personne disposant de la CAN_MANAGE liste de contrôle d'accès (ACL)) peut activer ou désactiver la reprise après sinistre, ou Trigger un basculement. Pour voir qui CAN_MANAGE a, vérifiez la section **Autorisations du projet** des paramètres du projet.

La reprise après sinistre couvre deux Workspaces : chaque tâche est effectuée dans un Workspace spécifique.

Tâche	Où vous l'exécutez
Activer ou désactiver	Le projet principal, dans le Workspace principal
Trigger un basculement	Le projet secondaire, dans le Workspace secondaire.
Failback	Le projet principal d'origine, dans le Workspace principal d'origine (maintenant le secondaire).
Inspecter les Branch de récupération	Le projet Primary d'origine, dans le Workspace Primary d'origine, après le retour arrière

Tâche	Où vous l'exécutez
Activer ou désactiver	Le projet principal, dans le Workspace principal
Trigger un basculement	Le projet secondaire, dans le Workspace secondaire.
Failback	Le projet principal d'origine, dans le Workspace principal d'origine (maintenant le secondaire).
Inspecter les Branch de récupération	Le projet Primary d'origine, dans le Workspace Primary d'origine, après le retour arrière

Prérequis

• **Un projet Lakebase Autoscaling.** Les projets créés avec Lakebase Provisionné doivent être migrés vers l'autoscaling avant que vous ne puissiez activer la reprise après sinistre. Consultez Mise à niveau vers Lakebase Autoscaling.
• **Deux Workspaces dans des régions différentes.** Les Workspaces dans la même région ne sont pas pris en charge en tant que paire de réplication.
• Le Workspace secondaire en tant que cible de réplication éligible. Le Workspace secondaire doit figurer sur la liste des cibles de réplication éligibles de votre compte. Pendant la préversion privée, votre représentant de compte Databricks configure cela lorsqu'il active la reprise après sinistre.

remarque

Pendant la préversion privée, veuillez fournir à votre représentant de compte les informations suivantes afin qu'il puisse configurer votre groupe de réplication :

• ID de compte : retrouvez-le dans la console de compte
• ID du Workspace principal : le Workspace où se trouve le projet Lakebase principal
• ID du Workspace secondaire : le Workspace où s'exécute le projet Lakebase secondaire
• ID de projet Lakebase : le projet doit déjà exister avant que la reprise après sinistre puisse être activée.

Pour trouver un ID de workspace, consultez Obtenir les identifiants des objets workspace. L’ID de projet Lakebase est le project_id du projet, affiché dans la liste des projets de la console Lakebase.

La reprise après sinistre fonctionne avec les clés gérées par le client (CMK) : les projets chiffrés par CMK sont répliqués entre les régions comme tout autre projet.

Activer la reprise après sinistre

Un administrateur de projet active la réplication depuis le projet Primary , dans le Workspace qui l'héberge.

1. Dans le Workspace principal, ouvrez votre projet et sélectionnez Paramètres .
2. Dans la section **Cross-Workspace Replication**, confirmez le **Workspace principal**. Ceci est défini sur le Workspace qui héberge le projet et ne peut pas être modifié.
3. Sous Secondaire , sélectionnez le Workspace où le projet secondaire s'exécute.
4. Sélectionnez **Enregistrer et activer**.

Lakebase crée le groupe de réplication et commence la réplication périodique du Principal au Secondaire.

Dans le Workspace secondaire, Lakebase crée un projet secondaire portant le même nom que le principal. Pour le trouver, passez au Workspace secondaire et ouvrez la console Lakebase. Le nouveau projet apparaît dans la liste des **Projets de base de données à dimensionnement automatique**.

Le projet secondaire inclut toutes les branches du projet principal, et chaque branch a ses propres Endpoints régionaux. Pendant la réplication périodique, ce projet secondaire est en lecture seule. Son compute reste inactif et vous ne pouvez pas vous y connecter tant qu'un basculement ne le promeut pas. La configuration de la Branch, y compris les plages de compute et la haute disponibilité, est copiée à partir du primaire afin que le compute correspondant puisse start immédiatement en cas de basculement.

Trigger un basculement

Un administrateur de projet Trigger un failover depuis le Workspace secondaire, afin que vous puissiez le start même lorsque la région principale est indisponible. Le basculement est immédiat : Lakebase promeut le secondaire au rang de nouveau principal et cesse d'accepter les écritures sur le principal d'origine.

Pour Trigger un basculement :

1. Dans le workspace secondaire, ouvrez le projet secondaire et accédez à son tableau de bord du projet .
2. Sous Paramètres du projet , sélectionnez Promouvoir le secondaire .
3. Dans la boîte de dialogue Promotion , sélectionnez basculement . Le basculement promeut cette copie immédiatement. Les transactions qui n'avaient pas encore été répliquées vers ce Workspace ne sont pas promues avec celui-ci. Lakebase les préserve en tant que branche de récupération que vous réconcilierez plus tard, après la restauration après basculement.
4. Sélectionnez **Je confirme que je souhaite promouvoir ce projet et que cette opération peut entraîner des temps d'arrêt**, puis sélectionnez **Promouvoir**.

Le basculement implique des temps d'arrêt. Le principal d'origine cesse immédiatement d'accepter les écritures, et le nouveau principal est indisponible tant qu'il ne start pas le compute et qu'il n'est pas interrogeable. Votre application reste en panne tant que vous ne la configurez pas pour se connecter au nouveau principal à l'aide de sa chaîne de connexion. Plus précisément, après un basculement :

• Le projet secondaire devient le nouveau Primary. Lakebase active ses Endpoints régionaux et start le compute pour chaque Branch, en utilisant la configuration de Branch copiée du Primary d'origine.
• Le primaire d'origine cesse d'accepter les écritures. Lorsque son Workspace est disponible, Lakebase arrête son compute. Toute table synchronisée ou pipeline CDF Lakebase est résiliée.
• Votre application doit se reconnecter à l'Endpoint du nouveau principal. Chaque région a ses propres Endpoint, mettez donc à jour la configuration de connexion de votre application et obtenez un nouveau jeton d'authentification avant de reprendre le trafic. Obtenez la chaîne de connexion et le jeton du nouveau principal depuis la boîte de dialogue **Connect** dans le projet secondaire. Voir Se connecter à votre base de données.

Vous pouvez Trigger un basculement à tout moment, pas seulement pendant une panne réelle. Utilisez ceci pour effectuer des exercices de reprise après sinistre et répéter votre processus de reconnexion, en mettant à jour la chaîne de connexion de votre application et en obtenant un nouveau jeton, afin qu'il soit éprouvé avant une panne réelle.

Rebasculer vers votre région d'origine

Le failback renvoie votre charge de travail vers sa région d’origine une fois cette région rétablie. Dans le cycle de reprise après sinistre, le failover est le basculement d’urgence qui vous permet de fonctionner dans la région secondaire pendant une interruption ; le failback est le retour planifié une fois que la région d’origine est de nouveau opérationnelle, afin que vous puissiez reprendre votre topologie normale. Le failback est facultatif. Faites-le lorsque vous souhaitez que la région d’origine redevienne la région principale.

Le rebasculement n'est pas une Opération distincte : c'est un basculement effectué dans la direction opposée. Une fois que la région principale d'origine est récupérée, son projet rejoint le groupe de réplication en tant que secondaire et la réplication reprend du principal actuel vers celui-ci. Comme vous effectuez le rebasculement en tant qu'Opération planifiée plutôt que pendant une panne, vous pouvez d'abord laisser la réplication se rattraper complètement, puis revenir sans perte de données (RPO=0). Pour ce faire, vous arrêtez les écritures sur le principal actuel et attendez que le retard de réplication atteigne zéro avant la promotion, comme décrit dans les étapes suivantes.

Le dialogue Promouvoir liste également Switchover comme une option à venir. Switchover arrêtera les écritures sur le Primary actuel, attendra que toutes les transactions soient répliquées et promouvra en une seule étape, de sorte que vous n'aurez pas besoin d'arrêter les écritures et de basculer en étapes séparées.

Pour rebasculer :

1. Arrêtez le trafic d'écriture sur le primaire actuel afin qu'aucune nouvelle transaction ne soit créée pendant que la région d'origine se met à jour. Vous le faites depuis votre application, par exemple en suspendant le service d'écriture ou en plaçant l'application en mode lecture seule ou maintenance. Lakebase n'arrête pas les écritures pour vous.
2. Surveillez le décalage de réplication jusqu'à ce qu'il atteigne zéro, confirmant que toutes les transactions ont été répliquées vers la région d'origine.
3. Depuis le Workspace principal d'origine, ouvrez le projet (qui agit maintenant comme secondaire) et sélectionnez Promouvoir le secondaire sur son tableau de bord, la même action que vous avez utilisée pour le basculement. Dans la boîte de dialogue Promote , sélectionnez basculement et confirmez.
4. Configurez votre application pour qu'elle se connecte au primaire d'origine à l'aide de sa chaîne de connexion et d'un nouveau jeton d'authentification. Obtenez-les à partir de la boîte de dialogue Connexion dans le projet principal d'origine. Consultez Connectez-vous à votre base de données.

Après le failback :

• La région d'origine redevient le primaire, et l'autre région redevient un secondaire inactif.
• Si des transactions n'ont pas été répliquées avant la panne d'origine, Lakebase les affiche sous forme de branches de récupération sur le principal d'origine. Consultez Examiner et rapprocher les branches de récupération.

Inspecter et réconcilier les Branch de récupération

Les Branches de récupération vivent sur le projet Primary d'origine, vous les inspectez donc dans le Workspace Primary d'origine. Lorsqu'un projet a des Branch de récupération, sa page Branches affiche une bannière indiquant le nombre de Branch de récupération existant suite à un basculement récent, avec une invite à inspecter leur divergence de données. Sélectionnez Afficher les Branches de projet pour les voir. Les Branches de récupération ne sont affichées que lorsque la divergence est détectée.

Sur la page **Branches**, une branche de récupération apparaît avec le nom de la branche dont elle a divergé, plus un -recovery suffixe. Son étiquette d'état indique où il se trouve dans le processus de synchronisation :

• **Synchronisation vers l'origine en attente** : la branch n'a pas encore été répliquée vers sa région d'origine, la divergence ne peut donc pas être déterminée. Survoler l'étiquette explique que l'inspection est prématurée. C'est l'état juste après un basculement, avant la reprise après basculement. Attendez que la Branch se synchronise.
• Inspecter : la Branch a été resynchronisée avec sa région d'origine et est prête à être rapprochée.

Une fois qu'une Branch de récupération affiche **Inspecter** :

1. Dans le projet principal d'origine, ouvrez la page Branches .
2. Interrogez la Branch de récupération pour trouver les transactions qui ne se sont pas répliquées vers le Secondaire avant la panne. Une Branch de récupération est une Branch normale, vous l'interrogez donc de la même manière que toute autre Branch.
3. Rapprochez les données manuellement. Lakebase n'effectue pas automatiquement de Merge une Recovery Branch dans votre Production Branch, car vous êtes le seul à savoir comment les données ont divergé. Voir Comment effectuer le rapprochement.
4. Supprimez la branch de récupération lorsque vous avez terminé.

Les Branch de récupération ne sont jamais supprimées automatiquement. Lakebase préserve l'historique de la divergence jusqu'à ce que vous supprimiez la branch vous-même.

Comment rapprocher

A recovery Branch holds your data as it existed on the original Primary at the moment of failover, including the transactions that hadn't replicated yet. Votre Branch de production contient les données qui ont été répliquées et toutes les écritures effectuées après le basculement. Le rapprochement signifie trouver ce qui se trouve uniquement sur la Branch de récupération et décider quoi en faire.

La Branch de récupération et votre Branch de production sont des bases de données distinctes avec leurs propres Endpoints, vous les comparez donc plutôt que d'effectuer des queries entre elles. Quelques manières de trouver les données divergentes :

• Examinez les lignes les plus récentes. Les transactions non répliquées sont les dernières écrites avant la panne, de sorte que la divergence se concentre sur les lignes récentes. Si vos tables ont une colonne Timestamp, interrogez la Branch de récupération pour les lignes écrites dans les minutes précédant le basculement.
• Comparez les valeurs maximales. Pour les tables avec une séquence ou un ID incrémentiel, comparez la valeur maximale de la branch de récupération avec votre branch de production. Une valeur plus élevée sur la branch de récupération indique des lignes qui n'ont jamais été répliquées.
• Comparez les nombres de lignes. Une table avec plus de lignes sur la Branch de récupération que sur la production présente des insertions non répliquées à investiguer.

Une fois que vous avez identifié les lignes divergentes, décidez par table comment les concilier : réinsérez les lignes manquantes en production, réappliquez les mises à jour ou ignorez intentionnellement les modifications que vous ne souhaitez pas.

Désactiver la reprise après sinistre

Un administrateur de projet désactive la reprise après sinistre depuis le projet principal, dans le Workspace principal, le même endroit où vous l'avez activée.

1. Dans le Workspace principal, ouvrez votre projet et sélectionnez Paramètres .
2. Dans la section Réplication inter-Workspace , sélectionnez Désactiver la réplication .

La désactivation supprime le groupe de réplication et arrête la réplication. Par la suite, vous conservez l'accès au projet dans le Workspace principal uniquement. Le projet secondaire est supprimé du Workspace secondaire.

Ressources supplémentaires

• Reprise après sinistre — concepts, comportement du basculement et ce qui n'est pas pris en charge.
• Haute disponibilité — basculement automatique intra-régional
• Gérer les autorisations du projet — l'ACL CAN_MANAGE requise pour gérer la reprise après sinistre