Gestion des tâches
La création de nouveaux index pour un nombre important de données ainsi que la réplication d'une base de données peuvent être des opérations longues.
Comment savoir si vos tâches sont en cours ou terminées ? Le point de terminaison _active_tasks fournit des informations sur toutes les tâches en cours. Toutefois,
si vous démarrez de nombreuses tâches, certaines d'entre elles peuvent être planifiées pour s'exécuter ultérieurement et ne pas s'afficher _active_tasks jusqu'à ce qu'elles commencent.
Voir les exemples suivants de code SDK et curl :
curl "$SERVICE_URL/_active_tasks"
import com.ibm.cloud.cloudant.v1.Cloudant;
import com.ibm.cloud.cloudant.v1.model.ActiveTask;
Cloudant service = Cloudant.newInstance();
List<ActiveTask> response =
service.getActiveTasks().execute().getResult();
System.out.println(response);
const { CloudantV1 } = require('@ibm-cloud/cloudant');
const service = CloudantV1.newInstance({});
service.getActiveTasks().then(response => {
console.log(response.result);
});
from ibmcloudant.cloudant_v1 import CloudantV1
service = CloudantV1.new_instance()
response = service.get_active_tasks().get_result()
print(response)
getActiveTasksOptions := service.NewGetActiveTasksOptions()
activeTask, response, err := service.GetActiveTasks(getActiveTasksOptions)
if err != nil {
panic(err)
}
b, _ := json.MarshalIndent(activeTask, "", " ")
fmt.Println(string(b))
L'exemple précédent de Go requiert le bloc d'importation suivant :
import (
"encoding/json"
"fmt"
"github.com/IBM/cloudant-go-sdk/cloudantv1"
)
Tous les exemples de Go nécessitent l'initialisation de l'objet service. Pour plus d'informations, reportez-vous à la documentation de l'API Section Authentification pour avoir des exemples.
A présent, vous allez apprendre à utiliser le noeud final _active_tasks pour surveiller les tâches à exécution longue. La commande curl permet d'accéder au noeud final. Le processeur JSON de ligne de commande jq est utilisé pour traiter la réponse JSON.
Ce document est un tutoriel concernant les tâches et présente uniquement la procédure de base pour leur réalisation. Pour plus d'informations, voir Utilisation d'IBM® Cloudant® for IBM Cloud®, qui est un guide complet présentant les options disponibles.
Bases de curl et jq
Pour obtenir toutes les tâches actives et formater correctement la sortie, appelez votre compte en utilisant curl, puis dirigez la sortie vers jq.
jq vous permet de filtrer une liste de documents en fonctions des valeurs des zones. Ainsi, il est plus facile d'obtenir tous les documents de réplication, ou les détails d'une seule tâche d'indexation de vue spécifique. La rubrique
Référence d'API inclut des informations supplémentaires sur les options.
Voici un exemple d'obtention et de formatage d'une liste de tâches actives :
curl "$SERVICE_URL/_active_tasks" | jq
Surveillance des générations de vue et des index de recherche
Les index de vue sont régénérés à chaque mise à jour d'un document de conception. Dès qu'une de ces vues est mise à jour, toutes les vues du document sont régénérées.
Les index de recherche sont régénérés uniquement lors de la modification de leur fonction d'index correspondante. Dès qu'un index de recherche est régénéré et qu'une modification est apportée à un document de conception incluant des vues, une nouvelle tâche est créée pour chaque réplique et chaque fragment d'un cluster.
Par exemple, si 24 fragments possédant 3 répliques chacun existent et que vous mettez à jour deux index de recherche, alors 24 x 3 x 2 = 144 tâches s'exécutent.
Pour trouver toutes les tâches d'indexation de vue, dirigez la sortie curl vers jq, et laissez ce dernier filtrer les documents dans le tableau en fonction de leur zone de type. Il existe une commande correspondante
pour les tâches d'indexation de recherche.
Dans chaque cas, les résultats de la recherche d'une liste de tâches d'indexation sont une liste d'objets JSON : Une pour chacune des tâches actives trouvées.
Voici un exemple de recherche de toutes les tâches d'indexation de vue qui filtre le type indexer :
curl -s "$SERVICE_URL/_active_tasks" | jq '.[] | select(.type=="indexer")'
Voici un exemple de recherche de toutes les tâches d'indexation de recherche qui filtre le type search_indexer :
curl -s "$SERVICE_URL/_active_tasks" | jq '.[] | select(.type=="search_indexer")'
Voici un exemple de résultat suite à la recherche de tâches d'indexation de vue :
{
"total_changes": 6435,
"started_on": 1371118332,
"user": "username",
"updated_on": 1371118334,
"type": "indexer",
"node": "dbcore@db6.meritage.cloudant.net",
"pid": "<0.16366.6103>",
"changes_done": 364,
"database": "shards/40000000-7fffffff/username/database",
"design_document": "_design/ngrams"
}
Estimation de la durée d'exécution d'une tâche
Pour estimer la durée d'exécution de la tâche d'indexation, surveillez le nombre d'éléments changes_done et comparez cette valeur à total_changes. Par exemple, si changes_done est incrémenté de 250 par
seconde et que total_changes a la valeur 1 000 000, il est attendu que l'exécution dure 1 000 000 / 250 = 4 000 secondes, soit environ 66 minutes.
Les estimations de la durée d'exécution d'une tâche d'indexation ne peuvent pas être exactes à 100 %. La durée d'exécution réelle de la tâche dépend des facteurs suivants :
- Durée de traitement de chaque document. Par exemple, une vue pourrait commencer par vérifier le type de document, et créer de nouvelles entrées d'index pour un seul type.
- Taille des documents.
- Charge de travail dans le cluster.
Gardez à l'esprit que ces facteurs peuvent être associés et réduire de manière importante la précision de votre estimation.
Voici un exemple d'extraction de la zone changes_done à l'aide de jq :
curl ... | jq '.[] | select(.type=="search_indexer") | .changes_done'
Surveillance de la réplication
Pour trouver toutes les tâches de réplication, dirigez la sortie curl vers jq, et filtrez les documents dans le tableau en fonction de leur zone de type.
Facilitez la sélection des informations sur un processus de réplication dans la liste de tâches actives en suivant les étapes ci-dessous :
- Démarrez le processus de réplication en créant un document dans la base de données
_replicator. - Associez sa zone
_idà une valeur connue.
Voici un exemple de recherche de toutes les tâches de réplication qui filtre le type replication :
curl -s "$SERVICE_URL/_active_tasks" | jq '.[] | select(.type=="replication")'
Voici un exemple de recherche d'une tâche de réplication spécifique qui filtre une identité de document connue :
curl ... | jq '.[] | select(.doc_id=="ID")'
Voici un exemple de recherche d'une tâche de réplication spécifique qui filtre une valeur replication_id connue :
curl ... | jq '.[] | select(.replication_id=="ID")'
Voici un exemple de résultat suite à la recherche d'une tâche de réplication :
{
"started_on": 1371094220,
"source_seq": "62960-sakdjflksdfjsdlkafjalskdfjlsakfjlasdkjksald",
"source": "",
"revisions_checked": 12,
"continuous": true,
"doc_id": null,
"doc_write_failures": 0,
"docs_read": 12,
"target": "",
"type": "replication",
"updated_on": 1371118477,
"user": "username",
"checkpointed_source_seq": "61764-dskfjalsfjsalkfjssadjfhasdfkjhsdkfhsdkf",
"changes_pending": 1196,
"pid": "<0.9955.4120>",
"node": "dbcore@db7.meritage.cloudant.net",
"docs_written": 12,
"missing_revisions_found": 12,
"replication_id": "asfksdlfkjsadkfjsdalkfjas+continuous+create_target"
}
Traitement des incidents générés par des tâches bloquées
Une tâche est-elle bloquée ?
Pour une réplication ponctuelle, non continue, dans laquelle la base de données source n'est pas mise à jour de manière significative lors de la réplication, la valeur changes_pending indique le nombre de documents restant à traiter.
Par conséquent, la valeur changes_pending constitue un bon indicateur de la fin possible de la réplication.
Dans le cadre d'une réplication continue, il est important de savoir comment le nombre de documents traités évolue au cours du temps et de déterminer si la valeur changes_pending augmente. Si c'est le caschanges_pending,
mais que la valeur revisions_checked reste constante pendant un moment, il est possible que la réplication soit bloquée. L'augmentation des valeurs changes_pending et
revisions_checked peut indiquer que la réplication ne parvient pas à gérer l'ajout ou la mise à jour de données dans la base de données.
Que faire lorsqu'une tâche est bloquée ?
Pour résoudre un problème de réplication bloquée, vous devrez peut-être annuler le processus de réplication et le relancer.
Si le problème persiste, cette situation peut être due au fait que l'utilisateur accédant aux bases de données source ou cible ne dispose pas des droits d'écriture.
La réplication utilise des points de contrôle, ce qui signifie qu'il n'est pas nécessaire de répliquer à nouveau le contenu déjà répliqué et non modifié si la réplication est redémarrée.
Si vous avez créé le processus de réplication en générant un document dans la base de données _replicator, vous pouvez également vérifier ici le statut de la réplication.