Configura las marcas de base de datos de una instancia
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En esta página, se describe cómo agregar, modificar y borrar marcas de bases de datos de una instancia en un clúster de AlloyDB para PostgreSQL.
Las marcas de base de datos se usan en muchas operaciones, como el ajuste de los parámetros de PostgreSQL, el ajuste de las opciones, y la configuración y el ajuste de una instancia.
Las modificaciones en el valor de una marca de base de datos persisten en su instancia hasta que quitas la marca o vuelves a modificar su valor.
En algunos casos, para configurar una marca necesitas configurar otra a fin de habilitar por completo la función deseada.
Después de configurar, quitar o modificar una marca para una instancia de base de datos, es posible que AlloyDB reinicie la instancia. Esto depende de la marca, como se indica en Marcas de base de datos admitidas.
Cuando modificas una marca de base de datos en la instancia principal o en una instancia de grupo de lectura que necesita un reinicio, puedes elegir una de las siguientes políticas de mantenimiento:
Tiempo de inactividad bajo. Esta política está habilitada de forma predeterminada. Recomendamos usar esta política para todos tus clústeres de AlloyDB de producción, ya que minimiza el tiempo de inactividad de la aplicación.
Con la política de tiempo de inactividad bajo habilitada, actualizar una marca que requiere un reinicio en la instancia principal de tu clúster tiene los siguientes efectos:
La instancia principal experimenta menos de un segundo de tiempo de inactividad para la mayoría de las cargas de trabajo.
La marca en la instancia principal termina de actualizarse a su nuevo valor después de unos 15 minutos.
Actualizar una marca que requiere un reinicio en una instancia de grupo de lectura tiene los siguientes efectos:
La instancia del grupo de lectura no requiere tiempo de inactividad.
La marca en la instancia del grupo de lectura termina de actualizarse a su nuevo valor después de unos 10 minutos.
Aplicar a la fuerza Para aplicar las actualizaciones de marcas más rápido, usa la opción FORCE_APPLY con el comando gcloud beta alloydb instances update.
Esta política es más adecuada para los entornos de desarrollo, ya que te permite agregar o modificar marcas rápidamente a cambio de un mayor tiempo de inactividad de la instancia y una disminución temporal en el rendimiento o la capacidad de procesamiento de la base de datos. El clúster vuelve a su rendimiento máximo varios minutos después de aplicar por la fuerza una actualización de la marca.
Con la política de aplicación forzada habilitada, la actualización de una marca que requiere un reinicio en la instancia principal de tu clúster tiene los siguientes efectos:
La instancia principal experimenta aproximadamente un minuto de inactividad.
La marca de la instancia principal termina de actualizarse a su nuevo valor después de uno o dos minutos.
Actualizar una marca que requiere un reinicio en una instancia de grupo de lectura tiene los siguientes efectos:
La instancia del grupo de lectura experimenta aproximadamente un minuto de inactividad.
La marca en la instancia del grupo de lectura termina de actualizarse a su nuevo valor después de uno o dos minutos.
Haz clic en un clúster en la columna Nombre del recurso.
En la página Descripción general, ve a Instancias en tu clúster, selecciona una instancia y, luego, haz clic en Editar.
Sigue estos pasos para agregar, modificar o borrar una marca de base de datos de tu instancia:
Cómo agregar una marca
Para agregar una marca de base de datos a tu instancia, haz clic en Agregar marca.
Selecciona una marca de la lista New database flag.
Proporciona un valor para la marca.
Haz clic en Listo.
Cómo modificar una marca
Para modificar una marca de base de datos presente en tu instancia, expande la marca de base de datos y modifica el valor de la marca existente en la sección Editar marca de base de datos.
Haz clic en Listo.
Cómo borrar una marca
Para borrar una marca de base de datos de tu instancia, selecciona una marca y haz clic en el ícono de borrar.
Para aplicar las actualizaciones de marcas más rápidamente, incluye el argumento --update-mode=FORCE_APPLY. Dado que esto puede reducir temporalmente el rendimiento de la base de datos, evita usar esta opción en un entorno de producción.
FLAGS_LIST: Es una lista separada por comas de una o más especificaciones de marcas de bases de datos. Cada especificación consta del nombre de la marca, un signo igual (=) y el valor que se asignará a las marcas. En el caso de las marcas de la base de datos que no toman valores, proporciona el nombre de la marca seguido de un signo igual (=).
REGION_ID: Es la región en la que se coloca la instancia, por ejemplo, us-central1.
CLUSTER_ID: Es el ID del clúster en el que se coloca la instancia.
PROJECT_ID: ID del proyecto en el que se coloca el clúster. Se somete a un ciclo de mantenimiento con un tiempo de inactividad bajo o nulo después de que modificas las marcas de la base de datos.
Para ver la lista de marcas actuales establecidas manualmente de una instancia, ejecuta el siguiente comando:
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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"]]