[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[[["\u003cp\u003eAlloyDB, a managed service, handles internal resource updates to ensure reliability, performance, and security, with most updates requiring no downtime, though some necessitate brief maintenance.\u003c/p\u003e\n"],["\u003cp\u003eMaintenance updates, which can involve new features, database compatibility upgrades, or operating system patches, cause minimal downtime, specifically less than one second for primary and secondary instances and zero seconds for read pools.\u003c/p\u003e\n"],["\u003cp\u003eMaintenance timing can be managed through user-defined maintenance windows, allowing you to choose preferred days and hours for non-emergency maintenance events, scheduled at least a week in advance.\u003c/p\u003e\n"],["\u003cp\u003eSetting maintenance windows on production clusters and omitting them on non-production ones allows for previewing updates in a non-production environment, as non-production updates are always done first.\u003c/p\u003e\n"],["\u003cp\u003eEmergency maintenance for urgent security patches might occur outside of the set maintenance windows and default maintenance times.\u003c/p\u003e\n"]]],[],null,["# Maintenance overview\n\nAlloyDB clusters and instances rely upon many internal, low-level\nGoogle Cloud resources. These include the virtual machine (VM) instances\nthat serve as AlloyDB nodes and load balancers, and the storage\nvolumes that hold your data. Because AlloyDB is a managed\nservice, Google takes care of keeping these internal resources up to date. This\nhelps ensure that your AlloyDB clusters and instances stay\nreliable, performant, and secure.\n\nMost of these updates require no downtime, but certain system updates require a\nbrief service interruption. We refer to these updates as *maintenance*.\nBecause these updates require the affected node to restart, they can incur\ndowntime.\n\nAlloyDB's non-disruptive maintenance operations limit the\ndowntime to \\\u003c1 seconds for primary and secondary instances, and they limit the\ndowntime to zero seconds for read pools. This near-zero and zero downtime is\nachieved by preparing a replacement server with the updates, and then switching\nthe database server afterwards. As you can see in the logs, the operation time\nis longer than the downtime.\n\nReasons for maintenance\n-----------------------\n\nMaintenance updates can happen for the following reasons:\n\n- **New AlloyDB features.** To launch new features, Google\n needs to update the AlloyDB software running on the nodes\n within your cluster. This might also involve updating the PostgreSQL\n extensions that are included with AlloyDB, or installing new\n extensions.\n\n- **Database compatibility upgrades.** The PostgreSQL community regularly\n releases minor-version updates to supported major versions of PostgreSQL.\n Google incorporates these updates into AlloyDB, and applies\n them to clusters configured for compatibility with the affected major\n version. For more information, see [Database version\n policies](/alloydb/docs/db-version-policies).\n\n- **Operating system patches.** Google continuously monitors for security\n vulnerabilities in the operating systems that run on the internal resources\n that constitute AlloyDB clusters. Upon discovery, we patch\n the resources' operating systems to protect you from new risks.\n\nMaintenance timing and maintenance preferences\n----------------------------------------------\n\n| **Note:** To access new AlloyDB features, you must have the latest AlloyDB system software version. If you have a maintenance window set for your AlloyDB cluster, you might not have the latest software version.\n\nYou can set maintenance windows for both primary and secondary\nAlloyDB clusters. By default, no maintenance window is set on\nan AlloyDB cluster. Non-emergency maintenance for\nan AlloyDB cluster with no configured maintenance windows can\noccur any time except for the hours between 6 AM and 10 PM on weekdays, in the\nlocal time of the region where the cluster is located.\n\nYou can also [specify a *maintenance window*](/alloydb/docs/maintenance-windows#set-window).\nA maintenance window defines your preferred maintenance time, in terms of hour-of-day and day-of-week,\nfor your cluster to begin its maintenance events. For example, you can set a cluster to\nhave a maintenance window that begins at 11AM on Sundays (UTC).\n\nIf you set a maintenance window, then AlloyDB schedules future\nnon-emergency maintenance events to begin no later than one hour after the specified time. In\naddition, if you [opt in to receive email notifications](/alloydb/docs/maintenance-windows#opt-in) about upcoming\nAlloyDB maintenance events, then you receive an automated\nnotification about the event as soon as it is scheduled. Maintenance events are scheduled at least one week ahead of time.\n\nYou can't set the ending time of a maintenance window, since the total time\nrequired for a single maintenance event can vary depending upon the complexity\nof the cluster---that is, the number of read pool instances that require\nupdating---and the nature of the update. While the downtime required for any\nindividual instance can be very brief, the entire maintenance might take hours.\nFor this reason, you can use a maintenance window to control the general time of\nday when the instances of your cluster experience maintenance downtime, but you\ncan't specify a to-the-minute downtime window for any instance.\n\nEmergency maintenance events, such as applying urgent security patches, might\noccur outside of default maintenance times or configured maintenance windows,\nincluding during deny maintenance periods.\n\nMaintenance window best practices\n---------------------------------\n\nWe recommend that you set maintenance windows on your production clusters,\nand not set one maintenance windows on your non-production clusters.\nThis is because of the following broad order of events around a maintenance\nupdate:\n\n1. First, Google updates all of your clusters that don't have maintenance windows.\n2. Next, Google schedules updates for all of your clusters that do have maintenance windows. These updates have at least one week of lead time.\n3. If you have opted in to receive communication about upcoming AlloyDB maintenance events, then Google emails you with notification about the scheduled maintenance.\n4. Google performs the maintenance updates at the scheduled times.\n\nTherefore, a notification of upcoming maintenance also means that the same\nupdates have already been applied to all of your clusters with no maintenance\nwindows set. If you leave your non-production clusters without maintenance\nwindows, you can then guarantee that they receive system updates first, and you\ncan use upcoming-maintenance notifications as a prompt to test or preview the\nupdates in a non-production environment.\n\nWhat's next\n-----------\n\n- [View and set maintenance times](/alloydb/docs/maintenance-windows)"]]
