Dernier timestamp restaurable pour les comptes Azure Cosmos DB avec le mode de sauvegarde continue
S’APPLIQUE À : NoSQL MongoDB Gremlin Table
Azure Cosmos DB propose une API qui permet d’obtenir le dernier timestamp restaurable d’un conteneur. Cette API est disponible pour les comptes pour lesquels le mode de sauvegarde continue est activé. Le dernier horodatage restaurable représente l’horodatage le plus récent au format UTC auquel vos données ont été correctement sauvegardées. À l’aide de cette API, vous pouvez obtenir le timestamp restaurable pour déclencher la restauration du compte en direct ou surveiller que vos données sont sauvegardées à temps.
Cette API prend également l’emplacement du compte comme paramètre d’entrée et renvoie le dernier timestamp restaurable pour le conteneur donné dans cet emplacement. Si un compte existe dans plusieurs emplacements, le dernier timestamp restaurable pour un conteneur situé à des emplacements différents peut être différent, car les sauvegardes de chaque emplacement sont effectuées indépendamment.
Par défaut, cette API fonctionne uniquement au niveau du conteneur, mais elle peut être facilement étendue pour fonctionner au niveau de la base de données ou du compte. Cet article vous aide à comprendre la sémantique de l’API, comment elle est calculée et les cas d’usage associés. Pour en savoir plus, découvrez comment obtenir le dernier horodateur de restauration pour des comptes API pour NoSQL, MongoDB, Table et Gremlin.
Cas d'utilisation
Vous pouvez utiliser le dernier timestamp restaurable dans les cas d’usage suivants :
Vous pouvez obtenir le dernier timestamp restaurable pour un conteneur, une base de données ou un compte et l’utiliser pour déclencher la restauration. Cet horodatage représente les données de la ressource spécifiée ou de toutes les ressources sous-jacentes quand elles ont été correctement sauvegardées.
Vous pouvez utiliser cette API pour vérifier que vos données ont été correctement sauvegardées avant la suppression du compte. Si l’horodatage renvoyé par cette API est inférieur au dernier horodatage d’écriture, cela signifie qu’il y a des données qui n’ont pas encore été sauvegardées. Dans ce cas, vous devez appeler cette API jusqu’à ce que le timestamp soit supérieur ou égal au dernier timestamp d’écriture. Si un compte existe dans plusieurs localisations, vous devez obtenir le dernier horodatage restaurable de toutes les localisations pour vérifier que les données ont été sauvegardées dans toutes les régions avant la suppression du compte.
Vous pouvez utiliser cette API pour surveiller si vos données sont sauvegardées à temps. Ce timestamp est généralement de quelques centaines de secondes après l’heure actuelle, et parfois plus élevé.
Sémantique
Le dernier horodatage restaurable d’un conteneur est l’horodatage minimal où ont été prises les sauvegardes de toutes ses partitions dans une localisation. Cette API calcule le dernier horodatage restaurable en récupérant l’horodatage de la dernière sauvegarde de chaque partition du conteneur dans une localisation et renvoie l’horodatage minimum de tous ces horodatages. Si les données de toutes ses partitions sont sauvegardées et qu’aucune nouvelle donnée n’a été écrite dans ces partitions, l’API renvoie l’horodatage actuel maximal et l’horodatage de la dernière sauvegarde de données.
Si une partition n’a pas encore effectué de sauvegarde, mais dispose de certaines données à sauvegarder, elle retourne le timestamp Unix minimal (époque) autrement dit le 1er janvier 1970 heure UTC (temps universel coordonné). Dans ce cas, l’utilisateur doit réessayer jusqu’à ce que l’opération donne un timestamp supérieur au timestamp d’époque.
Calcul du dernier timestamp restaurable
L’exemple suivant décrit le résultat attendu de l’API du dernier horodatage restaurable dans différents scénarios. Dans chaque scénario, nous décrivons l’état de sauvegarde de fichier journal actuel de la partition, les données en attente de sauvegarde et comment cela affecte le calcul du dernier horodatage restaurable général pour un conteneur.
Supposons que nous avons un compte qui existe dans deux régions (USA Est et USA Ouest). Nous avons un conteneur « cont1 » avec deux partitions (Partition1 et Partition2). Si nous envoyons une demande pour obtenir le dernier timestamp restaurable pour ce conteneur au moment du timestamp « t3 », le dernier timestamp restaurable pour ce conteneur se calcule comme suit :
Cas 1 : les données de toutes les partitions n’ont pas encore été sauvegardées
Région USA Est :
- Partition 1 : heure de la dernière sauvegarde = t2, mais elle possède d’autres données à sauvegarder après l’heure t2.
- Partition 2 : heure de la dernière sauvegarde = t3 et toutes ses données sont sauvegardées.
- Dernier timestamp restaurable = min (t2, t3) = t2
Région USA Ouest :
- Partition 1 : heure de la dernière sauvegarde = t1, mais elle possède d’autres données à sauvegarder après l’heure t1.
- Partition 2 : heure de la dernière sauvegarde = t2, mais elle possède d’autres données à sauvegarder après l’heure t2.
- Dernier timestamp restaurable = min (t1, t2) = t1
Cas 2 : les données de toutes les partitions sont sauvegardées
Région USA Est :
- Partition 1 : heure de la dernière sauvegarde = t2 et toutes ses données sont sauvegardées.
- Partition 2 : heure de la dernière sauvegarde = t3 et toutes ses données sont sauvegardées.
- Dernier timestamp restaurable = max (timestamp actuel, t2, t3)
Région USA Ouest :
- Partition 1 : heure de la dernière sauvegarde = t3 et toutes ses données sont sauvegardées.
- Partition 2 : heure de la dernière sauvegarde = t3 et toutes ses données sont sauvegardées.
- Dernier timestamp restaurable = max (timestamp actuel, t3, t3)
Cas 3 : lorsqu’une ou plusieurs partitions n’ont pas encore effectué de sauvegarde
Région USA Est :
- Partition 1 : aucune sauvegarde du journal n’a encore été effectuée pour cette partition.
- Partition 2 : Heure de dernière sauvegarde = t3
- Dernier timestamp restaurable = 1/1/1970 12:00:00 AM
Forum aux questions
Puis-je utiliser cette API pour les comptes avec une sauvegarde périodique ?
Faux. Cette API ne peut être utilisée que pour les comptes avec le mode de sauvegarde continue.
Puis-je utiliser cette API pour les comptes migrés vers le mode continu ?
Oui. Cette API peut être utilisée pour le compte provisionné avec le mode de sauvegarde continue ou correctement migré vers le mode de sauvegarde continue.
Quel est le délai classique entre le dernier timestamp d’écriture et le dernier timestamp restaurable ?
Les données de sauvegarde du journal sont sauvegardées toutes les 100 secondes. Toutefois, dans certains cas exceptionnels, les sauvegardes peuvent être retardées de plus de 100 secondes.
L’horodatage restaurable fonctionne-t-il pour les ressources supprimées ?
Non. Il s’applique uniquement aux ressources actives (bases de données, collections ou compte). Vous pouvez obtenir le timestamp restaurable pour déclencher la surveillance ou la restauration du compte en direct sur lequel vos données sont restaurées.