Maintenance de la base de données de réplication

Une base de données de réplication doit être surveillée à l'instar de n'importe quelle autre base de données. Sans maintenance régulière, vous risquez d'accumuler des documents non valides générés par des interruptions du processus de réplication. Un nombre élevé de documents non valides peut entraîner une charge excessive sur votre cluster lorsque des opérations IBM® Cloudant® for IBM Cloud® redémarrent le processus de réplicateur.

Pour assurer la maintenance d'une base de données de réplication, retirez les anciens documents. Vous pouvez retirer les anciens documents en déterminant leur ancienneté et en les supprimant s'ils ne sont plus nécessaires.

Planificateur de réplication

Le nouveau planificateur de réplication IBM Cloudant présente plusieurs améliorations par rapport au mécanisme de réplication d'IBM Cloudant précédent.

En particulier, l'utilisation du réseau au cours de la réplication est plus efficace. Le planificateur prend en compte la charge en cours pour les noeuds de base de données individuels dans un cluster lorsqu'il détermine l'allocation des tâches de réplication.

Enfin, l'état d'une réplication est désormais plus détaillé et se compose de sept états distincts :

1. initializing : la réplication a été ajoutée au planificateur mais celle-ci n'a pas encore été initialisée ou son exécution n'a pas encore été planifiée. Ce statut est indiqué lorsqu'un document de réplication nouveau ou mis à jour est stocké dans la base de données _replicator.
2. error : la réplication ne peut pas être transformée en travail. Cette erreur peut avoir plusieurs causes. Par exemple, la réplication doit être filtrée, mais il n'a pas été possible d'extraire le code de filtre depuis la base de données source.
3. pending : l'exécution du travail de réplication a été planifiée, mais le travail de réplication n'est pas encore en cours d'exécution.
4. running : le travail de réplication est en cours d'exécution.
5. crashing : une erreur temporaire affectant le travail de réplication est survenue. Le travail sera relancé ultérieurement.
6. completed : le travail de réplication est terminé. Cet état ne s'applique pas aux réplications continues.
7. failed : le travail de réplication a échoué. L'échec est permanent. Cet état signifie qu'aucune autre tentative de réplication ne sera effectuée avec cette tâche de réplication. Cet échec peut avoir plusieurs causes ; par exemple, les URL source ou cible peuvent ne pas être valides.

La transition entre ces états est illustrée dans le diagramme suivant :

Le planificateur introduit deux nouveaux noeuds finaux :

• /_scheduler/docs
• /_scheduler/jobs

Vous pouvez gérer et déterminer le statut de réplication plus rapidement et plus facilement à l'aide de ces noeuds finaux.

Voici le processus classique d'utilisation du planificateur de réplication pour gérer et surveiller les réplications :

1. Créez un document de réplication décrivant la réplication requise, puis enregistrez-le dans la base de données du réplicateur.
2. Surveillez le statut de la réplication à l'aide du noeud final /_scheduler/docs.

Authentification au cours de la réplication

Dans toute application de production, la sécurité des bases de données source et cible est essentielle. Pour que la réplication continue, l'authentification est nécessaire pour accéder aux bases de données. Les points de contrôle de réplication sont activés par défaut, ce qui signifie que la réplication de la base de données source nécessite un accès en écriture.

Pour activer l'authentification au cours de la réplication, incluez un nom d'utilisateur et un mot de passe dans l'URL de base de données. Le processus de réplication utilise les valeurs fournies pour l'authentification HTTP de base.

Voici un exemple illustrant la spécification d'un nom d'utilisateur et d'un mot de passe pour l'accès aux bases de données source et cible au cours de la réplication :

{
  "source": {
    "url": "https://example.com/db",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "target": {
    "url": "https://$ACCOUNT.cloudant.com/db",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  }
}

Pour les informations d'identification IAM, utilisez l'exemple ci-dessous pour vous authentifier avec une clé API IAM :

{
  "source": {
    "url": "https://example.com/db",
    "auth": {
      "iam": {
        "apikey": "$APIKEY"
      }
    }
  },
  "target": {
    "url": "https://$ACCOUNT.cloudant.com/db",
    "auth": {
      "iam": {
        "apikey": "$APIKEY"
      }
    }
  }
}

Réplication filtrée

Il peut arriver que vous ne souhaitiez pas transférer tous les documents de la source vers la cible. Pour choisir les documents à transférer, incluez une ou plusieurs fonctions de filtrage dans un document de conception dans la source. Vous pouvez alors demander au réplicateur d'utiliser ces fonctions de filtrage.

Le filtrage des documents au cours de la réplication est similaire au processus de filtrage du flux _changes.

Une fonction de filtrage admet deux arguments :

• Le document à répliquer.
• La demande de réplication.

Une fonction de filtrage renvoie une valeur true ou false. Si le résultat est true, cela signifie que le document a été répliqué.

Pour configurer le filtrage, utilisez la zone selector, si possible. Lorsque vous utilisez la zone selector, vous pouvez spécifier un filtre sans avoir à répliquer la totalité de la base de données. Cette méthode permet un filtrage plus rapide et implique une charge moins élevée sur IBM Cloudant. Pour plus d'informations, consultez la documentation relative au champ « selector ».

Reportez-vous à l'exemple de fonction de filtrage suivant :

function(doc, req) {
	return !!(doc.type && doc.type == "foo");
}

Les filtres sont stockés sous la clé filters supérieure du document de conception.

Voici un exemple de stockage d'une fonction de filtrage dans un document de conception :

{
	"_id": "_design/myddoc",
	"filters": {
		"myfilter": "function goes here"
	}
}

Une réplication filtrée est démarrée à l'aide d'une instruction JSON qui identifie les éléments suivants :

• La base de données source.
• La base de données cible.
• Le nom du filtre qui est stocké sous la clé filters dans le document de conception.

Voici un exemple de JSON de démarrage d'une réplication filtrée :

{
  "source": {
    "url": "https://example.org/example-database",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "target": {
    "url": "https://$ACCOUNT.cloudant.com/example-database",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "filter": "myddoc/myfilter"
}

Vous pouvez fournir des arguments à la fonction de filtrage en incluant des paires clé: valeur dans la zone query_params de l'appel.

Voici un exemple de JSON de démarrage d'une réplication filtrée avec spécification de paramètres :

{
  "source": {
    "url": "https://example.org/example-database",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "target": {
    "url": "https://$ACCOUNT.cloudant.com/example-database",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "filter": "myddoc/myfilter",
  "query_params": {
    "key": "value"
  }
}

L'option selector fournit des avantages de performances par rapport à l'utilisation de l'option filter. Utilisez l'option selector dans la mesure du possible.Pour plus d'informations, consultez la selector documentation.

{
	"source": {
	  "url": "https://example.org/example-database",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"target": {
	  "url": "https://$ACCOUNT.cloudant.com/example-database",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"winning_revs_only": true
}

Réplication de document nommé

Il peut arriver que vous ne souhaitiez pas répliquer des documents. Pour les réplications simples, il n'est pas nécessaire d'écrire une fonction de filtrage. A la place, pour répliquer des documents spécifiques, ajoutez la liste des clés sous forme de tableau dans la zone doc_ids.

Voici un exemple de réplication de documents spécifiques :

{
	"source": {
	  "url": "https://example.org/example-database",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"target": {
	  "url": "https://127.0.0.1:5984/example-database",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"doc_ids": ["foo", "bar", "baz"]
}

Propriété user_ctx et délégations

La propriété user_ctx des documents de réplication peut être personnalisée. Elle définit le contexte utilisateur dans lequel s'exécute une réplication.

L'ancienne manière de déclencher une réplication, en envoyant une demande POST au noeud final /_replicate/, ne nécessite pas la propriété user_ctx. En effet, au moment du déclenchement de la réplication, toutes les informations requises concernant l'utilisateur authentifié sont disponibles.

En revanche, la base de données du réplicateur est une base de données standard. Les informations relatives à l'utilisateur authentifié ne sont présentes qu'au moment où le document de réplication est enregistré dans la base de données. En d'autres termes, l'implémentation de la base de données du réplicateur est similaire à une application de consommation du flux _changes, avec le paramètre ?include_docs=true défini.

En matière de réplication, cette différence de mise en œuvre implique que, pour les utilisateurs non administrateurs, une propriété « user_ctx » comprenant le nom de l'utilisateur et un sous-ensemble de ses rôles doit être définie dans le document de réplication. Cette exigence est traitée par une fonction de validation présente dans le document de conception par défaut de la base de données du réplicateur. La fonction valide chaque mise à jour de document. Cette fonction de validation garantit également qu'un utilisateur non administrateur ne peut pas définir, dans la propriété « user_ctx », un nom d'utilisateur qui ne correspond pas au nom d'utilisateur correct. Le même principe s'applique aux rôles.

Reportez-vous à l'exemple de document de réplication délégué suivant :

{
	"_id": "my_rep",
	"source": {
	  "url": "https://$SERVER.com:5984/foo",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"target": {
	  "url": "https://$ACCOUNT.cloudant.com/bar",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"continuous":  true,
	"user_ctx": {
		"name": "joe",
		"roles": ["erlanger", "researcher"]
	}
}

Pour les administrateurs, la propriété user_ctx est facultative. Si la propriété manque, la valeur est par défaut un contexte utilisateur dont le nom est null et dont la liste de rôles est vide.

La liste de rôles vide signifie que les documents de conception ne sont pas écrits dans les cibles locales au cours de la réplication. Si vous voulez écrire les documents de conception dans des cibles locales, un contexte utilisateur avec le rôle _admin doit être défini explicitement.

De plus, pour les administrateurs, la propriété user_ctx peut être utilisée afin de déclencher une réplication pour un autre utilisateur. Ce contexte utilisateur est transmis aux fonctions de validation des documents de la base de données cible locale.

La propriété user_ctx s'applique aux noeuds finaux locaux uniquement.

En résumé, pour les administrateurs, la propriété « user_ctx » est facultative. Alors que pour les utilisateurs standard (non-administrateurs), c'est obligatoire. Lorsque la propriété des rôles de user_ctx manque, la valeur par défaut est une liste vide [ ].

Options liées aux performances

Vous pouvez définir plusieurs options liées aux performances pour une réplication en les incluant dans le document de réplication.

use_bulk_get

Défini sur true pour améliorer les performances des travaux de réplication. Une réplication extrait des documents par lots de la source. L'augmentation du taux de réplication peut consommer plus rapidement la capacité des comptes source et cible et entraîner un plus grand nombre d'erreurs dans les demandes concurrentes de non-réplication sur ces comptes 429 HTTP erreurs.

connection_timeout

Durée maximale d'inactivité pour une connexion en millisecondes. Si une connexion est inactive pendant cette durée, sa demande en cours est renvoyée. La valeur par défaut est 30000 millisecondes (30 secondes).

http_connections

Nombre maximal de connexions HTTP par réplication. Pour les réplications push, le nombre effectif de connexions HTTP qui sont utilisées est min(worker_processes + 1, http_connections). Pour les réplications pull, le nombre effectif de connexions qui sont utilisées correspond à la valeur de ce paramètre. La valeur par défaut est 20.

retries_per_request

Nombre maximal de tentatives par demande. Avant une nouvelle tentative, le réplicateur patiente pendant une courte période avant de relancer la demande. Cette période double entre chaque nouvelle tentative consécutive et ne dépasse jamais 5 minutes. La valeur minimale avant la première nouvelle tentative est 0,25 secondes. La valeur par défaut est 10 tentatives.

socket_options

Liste d'options à transmettre aux sockets de connexion. Les options disponibles sont décrites dans la documentation de la fonction Erlang setopts du module inet . La valeur par défaut est [{keepalive, true},{nodelay, false}].

worker_batch_size

Des processus worker exécutent des lots de tâches de réplication, dont la taille est définie par ce paramètre. Celle-ci correspond au nombre de lignes de flux _changes. Des valeurs de taille de lot plus élevées peuvent améliorer les performances. Avec des valeurs plus faibles, les points de contrôle sont plus fréquents. La valeur par défaut est 500.

worker_processes

Nombre de processus que le réplicateur utilise dans chaque tâche de réplication pour transférer des documents de la base de données source vers la base de données cible. Des valeurs plus élevées peuvent permettre un meilleur débit en raison d'un meilleur parallélisme des activités du réseau et d'E-S sur le disque, mais cette amélioration a un coût : elle requiert davantage de mémoire et potentiellement plus de temps d'UC. La valeur par défaut est 4.

Voici un exemple qui inclut des options de performance dans un document de réplication :

{
	"source": {
	  "url": "https://example.com/example-database",
	  "auth": {
	    "basic": {
	      "username": "$ACCOUNT1",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"target": {
	  "url": "https://example.org/example-database",
	  "auth": {
	    "basic": {
	      "username": "$ACCOUNT2",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"connection_timeout": 60000,
	"retries_per_request": 20,
	"http_connections": 30
}

Effet d'un grand nombre de pièces jointes

Si de nombreuses pièces jointes sont associées à des documents, l'effet sur les performances de la réplication peut être négatif.

Pour plus d'informations sur l'effet des pièces jointes sur les performances de la réplication, voir Remarques sur les performances.