Une configuration incorrecte des paramètres de l'oplog pour une instance ApsaraDB for MongoDB peut entraîner des problèmes tels qu'une réplication primaire-secondaire anormale et empêcher les restaurations à un instant donné. Découvrez comment configurer les paramètres de l'oplog et comprendre les risques associés.
Présentation
Dans les instances de type replica set ApsaraDB for MongoDB, la réplication des données passe par l'oplog (operations log), une capped collection nommée local.oplog.rs qui enregistre toutes les opérations modifiant les documents. Caractéristiques principales :
Les opérations d'écriture sur le nœud primaire génèrent des entrées dans l'oplog. Les nœuds secondaires répliquent et rejouent ces entrées de manière asynchrone pour rester synchronisés.
Les opérations qui ne modifient pas les documents ou qui échouent ne génèrent aucune entrée dans l'oplog.
Les entrées de l'oplog sont identiques sur tous les membres du replica set. L'application d'une entrée ne modifie pas l'entrée elle-même.
Chaque opération de l'oplog est idempotente : le résultat est le même, qu'elle soit appliquée une seule fois ou plusieurs fois.
Les entrées de l'oplog sont ordonnées chronologiquement. Chacune possède un champ d'horodatage unique (ts) combinant un horodatage UNIX et un compteur incrémentiel, garantissant un ordre strict.
La
oplog windowcorrespond à l'intervalle de temps entre l'entrée la plus ancienne et la plus récente de l'oplog. Un nœud secondaire ne peut se synchroniser que si l'entrée de départ requise se trouve dans la fenêtre d'oplog de la source de réplication.Les nœuds redémarrés ou nouvellement ajoutés s'appuient également sur les entrées de l'oplog pour rejoindre le replica set. Si l'entrée requise est manquante, le nœud passe dans un état RECOVERING anormal avec une erreur
too stale to catch up.
Taille de l'oplog
Dans ApsaraDB for MongoDB, la taille par défaut de l'oplog représente 10 % de l'espace disque total. Par exemple, un disque de 500 Go offre un oplog de 50 Go. La taille de l'oplog augmente automatiquement lorsque vous augmentez l'espace disque.
Pour ajuster la taille de l'oplog, modifiez le paramètre replication.oplogSizeMB dans la console. La modification prend effet immédiatement sans redémarrage. Définir les paramètres de base de données.
Pour vérifier la taille de la table d'oplog :
Consultez la métrique Disk Usage sur la page de surveillance de la console. Surveillance des nœuds (anciennement Surveillance de base).
-
Connectez-vous avec mongo shell ou mongosh et exécutez la commande suivante.
rs.printReplicationInfo()Exemple de sortie :
configured oplog size: 192MB log length start to end: 65422secs (18.17hrs) oplog first event time: Mon Jun 23 2014 17:47:18 GMT-0400 (EDT) oplog last event time: Tue Jun 24 2014 11:57:40 GMT-0400 (EDT) now: Thu Jun 26 2014 14:24:39 GMT-0400 (EDT)Cela indique un oplog de 192 Mo avec une fenêtre d'oplog de 18 heures.
Période minimale de conservation de l'oplog
MongoDB 4.4 a introduit le paramètre storage.oplogMinRetentionHours pour contrôler la période minimale de conservation de l'oplog et garantir une fenêtre d'oplog suffisante.
La valeur par défaut est 0 (aucune conservation minimale ; le nettoyage est contrôlé par la taille de l'oplog). Lorsqu'il est défini, le nettoyage de l'oplog n'a lieu que si les deux conditions suivantes sont remplies :
L'utilisation de l'oplog dépasse la valeur configurée pour
oplogSizeMB.Les horodatages des entrées sont antérieurs à la période minimale de conservation de l'oplog.
Avant que l'oplog n'atteigne la valeur oplogSizeMB (par exemple, sur une nouvelle instance), la fenêtre d'oplog réelle peut dépasser la période minimale de conservation configurée, et la taille est limitée uniquement par oplogSizeMB. Une fois la valeur oplogSizeMB atteinte, la période de conservation régit le nettoyage. Des taux d'écriture élevés peuvent entraîner une croissance de l'oplog bien au-delà de oplogSizeMB.
Pour ajuster la période de conservation, modifiez storage.oplogMinRetentionHours dans la console. La modification prend effet immédiatement sans redémarrage. Définir les paramètres de base de données.
Pour afficher la période de conservation, consultez la métrique Oplog retention duration sur la page de surveillance de la console. Surveillance des nœuds (anciennement Surveillance de base).
Sauvegarde des journaux ApsaraDB for MongoDB
La sauvegarde des journaux pour les instances ApsaraDB for MongoDB utilise l'oplog. Un processus dédié récupère continuellement les dernières entrées de l'oplog et les diffuse vers Object Storage Service (OSS) sous forme de fichiers de sauvegarde de journaux. Lors des restaurations à un instant donné, ces fichiers permettent de rejouer l'oplog.
Dans certains cas, des trous peuvent apparaître dans les sauvegardes de journaux, empêchant les restaurations à un instant donné. Risques.
Le trou de sauvegarde de journal décrit ici diffère du trou d'oplog MongoDB.
Bonnes pratiques
Configurer la taille ou la conservation de l'oplog
La taille par défaut de l'oplog suffit pour la plupart des charges de travail. Envisagez de l'augmenter dans les scénarios suivants :
-
Mises à jour par lots fréquentes
Chaque mise à jour par lot génère plusieurs opérations individuelles, produisant ainsi de nombreuses entrées dans l'oplog.
-
Insertions et suppressions fréquentes
L'utilisation du disque reste stable, mais l'oplog accumule des entrées pour les opérations d'insertion et de suppression.
-
Nombreuses mises à jour sur place des mêmes documents
Les mises à jour qui n'augmentent pas la taille du document génèrent de nombreuses entrées dans l'oplog sans modifier sensiblement l'utilisation du disque.
Envisagez de réduire la taille de l'oplog pour :
Les charges de travail à forte lecture et faible écriture.
Le stockage de données froides.
Maintenez la fenêtre d'oplog à 24 heures ou plus. Pour les scénarios de synchronisation initiale, la fenêtre doit couvrir le temps nécessaire pour copier toutes les données, ce qui dépend du volume de données, du nombre de collections et des spécifications de l'instance. Dans de tels cas, une fenêtre d'oplog plus longue peut être nécessaire.
Surveiller le décalage des nœuds secondaires et configurer des alertes
Si le décalage de réplication dépasse la fenêtre d'oplog, le nœud secondaire entre dans un état d'erreur irrécupérable. Surveillez le décalage de réplication et soumettez un ticket rapidement si le décalage augmente continuellement.
Causes courantes :
Latence réseau, perte de paquets ou interruptions.
Le débit du disque du nœud secondaire constitue un goulot d'étranglement.
Une charge d'écriture élevée combinée à une garantie d'écriture de
{w:1}.Des défauts du noyau qui bloquent la réplication primaire-secondaire sur le nœud secondaire.
D'autres raisons non répertoriées.
Pour vérifier le décalage de réplication :
Consultez la métrique Primary/Secondary Replication Latency sur la page de surveillance de la console. Surveillance des nœuds (anciennement Surveillance de base).
-
Connectez-vous avec mongo shell ou mongosh et exécutez :
rs.printSecondaryReplicationInfo()Exemple de sortie :
source: m1.example.net:27017 syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT) 0 secs (0 hrs) behind the primary source: m2.example.net:27017 syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT) 0 secs (0 hrs) behind the primaryLes deux nœuds secondaires affichent un décalage de réplication nul.
Créez une alerte Cloud Monitor pour la métrique Replication Latency en utilisant la fonctionnalité Alarm Rules. Définissez le seuil à 10 secondes ou plus. Définir une règle d'alerte basée sur un seuil.
Risques
Deux causes principales créent des trous dans les sauvegardes de journaux :
Versions MongoDB antérieures à 3,4
MongoDB 3,4 a introduit des écritures no-op périodiques pour prendre en charge le paramètre de préférence de lecture maxStalenessSeconds (SERVER-23892). Ces écritures no-op font avancer l'oplog pendant les périodes d'inactivité, permettant une mesure précise du décalage pour les nœuds secondaires.
Sur les versions antérieures à 3,4, l'oplog cesse d'avancer pendant les périodes d'inactivité. Le processus de sauvegarde des journaux ne peut pas récupérer de nouvelles données, créant ainsi un trou de sauvegarde qui empêche les restaurations à un instant donné.
Taux d'écriture élevé et fenêtre d'oplog courte
Les données des instances ApsaraDB for MongoDB montrent que lorsque le taux de génération de l'oplog atteint environ 125 Go/h à 165 Go/h, le processus de sauvegarde des journaux risque fortement de prendre du retard, créant ainsi un trou de sauvegarde.
Estimez le taux de génération en divisant la taille de l'oplog par la fenêtre d'oplog. Par exemple, un oplog de 20 Go avec une fenêtre de 0,06 h donne environ 333,3 Go/h.
Scénarios typiques :
Synchronisation des données avec DTS, mongoShake ou des outils similaires.
Grands lots d'opérations INSERT ou UPDATE sur une courte période.
Amorçage des données (importation en masse rapide).
Tests de charge.
Pour éviter les trous de sauvegarde dus à des taux d'écriture élevés :
Appliquez une limitation de débit aux outils de synchronisation en ajustant la concurrence ou la taille des lots.
Utilisez une garantie d'écriture de
{w:"majority"}au lieu de{w:1}.
Pour les charges de travail générant intrinsèquement un taux élevé d'oplog :
Utilisez un cluster shardé ou ajoutez des shards pour répartir le taux de génération de l'oplog.
Augmentez la taille de l'oplog ou la période minimale de conservation pour offrir au processus de sauvegarde plus de marge pour rattraper son retard pendant les périodes de trafic réduit.