Gérer des instances dupliquées avec accès en lecture

Cette page vous explique comment gérer les instances dupliquées avec accès en lecture. Ces opérations incluent la désactivation et l'activation de la réplication, la promotion d'une instance dupliquée, la configuration de la réplication parallèle et la vérification de l'état de réplication.

Pour en savoir plus sur le fonctionnement de la réplication, consultez la page Réplication dans Cloud SQL.

Désactiver la duplication

La réplication est activée par défaut au démarrage d'une instance dupliquée. Toutefois, vous avez la possibilité de désactiver la réplication, par exemple à des fins de débogage ou d'analyse de l'état d'une instance. Lorsque vous êtes prêt, vous pouvez la réactiver de façon explicite. La désactivation ou la réactivation de la réplication ne redémarre pas l'instance dupliquée.

La désactivation de la réplication n'arrête pas l'instance dupliquée. Celle-ci devient une instance avec accès en lecture seule qui ne réplique plus son instance maître. Les frais liés à l'instance continuent de vous être facturés. Sur l'instance dupliquée, vous pouvez réactiver la réplication, la supprimer, ou la promouvoir en instance autonome.

Pour désactiver la réplication, procédez comme suit :

Console

  1. Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez une instance dupliquée en cliquant sur son nom.
  3. Cliquez sur Désactiver la duplication dans la barre de boutons.
  4. Cliquez sur OK.

gcloud

gcloud sql instances patch REPLICA_NAME \
--no-enable-database-replication

REST v1

Pour exécuter cette commande cURL dans une invite de ligne de commande, vous devez obtenir un jeton d'accès à l'aide de la commande gcloud auth print-access-token. Vous pouvez également utiliser APIs Explorer sur la page dédiée à la méthode "instances.patch" pour envoyer la requête d'API REST.

Avant d'utiliser les données de requête, effectuez les remplacements suivants :

  • project-id : ID du projet
  • replica-name : nom de l'instance dupliquée

Méthode HTTP et URL :

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

Corps JSON de la requête :

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

Vous devriez recevoir une réponse JSON de ce type :

REST v1beta4

Pour exécuter cette commande cURL dans une invite de ligne de commande, vous devez obtenir un jeton d'accès à l'aide de la commande gcloud auth print-access-token. Vous pouvez également utiliser APIs Explorer sur la page dédiée à la méthode "instances.patch" pour envoyer la requête d'API REST.

Avant d'utiliser les données de requête, effectuez les remplacements suivants :

  • project-id : ID du projet
  • replica-name : nom de l'instance dupliquée

Méthode HTTP et URL :

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

Corps JSON de la requête :

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

Vous devriez recevoir une réponse JSON de ce type :

Activer la réplication

Lorsqu'une instance dupliquée ne réplique aucune donnée pendant une longue période, il lui faut plus de temps pour rattraper l'instance maître. Dans ce cas, supprimez l'instance dupliquée et créez-en une autre.

Pour activer la réplication, procédez comme suit :

Console

  1. Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez une instance dupliquée en cliquant sur son nom.
  3. Cliquez sur Activer la duplication.
  4. Cliquez sur OK.

gcloud

gcloud sql instances patch REPLICA_NAME \
--enable-database-replication

REST v1

Pour exécuter cette commande cURL dans une invite de ligne de commande, vous devez obtenir un jeton d'accès à l'aide de la commande gcloud auth print-access-token. Vous pouvez également utiliser APIs Explorer sur la page dédiée à la méthode "instances.patch" pour envoyer la requête d'API REST.

Avant d'utiliser les données de requête, effectuez les remplacements suivants :

  • project-id : ID du projet
  • replica-name : nom de l'instance dupliquée

Méthode HTTP et URL :

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

Corps JSON de la requête :

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

Vous devriez recevoir une réponse JSON de ce type :

REST v1beta4

Pour exécuter cette commande cURL dans une invite de ligne de commande, vous devez obtenir un jeton d'accès à l'aide de la commande gcloud auth print-access-token. Vous pouvez également utiliser APIs Explorer sur la page dédiée à la méthode "instances.patch" pour envoyer la requête d'API REST.

Avant d'utiliser les données de requête, effectuez les remplacements suivants :

  • project-id : ID du projet
  • replica-name : nom de l'instance dupliquée

Méthode HTTP et URL :

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

Corps JSON de la requête :

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

Vous devriez recevoir une réponse JSON de ce type :

Promouvoir une instance dupliquée

La promotion d'une instance dupliquée avec accès en lecture entraîne l'arrêt de la réplication et la transformation de l'instance en instance principale Cloud SQL autonome avec accès en lecture et écriture.

Lorsque elles sont promues, les instances dupliquées avec accès en lecture sont automatiquement configurées avec des sauvegardes, mais elles ne sont pas configurées en tant qu'instances à haute disponibilité. Vous pouvez activer la haute disponibilité après leur promotion, comme vous le feriez avec n'importe quelle instance non dupliquée. La configuration d'une instance dupliquée avec accès en lecture pour la haute disponibilité s'effectue de la même manière que pour une instance principale. Découvrez comment configurer l'instance pour la haute disponibilité.

Si l'instance principale est toujours disponible et traite les requêtes des clients, vous devez effectuer les opérations suivantes avant de promouvoir une instance dupliquée avec accès en lecture :

  1. Arrêtez toutes les opérations en écriture sur l'instance principale.
  2. Vérifiez l'état de réplication de l'instance dupliquée (suivez les instructions de l'onglet Client psql).
  3. Vous devez vérifier que l'instance dupliquée est en cours de duplication, puis attendre que le délai de duplication signalé par la métrique replay_lag atteigne 0.

Sinon, il est possible que certaines des transactions validées sur l'instance principale soient manquantes dans l'instance nouvellement promue.

Pour promouvoir une instance dupliquée en instance autonome, procédez comme suit :

Console

  1. Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez une instance dupliquée en cliquant sur son nom.
  3. Cliquez sur Promouvoir une instance dupliquée.
  4. Cliquez sur OK.

gcloud

gcloud sql instances promote-replica REPLICA_NAME

REST v1

Pour exécuter cette commande cURL dans une invite de ligne de commande, vous devez obtenir un jeton d'accès à l'aide de la commande gcloud auth print-access-token. Vous pouvez également utiliser APIs Explorer sur la page dédiée à la méthode "instances.promoteReplica" pour envoyer la requête d'API REST.

Avant d'utiliser les données de requête, effectuez les remplacements suivants :

  • project-id : ID du projet
  • replica-name : nom de l'instance dupliquée

Méthode HTTP et URL :

POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name/promoteReplica

Pour envoyer votre requête, développez l'une des options suivantes :

Vous devriez recevoir une réponse JSON de ce type :

REST v1beta4

Pour exécuter cette commande cURL dans une invite de ligne de commande, vous devez obtenir un jeton d'accès à l'aide de la commande gcloud auth print-access-token. Vous pouvez également utiliser APIs Explorer sur la page dédiée à la méthode "instances.promoteReplica" pour envoyer la requête d'API REST.

Avant d'utiliser les données de requête, effectuez les remplacements suivants :

  • project-id : ID du projet
  • replica-name : nom de l'instance dupliquée

Méthode HTTP et URL :

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name/promoteReplica

Pour envoyer votre requête, développez l'une des options suivantes :

Vous devriez recevoir une réponse JSON de ce type :

Vérifiez que l'instance promue est configurée correctement. Envisagez en particulier de configurer la haute disponibilité de l'instance si nécessaire.

Vérifier l'état de la duplication

Lorsque vous affichez une instance dupliquée à l'aide de Google Cloud Console ou que vous vous connectez à l'instance à l'aide d'un client d'administration, vous obtenez des informations sur la réplication, y compris l'état et les métriques. Si vous utilisez gcloud CLI, vous obtenez un bref résumé de la configuration de la réplication.

Avant de vérifier l'état de la réplication d'une instance dupliquée Cloud SQL, exécutez la commande
gcloud sql instances describe pour afficher l'état de l'instance. Vous pouvez ainsi vérifier si la réplication est activée pour l'instance dupliquée.

Les métriques suivantes sont disponibles pour les instances dupliquées. Apprenez-en plus sur les autres métriques disponibles pour l'ensemble des instances, y compris les instances non dupliquées.

MétriqueDescription
État de la réplication
(cloudsql.googleapis.com/database/replication/state)

Indique si la réplication diffuse activement les journaux de l'instance principale vers l'instance dupliquée. Les valeurs possibles sont les suivantes :

  • Running
  • Stopped
  • Error

Cette métrique indique Running si :

  1. le status (état) de pg_catalog.pg_stat_wal_receiver vaut "streaming" (diffusion en cours), et
  2. pg_catalog.pg_is_wal_replay_paused() vaut "f" (faux).

Pour en savoir plus, consultez les sections Collecteur de statistiques et Fonctions d'administration système du manuel de référence PostgreSQL.
Délai avant réplication
(cloudsql.googleapis.com/database/replication/replica_lag)

La durée de retard de l'instance dupliquée par rapport à l'état de l'instance principale. Cela correspond à la différence entre (1) l'heure actuelle et (2) l'horodatage d'origine auquel la transaction a été validée et qui est actuellement appliquée à l'instance dupliquée. En particulier, si cette instance dupliquée n'a pas encore appliqué l'écriture dans la base de données, les écritures peuvent être comptabilisées comme étant en retard, même si elles ont été reçues par l'instance dupliquée.

Pour les instances répliquées en cascade, chaque paire instance principale/instance répliquée est surveillée séparément et il n'existe pas de métrique spécifique donnant le délai de bout en bout (de l'instance principale vers l'instance répliquée).

Pour en savoir plus, consultez la section Délai avant réplication.
Octets de latence
(cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag)

Indique le nombre d'octets de retard de l'instance dupliquée avec accès en lecture par rapport à l'instance principale. Quatre séries temporelles sont générées pour chaque instance dupliquée. Elles indiquent dans le journal WAL (write-aheag log) de l'instance principale le nombre d'octets qui n'ont pas encore été…

  • sent_location : …envoyés à l'instance dupliquée.
  • write_location : …écrits sur le disque par l'instance dupliquée.
  • flush_location : …vidés sur le disque par l'instance dupliquée.
  • replay_location : …relus par l'instance dupliquée.

Ces métriques ont différents objectifs. Par exemple, replay_location indique le délai de réplication (nombre de transactions validées sur l'instance principale qui n'ont pas encore été appliquées à l'instance dupliquée), tandis que flush_location indique le nombre de transactions qui n'ont pas été enregistrées de façon durable sur l'instance dupliquée.

Ces métriques sont calculées en comparant pg_catalog.pg_current_wal_lsn() à l'un des champs suivants à partir de pg_stat_replication : sent_lsn, write_lsn, flush_lsn ou replay_lsn. Pour en savoir plus, consultez la page sur l'outil de collecte de statistiques dans le manuel de référence PostgreSQL.
Nombre maximal d'octets de latence
(cloudsql.googleapis.com/database/postgresql/external_sync/max_replica_byte_lag)

Pour l'instance dupliquée d'une instance principale externe, indique le délai maximal de réplication (en octets) sur toutes les bases de données répliquées sur cette instance. Pour chaque base de données, cela correspond au nombre d'octets du journal WAL de l'instance principale qui n'ont pas été reçus par l'instance dupliquée.

Cette métrique est calculée en envoyant une requête à l'instance principale afin de comparer pg_catalog.pg_current_wal_lsn() à la valeur de confirmed_flush_lsn pour chaque base de données répliquée sur l'instance dupliquée. Pour en savoir plus, consultez la page sur l'outil de collecte de statistiques dans le manuel de référence PostgreSQL.

Pour vérifier l'état de la réplication, procédez comme suit :

Console

Cloud SQL indique la métrique Replication State dans le tableau de bord de surveillance Cloud SQL par défaut.

Pour afficher d'autres métriques liées aux instances dupliquées régionales et interrégionales, ainsi que les instances dupliquées des serveurs externes, créez un tableau de bord personnalisé et ajoutez-y les métriques que vous souhaitez surveiller :

  1. Dans Google Cloud Console, accédez à la page Monitoring.

    Accéder à Monitoring

  2. Sélectionnez l'onglet Tableaux de bord.
  3. Cliquez sur Créer un tableau de bord.
  4. Attribuez un nom au tableau de bord, puis cliquez sur OK.
  5. Cliquez sur Ajouter un graphique.
  6. Pour Type de ressource, sélectionnez Base de données Cloud SQL.
  7. Effectuez l'une des actions suivantes :
    1. Pour surveiller la métrique de l'état de réplication : saisissez Replication state dans le champ Sélectionner une métrique. Ensuite, ajoutez le filtre state = "Running". Le graphique indique 1 si la réplication est en cours, et 0 sinon.
    2. Pour surveiller le délai de réplication, en octets, d'une instance dupliquée avec accès en lecture : saisissez Lag Bytes dans le champ Sélectionner une métrique. Ajoutez ensuite un filtre sur replica_lag_type = "replay_location". Le graphique indique le nombre d'octets associés aux transactions validées sur l'instance principale, mais qui n'ont pas encore été relus sur l'instance dupliquée.
    3. Pour surveiller le délai de réplication, en octets, d'une instance dupliquée d'une instance principale externe : saisissez Max Lag Bytes dans le champ Sélectionner une métrique. Le graphique indique le nombre d'octets associés aux transactions validées sur l'instance principale, mais qui n'ont pas encore été reçus par l'instance dupliquée.

gcloud

Vous pouvez vérifier l'état de la réplication d'une instance dupliquée à l'aide de la commande suivante :

gcloud sql instances describe REPLICA_NAME

Dans le résultat, recherchez les propriétés databaseReplicationEnabled et masterInstanceName.

Vous pouvez vérifier si une instance maître possède des instances dupliquées à l'aide de la commande suivante :

gcloud sql instances describe PRIMARY_INSTANCE_NAME

Dans le résultat, recherchez la propriété replicaNames.

Client psql

Certaines métriques d'état de la réplication sont générées par l'instance principale, d'autres par l'instance dupliquée. Avant de suivre les étapes suivantes, connectez-vous à l'instance dupliquée ou à l'instance principale (comme indiqué ci-dessous) à l'aide d'un client PostgreSQL.

Pour en savoir plus, consultez la page Options de connexion pour les applications externes.

  1. Pour vérifier l'état de l'instance dupliquée depuis l'instance principale, procédez comme suit : 
    select * from pg_stat_replication;
    Recherchez les métriques suivantes dans le résultat de la commande :
    • client_addr : adresse IP de l'instance dupliquée.
    • state : indique si le thread SQL qui permet d'exécuter des événements dans le journal de relais est en cours d'exécution. La valeur est streaming au démarrage de la réplication.
    • replay_lag : nombre d'octets de retard du thread SQL de l'instance dupliquée par rapport à l'instance principale. Sa valeur est O ou un petit nombre d'octets.
  2. Pour vérifier l'état de l'instance dupliquée directement sur l'instance dupliquée, procédez comme suit : 
    select * from pg_stat_wal_receiver;

    Recherchez les métriques suivantes dans le résultat de la commande :

    • sender_host : adresse IP de l'instance principale.
    • status : indique si le thread SQL qui permet d'exécuter des événements dans le journal de relais est en cours d'exécution. La valeur est streaming au démarrage de la réplication.
    • last_msg_send_time et last_msg_receipt_time : la différence entre ces deux horodatages correspond au délai de latence.

    Pour vérifier si la réplication a été suspendue, procédez comme suit :

    select pg_is_wal_replay_paused();

    La valeur est t si la réplication est suspendue. Sinon, elle est définie sur f.

    Pour vérifier si des transactions ont été reçues de l'instance principale, mais n'ont pas encore été appliquées, procédez comme suit :

    # for PostgreSQL 9.6
select pg_catalog.pg_last_xlog_receive_location(), pg_catalog.pg_last_xlog_replay_location();
# for PostgreSQL 10 and above
select pg_catalog.pg_last_wal_receive_lsn(), pg_catalog.pg_last_wal_replay_lsn();

    Si les deux valeurs sont identiques, cela signifie que l'instance dupliquée a traité toutes les transactions qu'elle a reçues de l'instance principale.

  • Pour en savoir plus sur le résultat de ces commandes, consultez la documentation de PostgreSQL sur l'outil de collecte de statistiques.

    • Résoudre les problèmes

    Problème Dépannage
    L'instance répliquée avec accès en lecture n'a pas commencé à se répliquer lors de la création. Les fichiers journaux indiquent probablement une erreur plus spécifique. Inspectez les journaux dans Cloud Logging pour rechercher l'erreur en question.
    Impossible de créer l'instance dupliquée avec accès en lecture : erreur invalidFlagValue. L'un des indicateurs de la requête n'est pas valide. Il peut s'agir d'une option que vous avez explicitement définie ou d'une option définie sur une valeur par défaut.

    Tout d'abord, vérifiez que la valeur de l'option max_connections est supérieure ou égale à la valeur principale.

    Si l'option max_connections est définie correctement, inspectez les journaux dans Cloud Logging pour rechercher l'erreur réelle.
    Impossible de créer l'instance dupliquée avec accès en lecture : erreur inconnue. Les fichiers journaux indiquent probablement une erreur plus spécifique. Inspectez les journaux dans Cloud Logging pour rechercher l'erreur en question.

    Si l'erreur est : set Service Networking service account as servicenetworking.serviceAgent role on consumer project, désactivez et réactivez Service Networking API. Cette action crée le compte de service nécessaire pour poursuivre le processus.
    Le disque est saturé. Le disque de l'instance principale peut arriver à saturation lors de la création de l'instance dupliquée. Modifiez l'instance principale en augmentant la taille du disque.
    L'espace disque augmente considérablement. Un emplacement qui n'est pas activement utilisé pour suivre les données oblige PostgreSQL à conserver les segments WAL indéfiniment, ce qui entraîne une augmentation permanente de l'espace disque. Si vous utilisez les fonctionnalités de réplication logique et de décodage logique de Cloud SQL, les emplacements de réplication sont créés et supprimés automatiquement. Vous pouvez détecter les emplacements de réplication inutilisés en interrogeant la vue système pg_replication_slots et en filtrant suivant la colonne active. La suppression des emplacements inutilisés, en vue d'éliminer des segments WAL, s'effectue à l'aide de la commande pg_drop_replication_slot.
    L'instance dupliquée utilise trop de mémoire. L'instance dupliquée met en cache les opérations de lecture souvent demandées dans une mémoire temporaire, ce qui peut l'amener à utiliser plus de mémoire que l'instance principale.

    Redémarrez l'instance dupliquée afin de récupérer l'espace de mémoire temporaire.
    La duplication s'est arrêtée. La limite de stockage maximale a été atteinte et l'augmentation automatique de l'espace de stockage n'est pas activée.

    Modifiez l'instance pour activer automatic storage increase.
    Le délai de duplication est systématiquement long. La charge d'écriture est trop élevée pour que l'instance dupliquée puisse la traiter. Le délai de duplication s'allonge lorsque le thread SQL d'une instance dupliquée ne parvient pas à suivre le thread d'E/S. Certains types de requêtes ou de charges de travail peuvent allonger le délai de duplication de manière temporaire ou permanente pour un schéma donné. Voici quelques causes typiques affectant le délai de duplication :
    • Requêtes lentes sur l'instance dupliquée. Recherchez-les et corrigez-les.
    • Toutes les tables doivent avoir une clé unique/primaire. Chaque mise à jour d'une table sans clé unique/primaire entraîne une analyse complète des tables de l'instance dupliquée.
    • Les requêtes telles que DELETE ... WHERE field < 50000000 allongent le délai de duplication, dans le cas des duplications basées sur les lignes, car un grand nombre de mises à jour s'accumulent sur l'instance dupliquée.

    Voici quelques solutions possibles :

    • Modifiez l'instance pour augmenter la taille de l'instance dupliquée.
    • Réduisez la charge sur la base de données.
    • Envoyez du trafic en lecture à l'instance dupliquée avec accès en lecture.
    • Indexez les tables.
    • Identifiez et corrigez les requêtes d'écriture lentes.
    • Recréez l'instance dupliquée.
    Erreurs lors de la reconstruction d'index dans PostgreSQL 9.6. Une erreur de PostgreSQL vous indique que vous devez reconstruire un index particulier. Cette opération n'est possible que sur l'instance principale. Si vous créez une nouvelle instance dupliquée, vous obtiendrez rapidement la même erreur. Les index de hachage ne sont pas propagés aux instances dupliquées dans les versions de PostgreSQL antérieures à la version 10.

    Si vous devez absolument utiliser des index de hachage, effectuez une mise à niveau vers PostgreSQL 10 ou une version ultérieure. Sinon, si vous souhaitez également utiliser des instances dupliquées, n'utilisez pas d'index de hachage dans PostgreSQL 9.6.
    La requête sur l'instance principale est toujours en cours d'exécution. Après avoir créé une instance répliquée, la requête SELECT * from pg_stat_activity where state = 'active' and pid = XXXX and username = 'cloudsqlreplica' doit s'exécuter en continu sur votre instance principale.
    La création d'une instance dupliquée échoue avec un délai d'expiration. Les transactions non validées de longue durée sur l'instance principale peuvent entraîner l'échec de la création d'une instance dupliquée avec accès en lecture.

    Recréez l'instance dupliquée après avoir arrêté toutes les requêtes en cours d'exécution.

    Étape suivante