2017-01-04 1 views
1

J'essaie d'identifier quelque chose dans la documentation Gemfire autour des sauvegardes de la région.Gemfire/Geode Back-ups

http://gemfire.docs.pivotal.io/geode/reference/topics/cache_xml.html#region

Faites défiler jusqu'à l'attribut scope ...

En utilisant l'attribut scope Région-ATTRIBUTES Je suppose que scope = "DISTRIBUÉ-ACK" signifierait SYNC opération de sauvegarde sur une REGION et que SCOPE = "DISTRIBUTED-NO-ACK" signifie une opération de sauvegarde ASYNC.

La région en question est PARTITIONNÉE. Je comprends que les régions REPLICATED par défaut à DISTRIBUTED-ACK.

Cette hypothèse serait-elle correcte? par exemple. que via la configuration Gemfire permet de configurer les opérations de sauvegarde SYNC ou ASYNC pour les mises à jour d'entrées REGION.

+0

Bienvenue dans Stack Overflow! Vous pouvez commencer par [tour] (http://stackoverflow.com/tour) et apprendre [Comment poser une bonne question] (http://stackoverflow.com/help/how-to-ask) et créer un [ Exemple minimal, complet et vérifiable] (http://stackoverflow.com/help/mcve). Ce sera plus facile pour nous de vous aider. – MrLeeh

Répondre

1

Les sauvegardes fonctionnent réellement au niveau des magasins de disques et des fichiers, et non des régions individuelles. L'opération de sauvegarde créera une copie de tous les fichiers de stockage sur disque, qui peuvent contenir des données pour de nombreuses régions avec des étendues différentes. La commande gfsh backup disk-store attend toujours la fin de la sauvegarde. La portée de la région n'affecte donc pas vraiment si la commande de sauvegarde est synchrone ou asynchrone. Si vous utilisez DISTRIBUTED_NO_ACK scope, cela signifie qu'un put peut terminer avant que tous les membres ne reçoivent la mise à jour, donc techniquement, il n'y a aucune garantie qu'un put sur une zone NO_ACK fasse partie d'une sauvegarde qui se produit après la mise.

+0

Salut Dan, Je devrais reformuler ma question légèrement, je suis intéressé par la nature de l'opération de réplique. par exemple. quand je fais une mise dans une région, elle ira au propriétaire principal de ce seau, puis une réplique sera placée sur un autre membre du cluster. Je voulais savoir si ce comportement peut être modifié pour être sync ou async en utilisant l'attribut SCOPE. En ce que le PUT retournera immédiatement après qu'il a atteint le propriétaire du compartiment principal si les réplicas ASYNC sont activés. –

+0

Ah. Eh bien, la portée DISTRIBUTED_NO_ACK fonctionne comme vous le décrivez, mais elle ne peut être utilisée qu'avec des régions répliquées. Les régions partitionnées prennent uniquement en charge la réplication entièrement synchrone. –

+0

C'est très intéressant, je pensais que c'était l'inverse. FULL SYNC sur REPLICATED et un choix de ASYNC ou SYNC sur PARTITIONED –