Index de résolution des problèmes

Les rubriques suivantes expliquent la procédure à suivre en cas d'échec de la génération de votre index ou de votre index d'arrière-plan.

La création de l'index échoue

Amazon DocumentDB utilise le stockage local sur une instance dans le cadre du processus de création d'index. Vous pouvez surveiller cette utilisation du disque à l'aide de la FreeLocalStorage CloudWatch métrique (CloudWatch -> Metrics -> DocDB -> Instance Metrics). Lorsque la génération d'un index utilise l'ensemble du disque local et échoue, vous recevez une erreur. Lorsque vous migrez des données vers Amazon DocumentDB, nous vous encourageons à créer d'abord des index, puis à insérer les données. Pour plus d'informations sur les stratégies de migration et la création d'index, consultez Migration vers Amazon DocumentDB la documentation Amazon DocumentDB et le blog : Migrer de MongoDB vers Amazon DocumentDB en utilisant la méthode hors ligne.

Lorsque vous créez des index sur un cluster existant, si la création de l'index prend plus de temps que prévu ou échoue, nous vous recommandons de redimensionner l'instance pour créer l'index, puis de la réduire une fois l'index créé. Amazon DocumentDB vous permet de redimensionner rapidement la taille des instances en quelques minutes à l'aide du AWS Management Console ou du. AWS CLI Pour de plus amples informations, veuillez consulter Gestion des classes d'instances. Avec la tarification des instances à la seconde, vous payez seulement pour les ressources que vous utilisez à la seconde près.

Problèmes et échecs de latence lors de la création de l'index d'arrière-plan

Les compilations d'index en arrière-plan dans Amazon DocumentDB ne démarrent que lorsque toutes les requêtes sur l'instance principale lancées avant le lancement de la génération d'index ne sont terminées. Si la requête est longue, les compilations d'index en arrière-plan seront bloquées jusqu'à la fin de la requête et peuvent donc prendre plus de temps que prévu. Cela est vrai même si les collections sont vides.

Les constructions d'index de premier plan ne présentent pas le même comportement de blocage. Au lieu de cela, les constructions d'index de premier plan bloquent exclusivement la collection jusqu'à ce que la création de l'index soit terminée. Ainsi, pour créer des index sur une collection vide et éviter de bloquer les requêtes de longue durée, nous vous suggérons d'utiliser des versions d'index de premier plan.

Note

Amazon DocumentDB autorise la création d'un seul index d'arrière-plan sur une collection à la fois. Si les opérations DDL (langage de définition de données) telles que createIndex() ou dropIndex() se produisent pendant la génération d'un index d'arrière-plan, celle-ci échoue.

Surcharge de l'index de base de données

Amazon DocumentDB utilise le contrôle de concurrence multiversion (MVCC) pour gérer les transactions simultanées. Lorsque des documents sont supprimés ou mis à jour, leurs versions précédentes restent dans les collections et les index en tant que versions « mortes ». Le processus de collecte des déchets permet de récupérer automatiquement de l'espace dans ces versions mortes pour les opérations futures.

Le gonflement des index se produit lorsque les index d'une collection augmentent en raison de l'accumulation d'entrées d'index mortes ou obsolètes ou de la fragmentation des pages. Le pourcentage indiqué représente la quantité d'espace d'index qui peut être utilisée par les futures entrées d'index. Cette surcharge consomme de l'espace à la fois dans le cache tampon et dans le stockage. Si vous souhaitez supprimer le surmenage, vous devez reconstruire les index.

Exemple exemple

Exécutez la commande suivante pour déterminer le stockage inutilisé pour votre index :

db.coll.aggregate({$indexStats:{}});

Le résultat ressemble à ceci :

{ 
    "name" : "_id_",
    "key" : { 
        "_id" : 1 
    },
    "host" : "devbox-test.localhost.a2z.com:27317",
    "size" : NumberLong(827392),
    "accesses" : {
        "ops" : NumberLong(40000),
        "docsRead" : NumberLong(46049),
        "since" : ISODate("2025-04-03T21:44:51.251Z") 
    },
    "cacheStats" : {
        "blksRead" : NumberLong(264),
        "blksHit" : NumberLong(140190),
        "hitRatio" : 99.8121
    }, 
    "unusedStorageSize" : {
        "unusedSizeBytes" : 409600,
        "unusedSizePercent" : 49.51
    }
}

Vous pouvez reconstruire les index sans interruption à l'aide de la reIndex commande, qui nécessite une analyse de l'ensemble de la collection. Consultez Maintenance de l'index en utilisant reIndex.