[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-19。"],[[["\u003cp\u003eAlloyDB for PostgreSQL offers in-place major version upgrades, allowing you to upgrade your database to a newer version without data migration or replacing the existing instance, retaining cluster settings and connection details.\u003c/p\u003e\n"],["\u003cp\u003eThe in-place upgrade process involves pre-upgrade checks, creating an internal clone of the cluster, upgrading the primary instance and read pools, and automatically creating pre- and post-upgrade backups for potential restoration.\u003c/p\u003e\n"],["\u003cp\u003eDuring the upgrade, the primary instance experiences downtime (typically 20 minutes to one hour), but read operations can continue through read pools until the read pool upgrade stage, and the overall downtime depends on the size and schema of the database.\u003c/p\u003e\n"],["\u003cp\u003eThe upgrade process can be monitored through various stages and statuses, and the upgrade can be cancelled until a specific point during the primary instance upgrade, indicated by the \u003ccode\u003ecancellable\u003c/code\u003e status in the upgrade status.\u003c/p\u003e\n"],["\u003cp\u003ePre-GA features like the in-place upgrade for AlloyDB are available "as is" with potentially limited support, and the use of personal data is subject to the Cloud Data Processing Addendum.\u003c/p\u003e\n"]]],[],null,["# Database in-place major version upgrade overview\n\nThis document describes AlloyDB for PostgreSQL database in-place major version\nupgrades, which let you upgrade a database to a higher version without\nmigrating data or replacing the existing instance.\n\nThe PostgreSQL community periodically releases [new major versions](https://www.postgresql.org/support/versioning/) that contain\nnew features, performance improvements, and security enhancements. After\nPostgreSQL releases a new major version, AlloyDB\n[adds support for the compatible version](/alloydb/docs/db-version-policies#support-table).\nTo keep your database up to date, you can upgrade your AlloyDB\ncluster by upgrading to a higher major version. You can upgrade your cluster\nby using this in-place upgrade feature or by\n[migrating your data](/alloydb/docs/cluster-upgrade) to a new\nAlloyDB cluster.\n\nFor more information, see\n[Database version policies](/alloydb/docs/db-version-policies).\n\nIn-place major version upgrades are an efficient way to upgrade your\ncluster's major version for the following reasons:\n\n- AlloyDB retains cluster and instance details and database settings like the instance name, IP address, and database flags after the upgrade.\n- You don't need to change application connection strings.\n- All the cluster instances (primary and read pool) are upgraded as part of the same operation.\n\n| **Note:** To verify the upgrade process and to check for incompatibilities, we recommend that you verify the upgrade process on a cloned cluster before you upgrade your actual cluster.\n\nIn-place major version upgrade workflow\n---------------------------------------\n\nWhen you start an upgrade on your cluster, AlloyDB performs the\nfollowing actions:\n\n1. Runs pre-upgrade checks to find incompatibilities that can impact the upgrade.\n2. Prepares for the major version upgrade, which includes creating an internal clone of the cluster.\n3. Makes the primary instance unavailable. Downtime starts. Reads can still be done through read pools.\n4. Initiates a pre-upgrade backup.\n5. Upgrades the primary instance.\n6. Makes the read pool instances unavailable.\n7. Makes the primary instance available. Downtime ends.\n8. Initiates a post-upgrade backup.\n9. Upgrades read pool instances.\n\n| **Note:** When you perform an in-place major version upgrade, version-specific default values of the database flags might change. For more information, see [Configure an instance's database flags](/alloydb/docs/instance-configure-database-flags).\n\nAfter the pre-upgrade checks pass, your cluster is cloned to an internal cluster\nin the same project. The backup and restore needed to clone the cluster takes\napproximately 10 minutes per terabyte of data.\n\nDuring the clone operation, you can continue to use your original cluster.\nAfter the clone operation is complete, the upgrade process starts. The\nprimary instance is unavailable for both reads and writes until the primary\ninstance is upgraded. Expected downtime is typically 20 minutes to one hour, and\nprimarily depends on your database schema and the number of objects.\n| **Note:** You can continue to use the read pool instances while the primary instance is being upgraded.\n\nAfter the primary instance is upgraded, read pool instances become\nunavailable. Upgrades are attempted on all read pool instances concurrently.\nDowntime is expected to last approximately 20 minutes.\n\nIf the major version upgrade fails at any step before the primary instance is\nupgraded, AlloyDB automatically rolls back all changes.\n\nAfter the primary instance is upgraded, the cluster version is\nupgraded to the target version and no rollbacks are triggered for any failure\nafter this point. For example, AlloyDB doesn't roll back the\ncluster if one or more read pool instance upgrades fail. In these situations,\ncontact [Google Cloud CLI Support](https://cloud.google.com/support).\n\nThe following table gives an approximate estimation of the time taken for the\nupgrade to complete for clusters of different database sizes:\n\nFor more information, see [Upgrade a database in-place major version](/alloydb/docs/upgrade-db-inplace-major-version).\n\n### Upgrade status\n\nYou can\n[monitor the status of an in-place database major version upgrade](/alloydb/docs/upgrade-db-inplace-major-version#monitor-upgrade) operation while it's in\nprogress.\n\nThe upgrade process includes the following stages:\n\n- `ALLOYDB_PRECHECK`\n- `PG_UPGRADE_CHECK`\n- `PREPARE_FOR_UPGRADE`\n- `PRIMARY_INSTANCE_UPGRADE`\n- `READ_POOL_INSTANCES_UPGRADE`\n- `ROLLBACK`(only in case of failure before read pool upgrades)\n- `CLEANUP`\n\nThe possible states of these stages include the following:\n\n- `NOT_STARTED`\n- `IN_PROGRESS`\n- `SUCCESS`\n- `FAILED`\n- `CANCEL_IN_PROGRESS`\n- `CANCELLED`\n\n### Upgrade cancellations\n\nYou can [cancel the upgrade operation](/alloydb/docs/upgrade-db-inplace-major-version#cancel-major-version-upgrade)\nuntil a certain point during the primary instance upgrade. Once that point is\ncrossed, you can't cancel an upgrade.\n\nIn the Google Cloud console, the operation isn't cancelable if the\n**Cancel upgrade** button is grayed out. Using the Google Cloud CLI or the\nREST API, you can\ndetermine if you can [cancel the upgrade](/alloydb/docs/upgrade-db-inplace-major-version#cancel-major-version-upgrade) by checking\n`upgradeClusterStatus` in the upgrade status:\n\n- If `cancellable` is `true`, you can cancel the upgrade.\n- If `cancellable` is `false` or is missing in the status, you can't cancel the upgrade.\n\nAutomatic pre-upgrade and post-upgrade backups\n----------------------------------------------\n\nWhen you perform a major version upgrade, AlloyDB automatically\ncreates the following continuous backups, where `XX` is the source major version\nand `YY` is the target major version.\n\n- The *pre-upgrade backup* is created immediately before the upgrade starts. This backup is named using the format `pre-upgrade-bkp-pgXX-pgYY-\u003cuuid\u003e`. You can use this backup to restore to the pre-upgrade state. Note that restore is not an in-place operation and that it creates a new cluster.\n- The *post-upgrade backup* is created after the primary instance is upgraded. This backup is named using the format `post-upgrade-bkp-pgXX-pgYY-\u003cuuid\u003e`.\n\nA *continuous backup* is incremental, which means that the backup stores only\nthe data that changed relative to the previous continuous backup. This approach\nreduces the size and cost (in resources) of the backup, and speeds up the backup creation\nprocess. For more information, see\n[Data backup and recovery overview](/alloydb/docs/backup/overview).\n\nWhen you view your list of backups, the upgrade backups are listed with type\n`CONTINUOUS`. For more information, see\n[View a list of backups](/alloydb/docs/backup/list).\n\nPerforming point-in-time recovery (PITR) requires that a backup of a version is\navailable. Recovery isn't available on the upgraded cluster until the\npost-upgrade backup, or another backup that is kicked off after the primary\ninstance is upgraded, completes.\n\nWhat's next\n-----------\n\n- [Upgrade a database in-place major version](/alloydb/docs/upgrade-db-inplace-major-version)."]]