在非 Kubernetes 部署作業中，您可以選擇特定唯讀備用資源，在主要資源故障時擔任主要資源的角色。AlloyDB Omni Kubernetes 運算子會自動處理區域中的節點放置位置，以及 Pod 應部署至哪些節點。影響放置位置的某些設定選項 (例如 Pod 親和性和容許度)，可在用於透過 AlloyDB Omni 運算子部署的資料庫設定中找到。
[[["容易理解","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 (世界標準時間)。"],[],[],null,["# Protect your data with zonal and regional replication\n\nSelect a documentation version: Current (16.8.0)keyboard_arrow_down\n\n- [Current (16.8.0)](/alloydb/omni/current/docs/protect-data-using-zonal-regional-replication)\n- [16.8.0](/alloydb/omni/16.8.0/docs/protect-data-using-zonal-regional-replication)\n- [16.3.0](/alloydb/omni/16.3.0/docs/protect-data-using-zonal-regional-replication)\n- [15.12.0](/alloydb/omni/15.12.0/docs/protect-data-using-zonal-regional-replication)\n- [15.7.1](/alloydb/omni/15.7.1/docs/protect-data-using-zonal-regional-replication)\n\n\u003cbr /\u003e\n\nThis page describes the AlloyDB Omni Premium Availability reference architecture, which includes data protection using zonal replication in a region (high availability), and adds disaster recovery (DR) protection using asynchronous streaming across large geographic boundaries.\n\n\u003cbr /\u003e\n\nThis reference architecture is best suited for the following use cases:\n\n- You need regional protection in addition to your zonal protection for your mission-critical applications.\n\nThis availability reference architecture incorporates read replicas within the\nregion for HA and across regions for DR. This multi-region deployment safeguards\nagainst significant disruptions, including widespread power failures and\nlarge-scale natural disasters.\n\nAvailability reference architecture considerations\n--------------------------------------------------\n\nWhen you're evaluating this availability reference architecture, consider the\nfollowing factors:\n\n- Network latency and bandwidth within the region and across regions\n- Geographical placement of databases and application servers\n- Strategy for offloading read-only workloads to replicas\n- Deploy high availability in the remote DR region\n\nRead-only load balancing might be required, especially if you use regional\napplication servers, so that requests are forwarded to the closest database for\nthe fastest response. For more information, see\n[Request routing to a multi-region classic Application Load Balancer](/load-balancing/docs/https/setting-up-https).\n\nExtra monitoring might be required for cross-region replication to ensure that\nreplication lag doesn't start to increase due to transaction load or network\ncapacity.\n\nTo ensure that your DR is successful, make sure that you perform thorough DR\ntesting. It's important to test application functionality and throughput if\nthere are any high latency network connections between applications servers and\nthe database.\n\nIn-region HA and cross-region DR architectures\n----------------------------------------------\n\nFigure 1 shows a suggested HA and DR configuration with three read-replica\nstandby databases in three availability zones and two regions.\n| **Note:** While the illustrations in this document show Google Cloud physical location-related concepts such as *Zone* and *Region*, AlloyDB Omni can be deployed in any cloud or any customer-managed environment. Consequently, terms such as \"data center\" or \"city\" might be more suitable to accurately represent your environments.\n\n**Figure 1.** AlloyDB Omni with backups and cross-region high\navailability options.\n\nAs Figure 1 illustrates, synchronous streaming replication to local (within the\nsame region) replicas provides high availability, while asynchronous streaming\nreplication to a geographically separated remote replica provides regional\ndisaster recovery protection. In the entire configuration, only the primary\ninstance can perform read-write operations while the other replicas can serve\nread queries.\n\nConfigure the replication from the primary to in-region replicas in synchronous\nmode while the replication to the cross-region replicas are to be configured in\nasynchronous mode to avoid the latency to impact the primary write performance.\nIn the event of a regional failure, this setup might lead to a non-zero RPO.\nHowever, this setup enables a faster RTO in case of a failure. This is because\nthe primary database doesn't need to wait for confirmation from remote standby\ndatabases before committing transactions.\n\nIt's possible to have additional cross-region backups take backups from the\nread-replica databases and thus add redundancy to the backups taken from the\nprimary database.\n\n### Read replica backups\n\nWhen you use Kubernetes deployments, then the secondary deployment in the\nalternative region is automatically set up with additional backups. When you\nuse non-Kubernetes deployments, then you can choose to deploy backups to suit\nyour business needs. Consider the following:\n\n- If your remote backup might be susceptible to region failure, then you need to initiate extra backups in the alternative regions.\n- If you require backup redundancy, you need to take regional read replica backups.\n\n### Read replica location to support multi-zone availability\n\nIn non-Kubernetes deployments, you can choose specific read replicas to assume\nthe role of the primary in the event of a primary failure. AlloyDB Omni Kubernetes operator\noperator automatically handles the node placement in zones and which nodes the\npods should be deployed to. Some configuration options that affect placement,\nsuch as pod affinity and tolerance, are available in the database configuration\nused to deploy with the AlloyDB Omni operator.\n\n### Migration from an HA-only to HA and DR architecture\n\nFor non-Kubernetes deployments, you need to build a new standby in a new region\nand add this configuration into the Patroni cluster configuration. For\nKubernetes deployments, you need to build a new regional Kubernetes deployment,\ncalled a secondary database cluster, and enable cross-data center replication.\n\nImplementation\n--------------\n\nWhen you choose an availability reference architecture, keep in mind the\nfollowing benefits, limitations, and options.\n\n### Benefits\n\n- Protects from zonal and instance failures\n- Protects from regional failures\n- RTO reduced when the database experiences a regional failure\n\n### Limitations\n\n- You can reduce RPO for regional recovery with synchronous replication, but this approach causes additional latency for transaction performance. For DR and remote region replication, we recommend that you use only asynchronous replication.\n- Configuring PostgreSQL WAL streaming in synchronous mode offers zero data loss (`RPO=0`) during normal operation or typical failovers. However, this approach doesn't protect against data loss in specific double-fault situations, such as when all standby instances are lost or become unreachable from the primary, and this is immediately followed by a primary restart.\n\n### Data protection options\n\n- The [Standard Availability Architecture](/alloydb/omni/current/docs/protect-data-using-backups) for backup and recovery options.\n- The [Enhanced Availability Architecture](/alloydb/omni/current/docs/protect-data-using-zonal-replication) for high availability options.\n\nWhat's next\n-----------\n\n- [AlloyDB Omni availability reference architecture overview](/alloydb/omni/current/docs/database-availability-reference-architecture-overview).\n- [AlloyDB Omni Standard Availability](/alloydb/omni/current/docs/protect-data-using-backups).\n- [AlloyDB Omni Enhanced Availability](/alloydb/omni/current/docs/protect-data-using-zonal-replication).\n- [Work with cross-data-center replication](/alloydb/omni/current/docs/cross-data-center-replication/work-with-cross-data-center-replication).\n- [Request routing to a multi-region classic Application Load Balancer.](/load-balancing/docs/https/setting-up-https)."]]
