Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Esta página oferece uma visão geral da replicação entre regiões do AlloyDB para PostgreSQL.
Com a replicação entre regiões do AlloyDB, é possível criar clusters e instâncias secundárias de um cluster principal para disponibilizar os recursos em diferentes regiões, no caso de uma interrupção na região principal. Esses clusters e instâncias secundários funcionam como cópias dos recursos do cluster e da instância principal.
Os principais conceitos desta página incluem:
Cluster principal. Um cluster de leitura/gravação em uma única região.
Cluster secundário. Um cluster somente leitura em uma região diferente da principal, que replica do cluster principal de forma assíncrona.
No caso de falha de um cluster principal do AlloyDB, é possível
promover um cluster secundário para principal.
É possível criar até cinco clusters secundários para um cluster principal. Todos os clusters secundários replicam de um único cluster principal. Se você
promover um cluster secundário, ele se tornará um cluster
principal independente.
Instância secundária. Um líder somente leitura de um cluster secundário. Ele é
responsável por receber um stream de replicação de um cluster principal. O fluxo de replicação atualiza o volume de armazenamento na região secundária com base no volume de armazenamento na região principal.
Se um cluster secundário for promovido a principal, a instância secundária
se tornará a instância principal.
Uma instância secundária pode ser básica (zonal) ou de alta disponibilidade (regional).
O diagrama a seguir ilustra como a replicação entre regiões funciona:
Figura 1. Exemplo de arquitetura de replicação entre regiões do AlloyDB.
Vantagens
Estes são os benefícios da replicação entre regiões no AlloyDB:
Recuperação de desastres. Se a região do cluster principal ficar
indisponível, será possível promover recursos do AlloyDB em outra região
para atender às solicitações.
Redução da inatividade. O suporte à alta disponibilidade (HA) em clusters secundários
reduz o tempo de inatividade durante eventos de manutenção ou falhas não planejadas.
Dados distribuídos geograficamente. Distribuir os dados geograficamente os aproxima de você e diminui a latência de leitura.
Escalonamento de leitura aumentado:cada réplica entre regiões (ou cluster secundário) pode oferecer suporte a até 20 nós de leitura, permitindo que você aumente ainda mais as leituras.
Alternância sem perda de dados. Para
configurações de replicação entre regiões, o AlloyDB oferece suporte à alternância entre
instâncias principal e secundária sem perda de dados.
Trabalhar com a replicação entre regiões
Trabalhar com a replicação entre regiões do AlloyDB envolve as seguintes tarefas:
Crie um cluster secundário.
Um cluster secundário é uma cópia atualizada continuamente do cluster principal do AlloyDB.
Ver um cluster secundário.
Depois de criar um cluster secundário, é possível conferir os detalhes dele na página Clusters do Google Cloud console.
Adicione instâncias do pool de leitura.
É possível adicionar instâncias de pool de leitura a um cluster secundário. Se você quiser escalonar horizontalmente a capacidade de leitura, adicione até 20 nós de leitura ao cluster secundário.
Promova um cluster secundário.
É possível ler os dados de um cluster secundário, mas não gravar neles
até que ele seja promovido a um cluster principal independente e completo. Quando você
promove um cluster secundário, a instância secundária do cluster também é
promovida como uma instância principal com recursos de leitura e gravação.
O principal caso de uso para promover um cluster secundário é a recuperação de desastres.
Se ocorrer uma interrupção regional na região do cluster principal, é possível
promover o cluster secundário para um cluster principal independente e
retomar a veiculação do aplicativo.
Alternância sem perda de dados.
A alternância permite reverter os papéis dos clusters principal e secundário
sem perda de dados. É possível fazer uma alternância para testar
a configuração de recuperação de desastres ou migrar sua carga de trabalho. Quando
você concluir a alternância, a direção da replicação
será invertida.
Se você tiver vários clusters secundários, o cluster que receber o comando de failover vai se tornar um cluster principal. O cluster principal anterior vai se tornar um cluster secundário, replicando do novo cluster principal. Todos os outros clusters secundários passam a replicar do novo cluster principal.
Há dois cenários comuns para fazer failover do cluster secundário:
Simulados de recuperação de desastres. É possível executar testes dos processos de recuperação de desastres
alternando o aplicativo para outra região sem perda de dados
para simular uma interrupção regional.
Migração regional. Faça uma migração planejada dos recursos do AlloyDB da região principal para outra. A alternância garante
que o cluster secundário se torne um cluster principal com objetivo de ponto de recuperação (RPO) zero, garantindo que
a migração não perca nenhum dado.
Configure backups automáticos e contínuos.
Por padrão, o AlloyDB copia automaticamente as configurações de backup automatizado e
contínuo do cluster principal para um cluster secundário
recém-criado. Se você quiser usar configurações de backup diferentes para
o cluster secundário, modifique a configuração de backup ao
criar um cluster secundário.
Se o cluster principal usar a criptografia de chave de criptografia gerenciada pelo cliente (CMEK)
para backups, faça uma destas ações ao criar um cluster secundário:
Forneça as configurações de criptografia da CMEK para os backups do cluster secundário.
Desative os backups do cluster secundário.
Para mais informações sobre como criptografar seus backups com CMEK, consulte
Usar CMEK
É possível modificar as configurações de backup automatizado e contínuo do cluster secundário após a criação dele.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-25 UTC."],[[["\u003cp\u003eAlloyDB cross-region replication creates read-only secondary clusters and instances in different regions, which mirror a primary cluster's data.\u003c/p\u003e\n"],["\u003cp\u003eSecondary clusters can be promoted to fully functional primary clusters in the event of a primary cluster failure, enabling disaster recovery.\u003c/p\u003e\n"],["\u003cp\u003eCross-region replication offers benefits like reduced downtime, geographic data distribution, geographic load balancing, and switchover with zero data loss.\u003c/p\u003e\n"],["\u003cp\u003eSecondary clusters can have up to 20 read nodes, allowing for increased read scaling capabilities.\u003c/p\u003e\n"],["\u003cp\u003eWorking with cross-region replication involves tasks such as creating and viewing secondary clusters, adding read pool instances, promoting secondary clusters, and performing switchovers with zero data loss.\u003c/p\u003e\n"]]],[],null,["# Cross-region replication overview\n\nThis page provides an overview of AlloyDB for PostgreSQL cross-region replication.\n\nAlloyDB cross-region replication lets you create secondary\nclusters and instances from a primary cluster to make the resources available in\ndifferent regions, in the event of an outage in the primary region. These\nsecondary clusters and instances function as copies of your primary cluster and\ninstance resources.\n\nKey concepts in this page include the following:\n\n- **Primary cluster.** A read-write cluster in a single region.\n\n- **Secondary cluster.** A read-only cluster in a different region than the primary,\n that replicates from the primary cluster asynchronously.\n In the event of a failure of an AlloyDB primary cluster, you can\n promote a secondary cluster to a primary cluster.\n\n You can create up to five secondary clusters for a primary cluster. All of\n the secondary clusters replicate from a single primary cluster. If you\n promote a secondary cluster, that secondary cluster becomes an independent\n primary cluster.\n- **Secondary instance.** A read-only leader of a secondary cluster. It is\n responsible for receiving a replication stream from a primary cluster. The\n replication stream updates the storage volume in the secondary region based on\n the storage volume in the primary region.\n If a secondary cluster is promoted to a primary cluster, the secondary instance\n becomes the primary instance.\n\n A secondary instance can be either basic (zonal) or high-availability\n (regional).\n\n The following diagram illustrates how cross-region replication works:\n\n**Figure 1.** Example of AlloyDB cross-region replication architecture.\n\nBenefits\n--------\n\nThe benefits of cross-region replication on AlloyDB include the\nfollowing:\n\n- **Disaster recovery.** In the event the primary cluster's region becomes\n unavailable, you can promote AlloyDB resources in another region\n to serve requests.\n\n- **Reduced downtime.** Support of high availability (HA) on secondary clusters\n reduces downtime during maintenance events or unplanned outages.\n\n- **Geographically distributed data.** Distributing the data geographically brings\n the data closer to you and decreases read latency.\n\n- **Increased read scaling:** Each cross-region replica (or secondary cluster)\n can support up to 20 read nodes, allowing you to scale your reads further.\n\n- **Switchover with zero data loss.** For\n cross-region replication setups, AlloyDB supports switchover between\n primary and secondary instance with zero data loss.\n\nWork with cross-region replication\n----------------------------------\n\n| **Note:** You cannot enable advanced query insights features for AlloyDB on instances in cross-region replica clusters. See [Limitations](/alloydb/docs/advanced-query-insights-overview#limitations) and [FAQ](/alloydb/docs/using-advanced-query-insights#advanced-query-insights-features-with-secondary-clusters) for more information.\n\nWorking with AlloyDB cross-region replication involves the following tasks:\n\n- [**Create a secondary cluster.**](/alloydb/docs/cross-region-replication/work-with-cross-region-replication#secondary-cluster-instance)\n A secondary cluster is a continuously updated copy of your AlloyDB\n primary cluster.\n\n- [**View a secondary cluster.**](/alloydb/docs/cross-region-replication/work-with-cross-region-replication#view-secondary-cluster)\n After you create a secondary cluster, you can view its details in the **Clusters**\n page in the Google Cloud console.\n\n- [**Add read pool instances.**](/alloydb/docs/cross-region-replication/work-with-cross-region-replication#read-pools-secondary-cluster)\n You can add read pool instances to a secondary cluster. If you want to scale your read\n capacity horizontally, you can add up to 20 read nodes to your secondary cluster.\n\n- [**Promote a secondary cluster.**](/alloydb/docs/cross-region-replication/work-with-cross-region-replication#promote-secondary-cluster)\n You can read the data from a secondary cluster, but you can't write to it\n until you promote it to a fully-featured, standalone primary cluster. When you\n promote a secondary cluster, the cluster's secondary instance is also\n promoted as a primary instance with read and write capabilities.\n\n The primary use case for promoting a secondary cluster is disaster recovery.\n If a regional outage occurs in your primary cluster's region, you can\n promote your secondary cluster to a standalone primary cluster, and\n resume serving your application.\n- [**Switchover with zero data loss.**](/alloydb/docs/cross-region-replication/work-with-cross-region-replication#switchover-secondary)\n Switchover lets you reverse the roles of your primary and secondary cluster\n with zero data loss. You can perform a switchover for testing\n your disaster recovery setup or performing migration of your workload. When\n you complete the switchover, the direction of replication\n is reversed.\n\n If you have multiple secondary clusters, the secondary cluster that receives\n the switchover command becomes a primary cluster; the previous primary\n cluster becomes a secondary cluster, replicating from the new primary\n cluster. All other secondary clusters switch to replicating from the new\n primary cluster.\n\n There are two common scenarios for switching over your secondary cluster:\n - **Disaster recovery drills.** You can run tests of your disaster recovery processes by switching your application over to another region with zero data loss to simulate a regional outage.\n - **Regional migration.** Perform a planned migration of the AlloyDB resources from their primary region to another region. Switchover ensures the secondary cluster becomes a primary cluster with 0 Recovery Point Objective (RPO), ensuring that the migration does not lose any data.\n- [**Configure automated and continuous backups.**](/alloydb/docs/backup/configure)\n By default, AlloyDB automatically copies automated and\n continuous backup configurations from the primary cluster to a newly created\n secondary cluster. If you want to use different backup configurations for\n your secondary cluster, you can modify the backup configuration when you\n create a secondary cluster.\n\n If your primary cluster uses customer-managed encryption key (CMEK) encryption\n for backups, do one of the following when you create a secondary cluster:\n - Provide CMEK encryption settings for the secondary cluster's backups.\n - Disable backups for the secondary cluster.\n\nFor more information about encrypting your backups with CMEK, see\n[Use CMEK](/alloydb/docs/use-cmek)\n\nYou can modify automated and continuous backup settings for the secondary\ncluster after its creation.\n\nWhat's next\n-----------\n\n- [Working with cross-region replication](/alloydb/docs/cross-region-replication/work-with-cross-region-replication)"]]
