Lorsque vous créez une instance dans la console Google Cloud , les sauvegardes automatisées et la récupération à un moment précis (PITR) sont automatiquement activées. Vous pouvez configurer la récupération PITR pour n'importe quelle instance existante en procédant comme suit :
- Activer la récupération PITR
- Désactiver la récupération PITR
- Définir la durée de conservation des journaux de transactions
- Vérifier l'emplacement de stockage des journaux de transactions utilisés pour la récupération à un moment précis
Activer la récupération PITR
Lorsque vous créez une instance dans la console Google Cloud , les options Sauvegardes automatiques et Activer la récupération à un moment précis sont automatiquement activées.La procédure suivante permet d'activer la récupération PITR sur une instance principale existante.
Console
-
Dans la console Google Cloud , accédez à la page Instances Cloud SQL.
- Ouvrez le menu "Autres actions"
au niveau de l'instance pour laquelle vous souhaitez activer la récupération PITR, puis cliquez sur Modifier. - Sous Personnaliser votre instance, développez la section Protection des données.
- Cochez la case Activer la récupération à un moment précis.
- Dans le champ Jours de journaux, saisissez le nombre de jours de conservation des journaux, compris entre 1 et 35 pour l'édition Cloud SQL Enterprise Plus, ou entre 1 et 7 pour l'édition Cloud SQL Enterprise.
- Cliquez sur Enregistrer.
gcloud
- Affichez la présentation de l'instance :
gcloud sql instances describe INSTANCE_NAME
- Si la mention
enabled: falses'affiche dans la sectionbackupConfiguration, activez les sauvegardes planifiées :gcloud sql instances patch INSTANCE_NAME \ --backup-start-time=HH:MM
Spécifiez le paramètre
backup-start-timeau format 24 heures dans le fuseau horaire UTC ± 00. - Activez la récupération PITR :
gcloud sql instances patch INSTANCE_NAME \ --enable-bin-log
Si vous activez la récupération PITR sur une instance principale, vous pouvez également configurer le nombre de jours pendant lesquels vous souhaitez conserver les journaux de transactions en ajoutant le paramètre suivant :
--retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS - Confirmez la modification :
gcloud sql instances describe INSTANCE_NAME
Dans la section
backupConfiguration, vous voyez le messagebinaryLogEnabled: trues'afficher si la modification a réussi.
Terraform
Pour activer la récupération PITR, utilisez une ressource Terraform.
Appliquer les modifications
Pour appliquer votre configuration Terraform dans un projet Google Cloud , suivez les procédures des sections suivantes.
Préparer Cloud Shell
- Lancez Cloud Shell.
-
Définissez le projet Google Cloud par défaut dans lequel vous souhaitez appliquer vos configurations Terraform.
Vous n'avez besoin d'exécuter cette commande qu'une seule fois par projet et vous pouvez l'exécuter dans n'importe quel répertoire.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
Les variables d'environnement sont remplacées si vous définissez des valeurs explicites dans le fichier de configuration Terraform.
Préparer le répertoire
Chaque fichier de configuration Terraform doit avoir son propre répertoire (également appelé module racine).
-
Dans Cloud Shell, créez un répertoire et un nouveau fichier dans ce répertoire. Le nom du fichier doit comporter l'extension
.tf, par exemplemain.tf. Dans ce tutoriel, le fichier est appelémain.tf.mkdir DIRECTORY && cd DIRECTORY && touch main.tf
-
Si vous suivez un tutoriel, vous pouvez copier l'exemple de code dans chaque section ou étape.
Copiez l'exemple de code dans le fichier
main.tfque vous venez de créer.Vous pouvez également copier le code depuis GitHub. Cela est recommandé lorsque l'extrait Terraform fait partie d'une solution de bout en bout.
- Examinez et modifiez les exemples de paramètres à appliquer à votre environnement.
- Enregistrez les modifications.
-
Initialisez Terraform. Cette opération n'est à effectuer qu'une seule fois par répertoire.
terraform init
Vous pouvez également utiliser la dernière version du fournisseur Google en incluant l'option
-upgrade:terraform init -upgrade
Appliquer les modifications
-
Examinez la configuration et vérifiez que les ressources que Terraform va créer ou mettre à jour correspondent à vos attentes :
terraform plan
Corrigez les modifications de la configuration si nécessaire.
-
Appliquez la configuration Terraform en exécutant la commande suivante et en saisissant
yeslorsque vous y êtes invité :terraform apply
Attendez que Terraform affiche le message "Apply completed!" (Application terminée).
- Ouvrez votre projet Google Cloud pour afficher les résultats. Dans la console Google Cloud , accédez à vos ressources dans l'interface utilisateur pour vous assurer que Terraform les a créées ou mises à jour.
Supprimer les modifications
Pour supprimer vos modifications, procédez comme suit :
- Pour désactiver la protection contre la suppression, définissez l'argument
deletion_protectionsurfalsedans le fichier de configuration Terraform.deletion_protection = "false"
- Appliquez la configuration Terraform mise à jour en exécutant la commande suivante et en saisissant
yeslorsque vous y êtes invité :terraform apply
-
Supprimez les ressources précédemment appliquées à votre configuration Terraform en exécutant la commande suivante et en saisissant
yesà la requête :terraform destroy
REST v1
Avant d'utiliser les données de requête, effectuez les remplacements suivants :
- PROJECT_ID : ID ou numéro de projet du projet Google Cloud contenant l'instance.
- INSTANCE_NAME : nom de l'instance principale ou de l'instance répliquée avec accès en lecture que vous configurez pour la haute disponibilité.
- START_TIME : heure (en heures et en minutes).
Méthode HTTP et URL :
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME
Corps JSON de la requête :
{
"settings":
{
"backupConfiguration":
{
"startTime": "START_TIME",
"enabled": true,
"binaryLogEnabled": 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
Avant d'utiliser les données de requête, effectuez les remplacements suivants :
- PROJECT_ID : ID ou numéro de projet du projet Google Cloud contenant l'instance.
- INSTANCE_NAME : nom de l'instance principale ou de l'instance répliquée avec accès en lecture que vous configurez pour la haute disponibilité.
- START_TIME : heure (en heures et en minutes).
Méthode HTTP et URL :
PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME
Corps JSON de la requête :
{
"settings":
{
"backupConfiguration":
{
"startTime": "START_TIME",
"enabled": true,
"binaryLogEnabled": true
}
}
}
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
Désactiver la récupération PITR
Console
-
Dans la console Google Cloud , accédez à la page Instances Cloud SQL.
- Ouvrez le menu "Autres actions"
pour l'instance que vous souhaitez désactiver, puis sélectionnez Modifier. - Sous Personnaliser votre instance, développez la section Protection des données.
- Désactivez l'option Activer la récupération à un moment précis.
- Cliquez sur Enregistrer.
gcloud
- Désactivez la récupération à un moment précis :
gcloud sql instances patch INSTANCE_NAME \ --no-enable-bin-log
- Confirmez la modification :
gcloud sql instances describe INSTANCE_NAME
Dans la section
backupConfiguration, vous voyez le messagebinaryLogEnabled: falses'afficher si la modification a réussi.
REST v1
Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :
- project-id : ID du projet
- instance-id : ID de l'instance.
Méthode HTTP et URL :
PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id
Corps JSON de la requête :
{
"settings":
{
"backupConfiguration":
{
"enabled": false,
"binaryLogEnabled": 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
Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :
- project-id : ID du projet
- instance-id : ID de l'instance.
Méthode HTTP et URL :
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id
Corps JSON de la requête :
{
"settings":
{
"backupConfiguration":
{
"enabled": false,
"binaryLogEnabled": false
}
}
}
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
Définir la durée de conservation des journaux de transaction
Pour définir le nombre de jours de conservation des journaux binaires, procédez comme suit :
Console
-
Dans la console Google Cloud , accédez à la page Instances Cloud SQL.
- Ouvrez le menu "Autres actions"
pour l'instance pour laquelle vous souhaitez définir les journaux de transactions et sélectionnez Modifier. - Sous Personnaliser votre instance, développez la section Protection des données.
- Dans la section Activer la récupération à un moment précis, développez Options avancées.
- Indiquez le nombre de jours de conservation des journaux, compris entre 1 et 35 pour l'édition Cloud SQL Enterprise Plus, ou entre 1 et 7 pour l'édition Cloud SQL Enterprise.
- Cliquez sur Enregistrer.
gcloud
Modifiez l'instance pour définir le nombre de jours de conservation des journaux binaires.
Remplacez les éléments suivants :
- INSTANCE_NAME : nom de l'instance sur laquelle vous souhaitez définir les journaux de transactions.
DAYS_TO_RETAIN : quantité de journaux de transactions à conserver, exprimée en jours de conservation. Pour l'édition Cloud SQL Enterprise Plus, la plage valide est comprise entre 1 et 35 jours, avec une valeur par défaut de 14 jours. Pour l'édition Cloud SQL Enterprise, la plage valide est comprise entre 1 et 7 jours, avec une valeur par défaut de 7 jours.
Si vous ne spécifiez pas de valeur, Cloud SQL utilise la valeur par défaut. Cette option n'est valide que si la récupération PITR est activée. Conserver les journaux de transactions sur un nombre de jours plus important nécessite une capacité de stockage plus importante.
gcloud sql instances patch INSTANCE_NAME
--retained-transaction-log-days=DAYS_TO_RETAIN
REST v1
Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :
- PROJECT_ID : ID du projet.
- INSTANCE_ID : ID de l'instance.
DAYS_TO_RETAIN : quantité de journaux de transactions à conserver, exprimée en jours de conservation. Pour l'édition Cloud SQL Enterprise Plus, la plage valide est comprise entre 1 et 35 jours, avec une valeur par défaut de 14 jours. Pour l'édition Cloud SQL Enterprise, la plage valide est comprise entre 1 et 7 jours, avec une valeur par défaut de 7 jours.
Si aucune valeur n'est spécifiée, la valeur par défaut est utilisée. Cette option n'est valide que si la récupération PITR est activée. Conserver les journaux de transactions sur un nombre de jours plus important nécessite une capacité de stockage plus importante.
Méthode HTTP et URL :
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID
Corps JSON de la requête :
{
"settings":
{
"backupConfiguration":
{
"transactionLogRetentionDays": "DAYS_TO_RETAIN"
}
}
}
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
REST v1beta4
Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :
- PROJECT_ID : ID du projet.
- INSTANCE_ID : ID de l'instance.
DAYS_TO_RETAIN : quantité de journaux de transactions à conserver, exprimée en jours de conservation. Pour l'édition Cloud SQL Enterprise Plus, la plage valide est comprise entre 1 et 35 jours, avec une valeur par défaut de 14 jours. Pour l'édition Cloud SQL Enterprise, la plage valide est comprise entre 1 et 7 jours, avec une valeur par défaut de 7 jours.
Si aucune valeur n'est spécifiée, la valeur par défaut est utilisée. Cette option n'est valide que si la récupération PITR est activée. Conserver les journaux de transactions sur un nombre de jours plus important nécessite une capacité de stockage plus importante.
Méthode HTTP et URL :
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID
Corps JSON de la requête :
{
"settings":
{
"backupConfiguration":
{
"transactionLogRetentionDays": "DAYS_TO_RETAIN"
}
}
}
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
Vérifier l'emplacement de stockage des journaux de transactions utilisés pour la récupération à un moment précis
Vous pouvez vérifier où votre instance Cloud SQL stocke les journaux de transactions utilisés pour la récupération à un moment précis.
gcloud
Pour déterminer si votre instance stocke les journaux de PITR sur le disque ou dans Cloud Storage, utilisez la commande suivante :
gcloud sql instances describe INSTANCE_NAME
Remplacez INSTANCE_NAME par le nom de l'instance.
Pour plusieurs instances dans le même projet, vous pouvez également vérifier l'emplacement de stockage des journaux de transactions. Utilisez la commande suivante pour déterminer l'emplacement pour plusieurs instances :
gcloud sql instances list --show-transactional-log-storage-state
Exemple de réponse :
NAME DATABASE_VERSION LOCATION TRANSACTIONAL_LOG_STORAGE_STATE my_01 MYSQL_8_0 us-central-1 DISK my_02 MYSQL_8_0 us-central-1 CLOUD_STORAGE ...
Dans le résultat de la commande, le champ transactionalLogStorageState ou la colonne TRANSACTIONAL_LOG_STORAGE_STATE fournissent des informations sur l'emplacement de stockage des journaux de transactions pour la récupération PITR associée à l'instance.
Les états du stockage des journaux de transactions possibles sont les suivants :
DISK: l'instance stocke les journaux de transactions utilisés pour la récupération PITR sur le disque. Si vous mettez à niveau une instance Cloud SQL Enterprise vers l'édition Cloud SQL Enterprise Plus, le processus de mise à niveau bascule également l'emplacement de stockage des journaux vers Cloud Storage. Pour en savoir plus, consultez Mettre à niveau une instance vers Cloud SQL Enterprise Plus en utilisant la mise à niveau sur place. Vous pouvez également choisir de changer d'emplacement de stockage à l'aide de gcloud CLI ou de l'API Cloud SQL Admin, sans mettre à niveau l'édition de votre instance et sans temps d'arrêt. Pour en savoir plus, consultez la section Passer au stockage des journaux de transactions dans Cloud Storage.SWITCHING_TO_CLOUD_STORAGE: l'instance change l'emplacement de stockage des journaux de transactions PITR vers Cloud Storage.SWITCHED_TO_CLOUD_STORAGE: l'instance a terminé le changement d'emplacement de stockage des journaux de transactions PITR du disque vers Cloud Storage.CLOUD_STORAGE: l'instance stocke les journaux de transactions utilisés pour la récupération à un moment précis dans Cloud Storage.
Passer au stockage des journaux de transactions dans Cloud Storage
Si votre instance stocke ses journaux de transactions utilisés pour la récupération PITR sur disque, vous pouvez définir l'emplacement de stockage sur Cloud Storage, sans subir de temps d'arrêt. Le processus global de changement d'emplacement de stockage correspond approximativement à la durée (en jours) de la période de conservation des journaux de transactions. Dès que vous initiez le basculement, les journaux de transactions commencent à s'accumuler dans Cloud Storage. Pendant l'opération, vous pouvez vérifier l'état du processus global à l'aide de la commande décrite dans la section Vérifier l'emplacement de stockage des journaux de transactions utilisés pour la récupération à un moment précis.
Une fois le processus de basculement vers Cloud Storage terminé, Cloud SQL utilise les journaux de transactions hébergés sur Cloud Storage pour la récupération PITR.
gcloud
Utilisez la commande suivante pour définir l'emplacement de stockage sur Cloud Storage :
gcloud sql instances patch INSTANCE_NAME \ --switch-transaction-logs-to-cloud-storage
Remplacez INSTANCE_NAME par le nom de l'instance. L'instance doit être une instance principale et non une instance répliquée. La réponse est semblable à ce qui suit :
The following message is used for the patch API method.
{"name": "INSTANCE_NAME", "project": "PROJECT_NAME", "switchTransactionalLogsToCloudStorageEnabled": "true"}
Patching Cloud SQL instance...done.
Updated
[https://sqladmin.prod.googleapis.com/v1/projects/PROJECT_NAME/instances/INSTANCE_NAME].
Si la commande renvoie une erreur, consultez la section Résoudre les problèmes liés au passage à Cloud Storage pour connaître les étapes à suivre.
REST v1
Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :
- PROJECT_ID : ID du projet.
- INSTANCE_ID : ID de l'instance. L'instance doit être une instance principale et non une instance répliquée.
Méthode HTTP et URL :
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID
Corps JSON de la requête :
{
"switchTransactionLogsToCloudStorageEnabled": true
}
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
Si la requête renvoie une erreur, consultez la section Résoudre les problèmes liés au passage à Cloud Storage pour connaître les étapes à suivre.
REST v1beta4
Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :
- PROJECT_ID : ID du projet.
- INSTANCE_ID : ID de l'instance. L'instance doit être une instance principale et non une instance répliquée.
Méthode HTTP et URL :
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID
Corps JSON de la requête :
{
"switchTransactionLogsToCloudStorageEnabled": true
}
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
Si la requête renvoie une erreur, consultez la section Résoudre les problèmes liés au passage à Cloud Storage pour connaître les étapes à suivre.
Stockage et configuration des journaux de transactions après le changement
Pour la réplication, Cloud SQL conserve toujours des copies des journaux binaires sur le disque.
Si vous souhaitez parcourir les journaux binaires avec l'utilitaire mysqlbinlog, il est utile de les stocker sur le disque.
Si vous avez configuré les options expire_logs_days ou binlog_expire_logs_seconds sur votre instance avant le changement, les valeurs configurées restent intactes.
Après le basculement, étant donné que les journaux binaires utilisés pour effectuer la récupération à un moment précis sont désormais stockés dans Cloud Storage, assurez-vous que les valeurs des options reflètent la conservation des journaux de transactions sur le disque attendu. Cloud SQL ne conserve les journaux sur le disque que pour la valeur minimale de l'un des éléments suivants :
- Le paramètre de configuration de la récupération PITR
transactionLogRetentionDaysavant le basculement. La valeur par défaut de ce paramètre est de sept jours. - Les options
expire_logs_daysoubinlog_expire_logs_secondsque vous avez définies manuellement sur votre instance.
Si vous souhaitez économiser de l'espace disque, une fois le processus de transfert terminé, définissez la valeur des options expire_logs_days ou binlog_expire_logs_seconds sur 1 jour afin de réduire la taille de disque allouée et les coûts de stockage sur disque. Pour en savoir plus sur le stockage des journaux de transactions et la récupération PITR, consultez Stockage de journaux pour la récupération à un moment précis.
Pour savoir comment vérifier l'utilisation du disque, consultez Journaux et utilisation du disque.
Résoudre les problèmes liés au passage à Cloud Storage
Le tableau suivant liste les erreurs pouvant être renvoyées avec le code INVALID REQUEST, lorsque vous changez l'emplacement de stockage des journaux de transactions pour passer d'un stockage sur disque à Cloud Storage.
| Problème | Dépannage |
|---|---|
Switching the storage location of the transaction logs
used for PITR is not supported for instances with database type %s.
|
Assurez-vous d'exécuter la commande gcloud CLI ou d'envoyer la requête API sur une instance Cloud SQL pour MySQL ou Cloud SQL pour PostgreSQL. Il n'est pas possible de changer l'emplacement de stockage des journaux de transactions à l'aide de gcloud CLI ou de l'API Cloud SQL Admin en passant par Cloud SQL pour SQL Server. |
MySQL transactional logging is not enabled on this instance.
|
MySQL utilise la journalisation binaire à titre de journaux de transactions, dans le cadre de la récupération à un moment précis (PITR). Pour que la récupération PITR soit possible, MySQL nécessite que vous activiez la journalisation binaire sur l'instance. Pour savoir comment activer la journalisation binaire, consultez la section Activer la récupération PITR. |
This command is not supported on replica instances.
Run the command on the primary instance instead.
|
Veillez à spécifier une instance principale lorsque vous exécutez la commande ou envoyez la requête API. |
This instance is already storing transaction logs used for PITR in
Cloud Storage
|
Pour vérifier l'emplacement de stockage des journaux de transactions, exécutez la commande mentionnée dans la section Vérifier l'emplacement de stockage des journaux de transactions utilisés pour la récupération à un moment précis. |
The instance is already switching transaction logs used for PITR from disk
to Cloud Storage.
|
Attendez que l'opération se termine. Pour vérifier l'état de l'opération et l'emplacement de stockage des journaux de transactions, exécutez la commande mentionnée dans la section Vérifier l'emplacement de stockage des journaux de transactions utilisés pour la récupération à un moment précis. |
Étape suivante
- Configurez des options sur votre clone.