Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questa pagina descrive come aggiungere flag di database per un'istanza, modificare i flag di database ed eliminarli da un'istanza in un cluster AlloyDB per PostgreSQL.
Utilizzi i flag di database per molte operazioni, tra cui la modifica dei parametri PostgreSQL, la modifica delle opzioni e la configurazione e l'ottimizzazione di un'istanza.
Le modifiche al valore di un flag di database vengono mantenute per la relativa istanza finché non rimuovi il flag o non modifichi di nuovo il suo valore.
In alcuni casi, l'impostazione di un flag potrebbe richiedere l'impostazione di un altro flag per
attivare completamente la funzionalità desiderata.
Dopo aver impostato, rimosso o modificato un flag per un'istanza di database,
AlloyDB potrebbe riavviare l'istanza. Dipende dal flag,
come indicato in
Flag di database supportati.
Quando modifichi un flag di database nell'istanza principale o in un pool di lettura
che richiede un riavvio, puoi scegliere uno dei seguenti criteri di manutenzione:
Tempi di inattività ridotti. Questo criterio è attivato per impostazione predefinita. Ti consigliamo di
utilizzare questo criterio per tutti i tuoi cluster AlloyDB di produzione
perché riduce al minimo i tempi di inattività dell'applicazione.
Se è abilitata la policy di tempi di inattività ridotti, l'aggiornamento di un flag che richiede un riavvio dell'istanza principale del cluster ha i seguenti effetti:
L'istanza primaria subisce un downtime inferiore a un secondo
per la maggior parte dei carichi di lavoro.
L'aggiornamento del flag sull'istanza principale al nuovo valore
termina dopo circa 15 minuti.
L'aggiornamento di un flag che richiede un riavvio su un'istanza di pool di lettura ha
questi effetti:
L'istanza del pool di lettura non richiede tempi di inattività.
L'aggiornamento del flag sull'istanza del pool di lettura al nuovo valore
termina dopo circa 10 minuti.
Forza applicazione. Per applicare più rapidamente gli aggiornamenti dei flag, utilizza l'opzione FORCE_APPLY
con il comando gcloud beta alloydb instances update.
Questa norma è più adatta agli ambienti di sviluppo, in quanto
consente di aggiungere o modificare rapidamente i flag in cambio di un tempo di inattività
più lungo dell'istanza e di una riduzione temporanea delle prestazioni o
del throughput del database. Il cluster torna al picco delle prestazioni diversi minuti
dopo l'applicazione forzata di un aggiornamento del flag.
Se è abilitato il criterio di applicazione forzata, l'aggiornamento di un flag che richiede un
riavvio sull'istanza primaria del cluster ha i seguenti effetti:
L'istanza principale subisce un'interruzione di circa un minuto.
L'aggiornamento del flag sull'istanza principale al nuovo valore termina
dopo uno o due minuti.
L'aggiornamento di un flag che richiede un riavvio su un'istanza di pool di lettura ha
questi effetti:
L'istanza del pool di lettura subisce un tempo di inattività di circa un minuto.
Il flag sull'istanza del pool di lettura termina l'aggiornamento al nuovo valore dopo uno o due minuti.
Fai clic su un cluster nella colonna Nome risorsa.
Nella pagina Panoramica, vai a Istanze nel cluster,
seleziona un'istanza e poi fai clic su Modifica.
Aggiungi, modifica o elimina un flag di database dalla tua istanza:
Aggiungere un flag
Per aggiungere un flag di database all'istanza, fai clic su Aggiungi flag.
Seleziona un flag dall'elenco Nuovo flag database.
Specifica un valore per il flag.
Fai clic su Fine.
Modificare un flag
Per modificare un flag di database presente nella tua istanza, espandi il flag di database e modifica il valore del flag esistente nella sezione Modifica flag di database.
Fai clic su Fine.
Eliminare un flag
Per eliminare un flag del database dall'istanza, seleziona un flag e fai clic sull'icona di eliminazione.
Per applicare gli aggiornamenti dei flag più rapidamente, includi l'argomento
--update-mode=FORCE_APPLY. Poiché questa operazione può ridurre temporaneamente le prestazioni del database, evita di utilizzare questa opzione in un ambiente di produzione.
FLAGS_LIST: un elenco separato da virgole di una o più specifiche di flag di database. Ogni specifica è costituita dal nome del flag, da un segno uguale (=) e dal valore da assegnare ai flag. Per i flag di database che non
accettano valori, fornisci il nome del flag seguito da un segno di uguale (=).
REGION_ID: la regione in cui si trova l'istanza, ad esempio
us-central1.
CLUSTER_ID: l'ID del cluster in cui viene inserita l'istanza.
PROJECT_ID: l'ID del progetto in cui è posizionato il cluster.
sottoposto a ciclo di manutenzione con tempi di inattività bassi o nulli, dopo la modifica dei flag del database.
Per visualizzare l'elenco dei flag attuali impostati manualmente di un'istanza, esegui questo comando:
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 UTC."],[[["\u003cp\u003eThis guide details how to add, modify, and delete database flags for instances within an AlloyDB for PostgreSQL cluster, which are used for various operational adjustments.\u003c/p\u003e\n"],["\u003cp\u003eDatabase flag modifications persist until removed or changed, and sometimes, setting one flag necessitates setting another for full functionality.\u003c/p\u003e\n"],["\u003cp\u003eApplying flag changes may trigger an instance restart, and users can choose between a "Low downtime" policy (recommended for production) or a "Force apply" policy (for faster updates, but with potential downtime and performance dips).\u003c/p\u003e\n"],["\u003cp\u003eThe "Low downtime" policy on primary instances results in minimal downtime (less than one second) and read pools experience zero downtime, while "Force apply" results in about one minute of downtime for both, with flag changes applying much faster.\u003c/p\u003e\n"],["\u003cp\u003eYou can manage database flags via the Google Cloud console or by using the \u003ccode\u003egcloud\u003c/code\u003e command-line tool, being cautious that \u003ccode\u003egcloud\u003c/code\u003e commands can reset unlisted flags to their default values.\u003c/p\u003e\n"]]],[],null,["# Configure an instance's database flags\n\nThis page describes how to add database flags for an instance, modify database\nflags, and delete database flags from an instance in an AlloyDB for PostgreSQL\ncluster.\n\nYou use database flags for many operations, including adjusting PostgreSQL\nparameters, adjusting options, and configuring and tuning an instance.\nModifications to a database flag's value persist for its\ninstance until you remove the flag or you modify its value again.\n\nIn some cases, setting one flag may require that you set another flag to\nfully enable the desired functionality.\n\nAfter you set, remove, or modify a flag for a database instance,\nAlloyDB might restart the instance. This depends upon the flag,\nas listed in\n[Supported database flags](https://cloud.google.com/alloydb/docs/reference/database-flags).\n\nWhen you modify a database flag in the primary or a read pool instance\nthat needs a restart, you can choose one of the following maintenance policies:\n\n- **Low downtime.** This policy is enabled by default. We recommend\n using this policy for all your production AlloyDB\n clusters because it minimizes application downtime.\n\n With the low downtime policy enabled, updating a flag that requires a\n restart on your cluster's primary instance has these effects:\n - The primary instance experiences less than one second of downtime\n for most workloads.\n\n - The flag on the primary instance finishes updating to its new value\n after about 15 minutes.\n\n Updating a flag that requires a restart on a read pool instance has\n these effects:\n - The read pool instance does not require any downtime.\n\n - The flag on the read pool instance finishes updating to its new\n value after about 10 minutes.\n\n- **Force apply.** To apply flag updates faster, use the `FORCE_APPLY`\n option with the `gcloud beta alloydb instances update` command.\n\n This policy is more appropriate for development environments, letting\n you quickly add or modify flags in exchange for longer instance\n downtime and a temporary decrease in database performance or\n throughput. Your cluster returns to peak performance several minutes\n after force applying a flag update.\n\n With the force apply policy enabled, updating a flag that requires a\n restart on your cluster's primary instance has these effects:\n - The primary instance experiences about one minute of downtime.\n\n - The flag on the primary instance finishes updating to its new value\n after one or two minutes.\n\n Updating a flag that requires a restart on a read pool instance has\n these effects:\n - The read pool instance experiences about one minute of downtime.\n\n - The flag on the read pool instance finishes updating to its new\n value after one or two minutes.\n\n\nBefore you begin\n----------------\n\n- The Google Cloud project you are using must have been [enabled to access AlloyDB](/alloydb/docs/project-enable-access).\n- You must have one of these IAM roles in the Google Cloud project you are using:\n - `roles/alloydb.admin` (the AlloyDB Admin predefined IAM role)\n - `roles/owner` (the Owner basic IAM role)\n - `roles/editor` (the Editor basic IAM role)\n\n If you don't have any of these roles, contact your Organization Administrator to request\n access.\n\n\u003cbr /\u003e\n\n### Console\n\n1. In the Google Cloud console, go to the **Clusters** page.\n\n [Go to Clusters](https://console.cloud.google.com/alloydb/clusters)\n2. Click a cluster in the **Resource Name** column.\n\n3. In the **Overview** page, go to **Instances in your cluster** ,\n select an instance, and then click **Edit**.\n\n4. Add, modify, or delete a database flag from your instance:\n\n **Add a flag**\n 1. To add a database flag to your instance, click **Add flag**.\n 2. Select a flag from the **New database flag** list.\n 3. Provide a value for the flag.\n 4. Click **Done**.\n\n **Modify a flag**\n 1. To modify a database flag present in your instance, expand the database flag and modify the value of the existing flag in the **Edit database flag** section.\n 2. Click **Done**.\n\n **Delete a flag**\n 1. To delete a database flag from your instance, select a flag and click the delete icon.\n 2. Click **Done**.\n5. Click **Update instance**.\n\n### gcloud\n\nUse the [`gcloud alloydb instances update`](/sdk/gcloud/reference/beta/alloydb/instances/update)\ncommand to change the database flags for an instance.\n**Caution:** Running the following command overwrites all database flags that are previously set. Any database flags that are not explicitly included in the `--database-flags` list are reset to its default value. To retain your instance's database flags while adding new flags, you must include both current and new flags in the `--database-flags` list. \n\n gcloud alloydb instances update \u003cvar translate=\"no\"\u003eINSTANCE_ID\u003c/var\u003e \\\n --database-flags \u003cvar translate=\"no\"\u003eFLAGS_LIST\u003c/var\u003e \\\n --region=\u003cvar translate=\"no\"\u003eREGION_ID\u003c/var\u003e \\\n --cluster=\u003cvar translate=\"no\"\u003eCLUSTER_ID\u003c/var\u003e \\\n --project=\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e\n\nTo apply flag updates more rapidly, include the argument\n`--update-mode=FORCE_APPLY`. Because this can temporarily decrease database\nperformance, avoid using this option in a production environment. \n\n gcloud beta alloydb instances update \u003cvar translate=\"no\"\u003eINSTANCE_ID\u003c/var\u003e \\\n --database-flags \u003cvar translate=\"no\"\u003eFLAGS_LIST\u003c/var\u003e \\\n --region=\u003cvar translate=\"no\"\u003eREGION_ID\u003c/var\u003e \\\n --cluster=\u003cvar translate=\"no\"\u003eCLUSTER_ID\u003c/var\u003e \\\n --project=\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e \\\n --update-mode=FORCE_APPLY\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eINSTANCE_ID\u003c/var\u003e: The ID of the instance.\n- \u003cvar translate=\"no\"\u003eFLAGS_LIST\u003c/var\u003e: A comma-separated list of one or more database flag specifications. Each specification consists of the name of the flag, an equals sign (=), and the value to assign to the flags. For database flags that do not take values, provide the name of the flag followed by an equals sign (=).\n- \u003cvar translate=\"no\"\u003eREGION_ID\u003c/var\u003e: The region where the instance is placed---for example, `us-central1`.\n- \u003cvar translate=\"no\"\u003eCLUSTER_ID\u003c/var\u003e: The ID of the cluster where the instance is placed.\n- \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e: The ID of the project where the cluster is placed. undergoing low or zero downtime maintenance cycle, after you modify database flags.\n\nTo see the list of an instance's current, manually-set flags, run the following\ncommand: \n\n gcloud alloydb instances describe \u003cvar translate=\"no\"\u003eINSTANCE_ID\u003c/var\u003e \\\n --region=\u003cvar translate=\"no\"\u003eREGION_ID\u003c/var\u003e \\\n --cluster=\u003cvar translate=\"no\"\u003eCLUSTER_ID\u003c/var\u003e \\\n --project=\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e"]]
