Présentation des index des instances dupliquées avec accès en lecture

Ce document décrit les concepts et les mécanismes de gestion des index secondaires sur les instances répliquées avec accès en lecture Cloud SQL dans les éditions Cloud SQL Enterprise et Cloud SQL Enterprise Plus. Dans MySQL, vous pouvez créer deux principaux types d'index sur une table :

  • Index en cluster : index principal d'une table MySQL qui classe physiquement les lignes sur le disque. Lorsque vous définissez une clé primaire sur une table, MySQL l'utilise comme index en cluster. Une table ne peut avoir qu'un seul index clusterisé.

  • Index secondaire : index supplémentaire sur une table MySQL qui optimise les performances des requêtes.

    Bien qu'une instance répliquée soit normalement en lecture seule, vous pouvez créer des index secondaires sur les tables à des fins de reporting. Cloud SQL accepte deux méthodes pour créer des index secondaires d'instance répliquée :

    • Index d'instance répliquée gérés (recommandé) : Cloud SQL stocke les définitions d'index sur l'instance principale et recrée automatiquement les index secondaires après un plantage ou une recréation de l'instance répliquée. Google recommande d'utiliser des index gérés plutôt que des index autogérés pour éviter la perte d'index et la restauration manuelle des index.
    • Index d'instances répliquées autogérés : vous permettent d'ajouter et de supprimer des index secondaires directement sur une instance répliquée, mais ces index ne sont pas conservés après un plantage ou une recréation de l'instance répliquée. Si vous utilisez des index autogérés, vous pouvez migrer vers des index d'instances répliquées gérés.

Comparer les méthodes d'indexation des instances répliquées

Le tableau suivant compare les index d'instances dupliquées gérées et les index d'instances dupliquées autogérées dans Cloud SQL :

Fonctionnalité Index d'instances répliquées gérés Index d'instances répliquées autogérés
Persistance lors de la recréation d'une instance répliquée Reconstruction automatique Supprimé (recompilation manuelle requise)
Modèle de configuration Métadonnées centralisées sur l'instance principale DDL direct sur l'instance répliquée avec accès en lecture cible
Mécanisme d'exécution Processus périodique en arrière-plan
(environ toutes les cinq minutes)		 Exécution immédiate
Garde-fous pour le délai de réplication Met automatiquement en pause la création d'index si le délai de réplication dépasse 20 minutes Aucune (gérée par l'utilisateur)
Éditions compatibles Éditions Cloud SQL Enterprise et Cloud SQL Enterprise Plus Éditions Cloud SQL Enterprise et Cloud SQL Enterprise Plus
Versions de base de données compatibles Cloud SQL pour MySQL
(version de maintenance R20260726.00_05 ou ultérieure)		 Cloud SQL pour MySQL
(toutes les versions compatibles)
Compatibilité avec les instances répliquées de serveur externe Non compatible Compatible

Index d'instances répliquées gérés

Pour éviter la perte d'index après la recréation d'une instance répliquée, Cloud SQL accepte les index d'instances répliquées gérés. Google recommande cette méthode de création et de conservation des index. Cloud SQL active cette méthode par défaut.

Les index d'instances dupliquées gérées nécessitent la version de maintenance Cloud SQL R20260726.00_05 ou ultérieure.

Les sections suivantes décrivent comment Cloud SQL gère les index d'instances répliquées, leurs avantages et leur comportement lors des événements de cycle de vie.

Comment Cloud SQL gère les index des instances dupliquées gérées

Avec cette méthode, vous définissez des index secondaires d'instances répliquées, vous les regroupez et vous désignez les instances répliquées qui peuvent gérer ces groupes d'index. Cloud SQL exécute un processus en arrière-plan sur l'instance répliquée pour créer et supprimer automatiquement les index requis, et les gérer au fil du temps. Lorsque Cloud SQL crée un index d'instance répliquée gérée, il ajoute un tag [SIC_X_Y] au commentaire de l'index, où X et Y sont des entiers. Ce tag est utilisé uniquement pour la gestion interne et n'a aucune fonctionnalité.

Cloud SQL effectue la maintenance des index des instances dupliquées gérées, comme la création et la suppression d'index, par lots. Une fois que le processus de maintenance des index Cloud SQL a récupéré un groupe d'actions CREATE ou DROP, il crée une entrée d'état PENDING pour chaque index secondaire. Il exécute ensuite en série chaque instruction du langage de définition de données (LDD). Un échec sur un index ne bloque pas l'exécution des index suivants dans la file d'attente. Cloud SQL récupère ensuite le lot suivant après environ cinq minutes.

Avantages et cas d'utilisation

Les index d'instances répliquées gérés offrent les avantages suivants :

  • Conservation automatisée des index : lorsque Cloud SQL recrée une instance répliquée avec accès en lecture (par exemple, après un plantage d'instance), Cloud SQL recrée automatiquement les index secondaires mappés à cette instance répliquée. Vous n'avez pas besoin d'exécuter des procédures stockées manuelles ni de gérer des scripts de suivi de schéma externes pour restaurer les index manquants.
  • Performances des requêtes cohérentes : en recréant automatiquement les index secondaires après la récupération de l'instance répliquée, Cloud SQL maintient le débit des requêtes et évite les pics de latence des requêtes et l'utilisation élevée du processeur causés par les requêtes non indexées.
  • Configuration basée sur des groupes : vous définissez les index secondaires une fois sur l'instance principale et les organisez en groupes d'instances répliquées nommés. Vous pouvez ensuite attribuer un groupe d'index contenant des centaines d'index à une instance répliquée avec accès en lecture en définissant un seul indicateur de base de données (cloudsql_index_recreate_replica_group). Cela évite d'avoir à exécuter des procédures stockées individuelles sur plusieurs instances répliquées.
  • Attribution sélective d'index par rôle d'instance répliquée : vous pouvez attribuer des groupes d'index spécifiquement aux instances répliquées avec accès en lecture de reporting et d'analyse pour accélérer les requêtes de lecture, tout en conservant les instances répliquées avec accès en lecture de reprise après sinistre (DR) non indexées et identiques au schéma de l'instance principale. Cela évite les surcoûts liés aux transactions d'écriture et le délai de réplication sur les instances de DR.
  • Isolation des performances de l'instance principale : les index secondaires sur les instances répliquées avec accès en lecture optimisent les requêtes de lecture et de reporting sans consommer d'espace de stockage ni ajouter de latence de transaction d'écriture à l'instance principale.
  • Observabilité intégrée : des procédures stockées dédiées vous permettent de surveiller la progression de la création de l'index, la durée d'exécution et les journaux d'erreurs sur l'instance répliquée avec accès en lecture.
  • Migration et coexistence sans interruption : les index d'instances répliquées gérées coexistent en toute sécurité avec les index d'instances répliquées autogérées existants sur la même instance et la même table. Vous pouvez adopter des index d'instances répliquées gérées de manière incrémentielle sans temps d'arrêt ni interruption des charges de travail de requêtes de lecture actives.

Promotion d'une instance répliquée

Cloud SQL gère les index d'instances dupliquées gérées uniquement sur les instances dupliquées avec accès en lecture. Si vous promouvez une instance répliquée avec accès en lecture en instance principale, Cloud SQL supprime automatiquement tous les index secondaires créés en tant qu'index d'instance répliquée gérés. Un délai d'environ cinq minutes peut s'écouler avant que Cloud SQL n'exécute la suppression.

Bien que Cloud SQL supprime les index secondaires et les indicateurs de base de données de l'instance promue, l'instance principale conserve les définitions d'index secondaires et les mappages de groupes.

Commutation de reprise après sinistre (DR)

Lors d'une commutation de DR, lorsque vous promouvez l'instance répliquée de DR en tant que nouvelle instance principale, Cloud SQL supprime automatiquement tous les index secondaires créés sur l'instance répliquée de DR. Cloud SQL ne crée pas automatiquement ces index secondaires sur l'ancienne instance principale lorsqu'elle devient une instance répliquée.

Pour créer des index secondaires sur l'ancienne instance principale après la commutation, définissez l'indicateur de base de données cloudsql_index_recreate_replica_group sur cette instance.

Délai avant réplication

Cloud SQL suspend les opérations de création d'index secondaires si le délai de réplication dépasse 20 minutes. Si la création de l'index de l'instance répliquée gérée est déjà en cours lorsque le délai dépasse 20 minutes, Cloud SQL laisse l'opération se terminer. Le délai de réplication ne suspend pas les opérations de suppression d'index de l'instance dupliquée gérée.

Limites

Lorsque vous utilisez des index d'instances répliquées gérées, les limites suivantes s'appliquent :

  • Vous ne pouvez pas créer d'index d'instance répliquée gérée sur des instances répliquées de serveur externe : Cloud SQL ne permet pas de créer des index d'instance répliquée gérée pour les instances répliquées de serveur externe.
  • La mise à jour ou la modification des métadonnées d'index n'est pas possible : vous ne pouvez pas mettre à jour ni modifier les métadonnées d'index existantes. Pour modifier un index, vous devez supprimer la définition d'index existante et en créer une autre.

Index d'instances répliquées autogérés

Les index d'instances dupliquées autogérés sont des index secondaires que vous créez et supprimez directement sur des instances dupliquées avec accès en lecture Cloud SQL individuelles. Comme les index d'instances répliquées gérées, ils optimisent les performances des requêtes de lecture (par exemple, pour les charges de travail de reporting et d'analyse) sans consommer d'espace de stockage ni affecter la latence d'écriture sur l'instance principale.

Gestion des index autogérés

Vous gérez les index d'instances répliquées autogérés directement sur l'instance répliquée avec accès en lecture à l'aide des procédures stockées suivantes dans le schéma mysql :

  • mysql.addSecondaryIdxOnReplica : ajoute un index secondaire sur une table spécifiée de l'instance répliquée avec accès en lecture. Cette procédure stockée est un wrapper pour l'instruction LDD CREATE INDEX.
  • mysql.dropSecondaryIdxOnReplica : supprime un index secondaire précédemment créé de l'instance répliquée avec accès en lecture. Cette procédure stockée est un wrapper pour l'instruction LDD DROP INDEX.

L'exécution de ces procédures stockées nécessite le rôle cloudsqlsuperuser.

Lorsque vous créez un index autogéré, Cloud SQL enregistre les métadonnées de base dans la table mysql.cloudsql_replica_index de l'instance répliquée, y compris le nom de la base de données, le nom de la table et le nom de l'index. Contrairement aux index d'instances répliquées gérés, les index autogérés ne sont pas enregistrés sur l'instance principale et ne sont pas gérés par le processus de réplication en arrière-plan de Cloud SQL.

Pour en savoir plus sur la syntaxe et obtenir des exemples d'utilisation, consultez Index d'instances répliquées autogérés.

Avantages et cas d'utilisation

Les index d'instances répliquées autogérés offrent les avantages suivants pour des workflows spécifiques :

  • Isolation des performances de l'instance principale : les index secondaires sur les instances répliquées avec accès en lecture optimisent les requêtes de lecture et de reporting sans consommer d'espace de stockage ni ajouter de latence de transaction d'écriture à l'instance principale.
  • Exécution immédiate : les appels de procédures stockées s'exécutent immédiatement en tant qu'instructions LDD sur l'instance répliquée, sans attendre le cycle de maintenance périodique en arrière-plan (environ toutes les cinq minutes) requis par les index d'instances répliquées gérées.
  • Tests et expérimentations isolés : vous pouvez tester les performances des requêtes et valider les optimisations d'index sur une instance répliquée avec accès en lecture individuelle avant de créer des index d'instances répliquées gérés dans un groupe d'instances répliquées.

Limites

Les index d'instances répliquées autogérés présentent des limites opérationnelles importantes :

  • Manque de persistance lors de la recréation de l'instance répliquée : si Cloud SQL recrée une instance répliquée avec accès en lecture (par exemple, lors de la récupération d'une instance, d'une maintenance ou d'une défaillance matérielle), tous les index secondaires autogérés sur cette instance répliquée sont supprimés et ne sont pas restaurés automatiquement.
  • Surcharge de restauration manuelle : Cloud SQL ne peut pas reconstruire ni recompiler les index. Vous devez recréer manuellement les index en exécutant à nouveau mysql.addSecondaryIdxOnReplica.
  • Dégradation des performances des requêtes : les requêtes de lecture peuvent subir une dégradation des performances après la recréation de l'instance répliquée, jusqu'à ce que vous recréiez manuellement les index manquants.

Étant donné que les index d'instances répliquées gérées sont automatiquement conservés et recréés lors des événements de recréation d'instances répliquées, Google recommande d'utiliser des index d'instances répliquées gérées pour les charges de travail de production. Si vous disposez d'index autogérés, migrez-les vers des index d'instances répliquées gérés.

Coexistence des types d'index d'instance répliquée

Les index d'instances répliquées autogérés (créés à l'aide de mysql.addSecondaryIdxOnReplica) et les index d'instances répliquées gérés peuvent coexister sur la même instance répliquée avec accès en lecture Cloud SQL et sur la même table. Vous pouvez ainsi adopter progressivement des index d'instances répliquées gérées sans perturber les charges de travail de base de données existantes.

Lorsque vous utilisez les deux méthodes de gestion des index, tenez compte des comportements suivants :

  • Fonctionnement indépendant : les index autogérés que vous créez directement sur l'instance dupliquée avec accès en lecture continuent de fonctionner parallèlement aux index d'instance dupliquée gérés.
  • Évaluation périodique : le processus de maintenance en arrière-plan de Cloud SQL évalue régulièrement (environ toutes les cinq minutes) les définitions d'index mappées au groupe d'instances dupliquées que vous attribuez à l'instance dupliquée.
  • Gestion des conflits de noms : si vous enregistrez une définition d'index d'instance répliquée gérée portant le même nom qu'un index autogéré existant sur l'instance répliquée avec accès en lecture, le processus en arrière-plan détecte qu'un index portant ce nom existe déjà. Le processus enregistre l'état FAILED dans la table mysql.cloudsql_replica_idx_status. Cette erreur n'affecte pas le trafic de la base de données, ne crée pas de verrouillage de table et n'affecte pas l'index autogéré existant.
  • Résolution automatique lors de la recréation : lorsque l'instance répliquée avec accès en lecture est recréée, Cloud SQL supprime l'index autogéré existant lors de la recréation de l'instance et crée automatiquement l'index de l'instance répliquée gérée à partir de la définition enregistrée.

Étapes suivantes