Réessayer d'exécuter des jobs

Par défaut, si un job Cloud Scheduler ne reçoit pas d'accusé de réception de son gestionnaire, il est considéré comme ayant échoué et une nouvelle tentative est effectuée en fonction de l'intervalle exponentiel entre les tentatives que vous avez configuré. Vous pouvez déterminer ce comportement de nouvelle tentative de différentes manières lorsque vous créez ou mettez à jour un job Cloud Scheduler :

Paramètres de réessai

Les tableaux suivants décrivent les paramètres de nouvelle tentative que vous pouvez configurer.

Nombre maximal de nouvelles tentatives

Nombre de tentatives que le système effectuera pour exécuter un job à l'aide de la procédure d'intervalle exponentiel entre les tentatives décrite par maxDoublings.

Description

Si retryCount est défini sur un nombre non nul, Cloud Scheduler relance le job ayant échoué, en utilisant un intervalle exponentiel entre les tentatives, retryCount fois jusqu'à ce que le job réussisse ou que le nombre de tentatives soit épuisé. Notez que la prochaine heure d'exécution planifiée peut être ignorée si les nouvelles tentatives se poursuivent jusqu'à cette heure.

Si retryCount est défini sur 0 (et si maxRetryDuration est également défini sur 0), une tentative de tâche ne sera pas relancée en cas d'échec. Cloud Scheduler attendra la prochaine heure d'exécution programmée.

Les valeurs supérieures à 5 et les valeurs négatives ne sont pas autorisées.
Par défaut La valeur par défaut est "0".
Libellé de la console Nombre maximal de nouvelles tentatives
Option de la CLI --max-retry-attempts
Champ de l'API retryCount

Durée maximale de nouvelle tentative

Délai maximal pour une nouvelle tentative d'exécution d'un job ayant échoué, mesuré à partir du moment où une exécution a été tentée pour la première fois. Si ce nombre est spécifié avec retryCount, le job sera relancé jusqu'à ce que les deux limites soient atteintes.

Description

Durée en secondes avec neuf chiffres au maximum après la virgule et se terminant par "s" (par exemple, "3.5s").

Une durée de 0 signifie que la durée de la nouvelle tentative est illimitée. Toutefois, si retryCount est également défini sur 0, une tentative de tâche ne sera pas relancée en cas d'échec.
Par défaut La valeur par défaut est de 0 seconde.
Libellé de la console Durée maximale de nouvelle tentative
Option de la CLI --max-retry-duration
Champ de l'API maxRetryDuration

Intervalle minimal entre les tentatives

Délai minimal d'attente avant de relancer une tâche ayant échoué.

Description

Durée en secondes avec neuf chiffres au maximum après la virgule et se terminant par "s" (par exemple, "3.5s").
Par défaut La valeur par défaut est de 5 secondes.
Libellé de la console Intervalle minimal entre les tentatives
Option de la CLI --min-backoff
Champ de l'API minBackoffDuration

Intervalle maximal entre les tentatives

Délai maximal d'attente avant de relancer une tâche ayant échoué.

Description

Durée en secondes avec neuf chiffres au maximum après la virgule et se terminant par "s" (par exemple, "3.5s").
Par défaut La valeur par défaut est de 3 600 secondes (1 heure).
Libellé de la console Durée maximale de l'intervalle entre les tentatives
Option de la CLI --max-backoff
Champ de l'API maxBackoffDuration

Nombre maximal de doublements

Nombre maximal de fois où l'intervalle entre les tentatives d'exécution de tâches ayant échoué est doublé avant que l'augmentation ne devienne constante.

Description Le délai entre les nouvelles tentatives sera doublé maxDoublings fois.

L'intervalle de relance d'un job commence à minBackoffDuration, puis double maxDoublings fois, augmente ensuite de manière linéaire, après quoi les tâches sont relancées à des intervalles de maxBackoffDuration jusqu'à retryCount fois. Exemple :

Si minBackoffDuration est de 10 s, maxBackoffDuration de 300 s et maxDoublings de 3 :

  1. La tâche fera d'abord l'objet d'une nouvelle tentative dans 10 secondes.
  2. L'intervalle entre les tentatives sera doublé trois fois.
  3. L'intervalle entre les tentatives augmentera ensuite de manière linéaire de 2^3 * 10 s.
  4. Le cas échéant, la tâche sera relancée à intervalles de maxBackoffDuration jusqu'à ce qu'elle ait été tentée retryCount fois (5 fois maximum).

Les requêtes seront donc relancées à 10, 20, 40, 80 et 160 secondes.

Si minBackoffDuration est égal à 10 s, maxBackoffDuration à 120 s et maxDoublings à 2 :

  1. La tâche fera d'abord l'objet d'une nouvelle tentative dans 10 secondes.
  2. L'intervalle entre les tentatives sera doublé deux fois.
  3. L'intervalle entre les tentatives augmentera ensuite de manière linéaire de 2^3 * 10 s.
  4. Le cas échéant, la tâche sera relancée à intervalles de maxBackoffDuration jusqu'à ce qu'elle ait été tentée retryCount fois (5 fois maximum).

Les requêtes seront donc relancées après 10 s, 20 s, 40 s, 120 s et 120 s.
Par défaut La valeur par défaut est 5.
Libellé de la console Nombre maximal de doublements
Option de la CLI --max-doublings
Champ de l'API maxDoublings

Exemples de nouvelles tentatives

Les exemples suivants illustrent le comportement de réessai lorsqu'un job Cloud Scheduler ne se termine pas correctement.

Si retryCount et maxRetryDuration ne sont pas définis

Les deux paramètres sont définis sur 0 par défaut, et le job n'est pas relancé.

Notez que Cloud Scheduler tentera d'exécuter le job à la prochaine heure d'exécution programmée.

Si retryCount et maxRetryDuration sont définis

Le job fera l'objet d'au moins retryCount nouvelles tentatives jusqu'à atteindre maxRetryDuration.

Notez que le job peut être relancé plus de fois que la valeur retryCount.

Si retryCount est défini et que maxRetryDuration ne l'est pas

Le paramètre maxRetryDuration est défini sur 0 par défaut, et le job sera relancé exactement retryCount fois.

Si retryCount n'est pas défini et que maxRetryDuration l'est

La tâche sera relancée un certain nombre de fois (jusqu'à cinq fois) ou jusqu'à ce que maxRetryDuration soit atteint.