Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://cloud.google.com/sql/docs/postgres/replication/external-server below:

About replicating from an external server | Cloud SQL for PostgreSQL

Stay organized with collections Save and categorize content based on your preferences.

This page describes a configuration that replicates data from a source database server to PostgreSQL replicas. This configuration is sometimes referred to as an external server configuration.

The source database server can be any PostgreSQL server, including servers running on other Google Cloud services (such as Cloud SQL or Compute Engine) or on other cloud providers (such as Amazon RDS), if they meet the requirements. For step-by-step instructions for setting up this configuration, see Replicating from an external server.

External server configuration helps you achieve the following goals:

1. Migrate your data from your self-managed PostgreSQL server to Google Cloud with a minimum of downtime.

2. Retain colocation and control of your server while off-loading the administration of the replicas to Cloud SQL.

   This use case is sometimes called a hybrid cloud. Replication between your self-managed server and the Cloud SQL replica continues indefinitely.

External replication configuration includes the following instances:

• The PostgreSQL server that you manage, also called the source database server.

• The Cloud SQL replica.

  There can be multiple replicas for a single source database server.

• The source representation instance.

  The source representation instance is a Cloud SQL instance that represents the source database server to the Cloud SQL replica. It is visible in the Google Cloud console and appears the same as a regular Cloud SQL instance, but it contains no data, requires no configuration or maintenance, and does not affect billing.

The following diagram shows these instances:

Replicating from an external server requires that all changes to the data be sent between the source database server and the Cloud SQL replicas.

If the connection is made over a public network (by using IP allowlists), Google recommend using SSL/TLS encryption for the connection between the source and destination databases.

Cloud SQL offers the following options for SSL/TLS configuration:

• None: the Cloud SQL destination instance connects to the source database without encryption.
• Server-only authentication

When the replica connects to the primary instance, the replica authenticates the primary instance. This helps make sure the replica connects to the correct host and helps prevent on-path attacks. The primary instance doesn't authenticate the replica.

To use server-only authentication, at replica creation time, provide the x509 PEM-encoded certificate of the certificate authority (CA) that signed the external server's certificate. The CA must contain only a single certificate, and it must be self signed. In other words, the Certificate Authority that signed the server's certificate must be a root CA.

If the external server's server CA certificate is expiring, then rotate the SSL certificates, including the server CA certificate on the on-premises instance.

For more information, see Manage SSL/TLS certificates.

You can create multiple replicas from the same source database server. You might want to provide more bandwidth or create replicas in different regions.

If you're creating multiple replicas in the same region, they can all use the same source representation instance or different ones. If you use the Google Cloud console to create multiple replicas, they will have different source representation instances.

If you're creating multiple replicas in different regions, they must have different source representation instances.

You cannot create more than one replica in the same operation. As soon as you finish creating the replica configuration for the first replica, you can start creating the replica configuration for the other replicas. You don't need to wait until the first replica is completely functional before starting to create other replicas.

Cascading read replicas let you create a read replica under another read replica in the same or different region. You can add up to four levels of cascading replicas, including the primary instance. When you promote the replica at the top of a cascading replica hierarchy, it becomes the primary instance and its cascading replicas continue to replicate.

With external servers, you can create read replicas under an external server replica after migrating your data, but before promoting the external server replica to primary. This lets you test read replica topologies before the external server replica is promoted.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-07-02 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-07-02 UTC."],[],[]]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4