Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette page présente la réplication interrégionale AlloyDB pour PostgreSQL.
La réplication interrégionale AlloyDB vous permet de créer des clusters et des instances secondaires à partir d'un cluster principal afin de rendre les ressources disponibles dans différentes régions en cas d'indisponibilité dans la région principale. Ces clusters et instances secondaires fonctionnent comme des copies de vos ressources de cluster et d'instance principales.
Voici les principaux concepts abordés sur cette page :
Cluster principal : Cluster en lecture/écriture dans une seule région.
Cluster secondaire. Cluster en lecture seule situé dans une région différente de celle du cluster principal et qui effectue une réplication à partir du cluster principal de manière asynchrone.
En cas de défaillance d'un cluster principal AlloyDB, vous pouvez promouvoir un cluster secondaire en cluster principal.
Vous pouvez créer jusqu'à cinq clusters secondaires pour un cluster principal. Tous les clusters secondaires effectuent une réplication à partir d'un seul cluster principal. Si vous promouvez un cluster secondaire, il devient un cluster principal indépendant.
Instance secondaire. Leader en lecture seule d'un cluster secondaire. Il est chargé de recevoir un flux de réplication à partir d'un cluster principal. Le flux de réplication met à jour le volume de stockage dans la région secondaire en fonction du volume de stockage dans la région principale.
Si un cluster secondaire est promu en cluster principal, l'instance secondaire devient l'instance principale.
Une instance secondaire peut être de base (zonale) ou à haute disponibilité (régionale).
Le schéma suivant illustre le fonctionnement de la réplication multirégionale :
Figure 1 : Exemple d'architecture de réplication AlloyDB multirégionale.
Avantages
Voici les avantages de la réplication interrégionale sur AlloyDB :
Reprise après sinistre : Si la région du cluster principal devient indisponible, vous pouvez promouvoir les ressources AlloyDB d'une autre région pour répondre aux requêtes.
Réduction des temps d'arrêt : La prise en charge de la haute disponibilité (HA) sur les clusters secondaires réduit les temps d'arrêt lors des événements de maintenance ou des pannes imprévues.
Données réparties géographiquement : La distribution géographique des données les rapproche de vous et réduit la latence en lecture.
Scaling de lecture amélioré : chaque réplica multirégion (ou cluster secondaire) peut prendre en charge jusqu'à 20 nœuds de lecture, ce qui vous permet de faire évoluer davantage vos lectures.
Basculement sans perte de données. Pour les configurations de réplication interrégionales, AlloyDB permet le basculement entre l'instance principale et l'instance secondaire sans perte de données.
Utiliser la réplication interrégionale
L'utilisation de la réplication AlloyDB interrégionale implique les tâches suivantes :
Créez un cluster secondaire.
Un cluster secondaire est une copie de votre cluster principal AlloyDB qui est mise à jour en continu.
Affichez un cluster secondaire.
Une fois que vous avez créé un cluster secondaire, vous pouvez afficher ses détails sur la page Clusters de la console Google Cloud .
Ajoutez des instances de pool de lecture.
Vous pouvez ajouter des instances de pool de lecture à un cluster secondaire. Si vous souhaitez faire évoluer horizontalement votre capacité de lecture, vous pouvez ajouter jusqu'à 20 nœuds de lecture à votre cluster secondaire.
Promouvoir un cluster secondaire
Vous pouvez lire les données d'un cluster secondaire, mais vous ne pouvez pas y écrire tant que vous ne l'avez pas promu en cluster principal autonome et complet. Lorsque vous promouvez un cluster secondaire, l'instance secondaire du cluster est également promue en tant qu'instance principale avec accès en lecture et écriture.
Le principal cas d'utilisation de la promotion d'un cluster secondaire est la reprise après sinistre.
En cas d'indisponibilité régionale dans la région de votre cluster principal, vous pouvez promouvoir votre cluster secondaire en cluster principal autonome et reprendre la diffusion de votre application.
Basculement sans perte de données
Le basculement vous permet d'inverser les rôles de votre cluster principal et de votre cluster secondaire sans aucune perte de données. Vous pouvez effectuer une permutation pour tester votre configuration de reprise après sinistre ou migrer votre charge de travail. Lorsque vous effectuez la commutation, le sens de la réplication est inversé.
Si vous avez plusieurs clusters secondaires, celui qui reçoit la commande de basculement devient un cluster principal. L'ancien cluster principal devient un cluster secondaire, qui réplique les données à partir du nouveau cluster principal. Tous les autres clusters secondaires passent à la réplication à partir du nouveau cluster principal.
Il existe deux scénarios courants pour basculer vers votre cluster secondaire :
Exercices de reprise après sinistre : Vous pouvez tester vos processus de reprise après sinistre en basculant votre application vers une autre région sans perte de données pour simuler une indisponibilité régionale.
Migration régionale : Effectuez une migration planifiée des ressources AlloyDB de leur région principale vers une autre région. Le basculement garantit que le cluster secondaire devient un cluster principal avec un objectif de point de récupération (RPO) de 0, ce qui permet de s'assurer qu'aucune donnée n'est perdue lors de la migration.
Configurez des sauvegardes automatiques et continues.
Par défaut, AlloyDB copie automatiquement les configurations de sauvegarde automatique et continue du cluster principal vers un cluster secondaire nouvellement créé. Si vous souhaitez utiliser des configurations de sauvegarde différentes pour votre cluster secondaire, vous pouvez modifier la configuration de sauvegarde lorsque vous créez un cluster secondaire.
Si votre cluster principal utilise le chiffrement avec clé de chiffrement gérée par le client (CMEK) pour les sauvegardes, effectuez l'une des opérations suivantes lorsque vous créez un cluster secondaire :
Fournissez les paramètres de chiffrement CMEK pour les sauvegardes du cluster secondaire.
Désactivez les sauvegardes pour le cluster secondaire.
Pour en savoir plus sur le chiffrement de vos sauvegardes avec CMEK, consultez Utiliser CMEK.
Vous pouvez modifier les paramètres de sauvegarde automatisée et continue pour le cluster secondaire après sa création.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/25 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)"]]
