如果您使用 Cloud SQL Enterprise Plus 版本，可以將跨區域唯讀備用資源指定為災難復原備用資源 (DR 備用資源)，以進行進階災難復原 (DR)。使用進階 DR 時，您可以執行備用資源容錯移轉，以指定的 DR 備用資源取代主要執行個體。舊的主要執行個體會成為升級後災難復原副本的副本。您只能對指派的 DR 備用資源執行備用資源容錯移轉。您還是可以升級其他唯讀備用資源，不必進行容錯移轉。
首先，請在監控資訊主頁中檢查副本執行個體的 Replication Lag 值，這表示副本落後主要執行個體的秒數。主要項目無法使用前一刻的這項指標值，表示交易可能在該時間範圍內遺失。舉例來說，如果 Replication Lag 顯示 5 秒，則副本可能會遺失主要項目在無法使用前 5 秒的寫入內容。(實際遺失的資料量可能少於此值，因為 Replication
Lag 也包含副本已成功接收但尚未套用的交易)。
然後，按照複製狀態頁面中的操作說明 (請參閱「mysql Client」分頁)，使用 MySQL 用戶端連線至副本執行個體。請參閱 Master_Log_File、Read_Master_Log_Pos、Relay_Master_Log_File 和 Exec_Master_Log_Pos 指標的相關操作說明。確認備用資源已處理從主要資源收到的所有交易。確保升級後，備用資源會反映主要資源無法使用前收到的所有交易。
[[["容易理解","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,["# Promote replicas for regional migration or disaster recovery\n\n\u003cbr /\u003e\n\nMySQL \\| [PostgreSQL](/sql/docs/postgres/replication/cross-region-replicas \"View this page for the PostgreSQL database engine\") \\| [SQL Server](/sql/docs/sqlserver/replication/cross-region-replicas \"View this page for the SQL Server database engine\")\n\n\u003cbr /\u003e\n\nThis page describes how to use and promote cross-region read replicas (replicas\ncreated in a different region from that of the primary) for regional migration\nor disaster recovery.\n\nOverview\n--------\n\nThere are two common scenarios for promoting cross-region replicas:\n\n- Regional migration: Perform a planned migration of a database to a different region.\n- Disaster recovery: Fail over a database to another region in the event that the primary's region becomes unavailable.\n\nBoth use cases involve setting up cross-region replication and then promoting\nthe replica. The main difference between them is whether the promotion of the\nreplica is planned (in the case of regional migration) or unplanned (a failover\nto the replica's region is needed to continue operations because the primary has\nbecome unavailable).\n| **Note:** Promoting a replica is done manually and intentionally. It is not the same as [high availability](/sql/docs/mysql/high-availability), where a standby instance (which is not a replica) automatically becomes the primary in case of a failure or zonal outage.\n\nRegional migration\n------------------\n\nYou can use a cross-region replica to migrate your database to another region\nwith minimal downtime. The general idea is to create a replica in another\nregion, wait until replication catches up, promote it, and then direct clients\nto the newly promoted instance.\n\nThe steps involved in promotion are the same as for [promoting an in-region\nreplica](/sql/docs/mysql/replication/manage-replicas#promote-replica); follow those instructions to ensure that the newly\npromoted instance has all of the transactions that were committed to the\noriginal primary instance. Once you have promoted the replica and verified that\nthe newly promoted instance is working, update all database clients to connect\nto the new instance.\n\nDisaster recovery (DR)\n----------------------\n\nCross-region replicas can be used as part of a disaster recovery procedure. You\ncan promote a cross-region replica to fail over to another region should the\nprimary instance's region become unavailable for an extended period of time.\n\nFor more information about disaster recovery, see\n[About disaster recovery in Cloud SQL](/sql/docs/mysql/intro-to-cloud-sql-disaster-recovery).\n\n### Advanced disaster recovery (DR)\n\nIf you are using Cloud SQL Enterprise Plus edition, then you can designate a cross-region read\nreplica\nas a disaster recovery replica (DR replica) for advanced disaster recovery (DR).\nWith advanced DR, you perform a replica failover to replace the\nprimary instance with the designated DR replica.\nThe old primary instance becomes a replica of\nthe promoted DR replica. You can only perform\nreplica failover to the designated DR replica.\nYou can still promote other read replicas without failover.\n\nTo return your deployment to the original state after the replica failover with\nzero data loss, you can perform a switchover. Since the old primary instance is\na replica of the new primary instance, you can switch roles again to restore the\nold primary instance.\n\nFor more information, see [Advanced disaster recovery (DR)](/sql/docs/mysql/intro-to-cloud-sql-disaster-recovery#advanced-dr).\n\n### Verify failover criteria\n\nBecause replication is asynchronous, when a region outage occurs and a\nfailover is attempted, some recent transactions that were committed to the\nprimary may be lost (not replicated to the replica). Whenever a primary instance\nbecomes unavailable, the following steps show (1) how to determine the amount of\ndata, if any, that may have been lost in the cross-region failover and (2) how\nto ensure that the promoted replica reflects as many recent writes as possible.\n\nFirst, check the `Replication Lag` value for the replica instance in\nthe [monitoring dashboard](https://console.cloud.google.com/monitoring/dashboards/resourceList/cloudsql_database), which indicates how far, in seconds, the\nreplica is behind its primary. The value of this metric at the time just before\nthe primary became unavailable indicates the window of time during which\ntransactions committed to the primary may have been lost. For example, if the\n`Replication Lag` showed 5 seconds, then the replica may be missing\nwrites to the primary from the 5 seconds before the primary became unavailable.\n(The true amount of data lost may be less than this because `Replication\nLag` also includes transactions that were successfully received by the\nreplica but simply have not yet been applied.)\n\nThen, connect to the replica instance with a MySQL client by following the\ninstructions in the [replication status](/sql/docs/mysql/replication/manage-replicas#replication-status) page (see the **mysql Client** tab). See the instructions pertaining to the\n`Master_Log_File`, `Read_Master_Log_Pos`,\n`Relay_Master_Log_File`, and `Exec_Master_Log_Pos`\nmetrics. Verify that the replica has processed all the transactions it has\nreceived from the primary. This ensures that when promoted, the replica reflects\nall transactions that were received before the primary became unavailable.\n\n### Promote a read replica\n\nOnce you determine that the failover criteria are met, you can promote one of\nthe replicas to a writeable, standalone instance. Consider the following\nscenario:\n\n- Region A (us-central1) has a High Availability primary instance (db-a-0)\n- Region B (us-west1) has a High Availability cross-region replica (db-b-1) of db-a-0\n- Region C (us-east1) has a cross-region replica (db-c-1) of db-a-0\n\nYou could choose to promote db-b-1 in Region B to become a standalone writable\ninstance.\n\nSee [Promoting a replica](/sql/docs/mysql/replication/manage-replicas#promote-replica) for detailed instructions.\n\n### Ensure the machine type is appropriate\n\nEnsure that the machine type of the newly promoted instance is appropriate for\nits workload by [monitoring metrics on the\ninstance](/sql/docs/mysql/monitor-instance) such as CPU and memory usage.\nIf the newly promoted instance is smaller than its former primary instance, we\nrecommend that you resize the promoted instance to match its former primary so\nthat it can handle the same amount of load.\n\n### Enable high availability for the promoted instance\n\nFor a disaster recovery configuration, we recommend that you configure the\nreplica that you intend to promote as a high-availability replica. Alternatively,\nconfigure the newly promoted instance as high-availability. If you choose not to\nconfigure the read replica with high availability, you can also configure the\ninstance with high availability if and when you promote it.\n\nWhen promoted, read replicas are automatically configured with backups.\nConfiguring a read replica for high availability is done the same way as for a\nprimary instance. For more information, see [configuring the instance for high availability](/sql/docs/mysql/configure-ha#ha-existing).\n\n### Recreate additional replicas\n\nIf you promote a replica to become a primary instance, you need to recreate any\nother replicas of the former primary instance. For example, consider the\nconfiguration referenced [earlier](#promote-a-replica) and repeated\nhere:\n\n- Region A (us-central1) has a High Availability primary instance (db-a-0)\n- Region B (us-west1) has a cross-region replica (db-b-1) of db-a-0\n- Region C (us-east1) has a cross-region replica (db-c-1) of db-a-0\n\nIf the primary instance (db-a-0) becomes unavailable, you can promote the replica\nin region B to become the primary. To again have additional replicas in\nregions A and C, delete the old instances (the former primary instance in A,\nand the replica in C), and\n[create new read replicas](/sql/docs/mysql/replication/create-replica) from the new primary instance in B.\n| **Note:** You need to use different names for the new replicas. The promoted replica retains its original name.\n\nThe resulting configuration would be:\n\n- Region A (us-central1) now has a cross-region replica (db-a-1)\n- Region B (us-west1) now has the primary instance (db-b-1)\n- Region C (us-east1) now has a new cross-region replica (db-c-2)"]]
