Sign inTry Free

Important

Helios features are now enabled during weekly update windows and are no longer directly tied to SingleStore engine releases. Refer to the release notes to view the latest features available in your Helios cluster.

Global Endpoints

On this page

Note

This feature is in Preview and available only for Enterprise clusters on AWS.

Global Endpoints simplifies the application connectivity portion of disaster recovery. It provides a single, stable private endpoint for a pair of SingleStore clusters. The endpoint switches between clusters during failover and failback, so applications can continue using the same connection string when failing over to another region.

Smart DR failover and failback are initiated separately through the Portal or API; the endpoint does not start these operations automatically.

How Global Endpoints Works

Without Global Endpoints, an application connects to the regional endpoint of a specific cluster. After a Smart DR failover, the promoted cluster becomes active and the application must be updated to use the secondary cluster's endpoint.

With Global Endpoints:

  • Applications connect to one stable private hostname.

  • Before failover, the endpoint routes traffic to the write cluster.

  • After a failover, Global Endpoints routes the endpoint to the newly active cluster.

  • After failback, SingleStore routes the endpoint back to the initial write cluster.

  • The endpoint name and application connection string remain unchanged.

Global Endpoints keeps the connection string unchanged during failover, but an already-open database connection may still be interrupted. Application retry logic will ensure that connections succeed when reconnecting.

Users create the VPC endpoints. SingleStoremanages the Private Networking (PrivateLink) services, the hosted zone, and the routing decision. Because the hosted zone is managed by SingleStore and the VPC is managed by the user, users must authorize the association once during setup so the two can be linked.

Sample Scenarios

Scenario

What it covers

Planned DR drill or switchover

Rehearse or perform a controlled regional switch without touching application configuration, which makes drills cheap to run and repeat.

Unplanned regional failover

Recover from a region failure without tracking down every application owner to repoint connection strings mid-incident.

Failback

Return to the original primary once it recovers, using the same endpoint and the same process as failover.

Recovery Options

Global Endpoints support two common recovery scenarios:

Scenario 1: When Only the Database Failsover

In this scenario, the application remains available in the original region but the database must fail over.

If a problem occurs that impacts only the SingleStore cluster or database while the application and its region remain healthy, failing over only the database lets the application keep running, avoiding an unnecessary application failover. This reduces recovery work because the application continues using the same connection string.

The typical action steps are:

  1. The application continues running in Region A.

  2. You initiate Smart DR failover.

  3. The secondary cluster in Region B becomes active.

  4. The Global Endpoint routes new connections to Region B.

  5. The application continues using the same connection string over a private cross-region path.

However in such cases, requests may experience additional latency since the application and database are in different regions.

Scenario 2: When the Application and Database Both Failover

In this scenario, a broader disruption requires both the application and database to move.

If a broader regional disruption affects both the application and SingleStore cluster, you can fail over both to the secondary region. This restores the application and database into the same region, allowing your application to resume local communication without the added latency of cross-region access. The Global Endpoint lets the application continue using the same connection string during recovery.

The typical action steps are:

  1. The application moves to Region B.

  2. You initiate Smart DR failover.

  3. The secondary cluster in Region B becomes active.

  4. The application uses the same Global Endpoint as before the failover.

  5. The endpoint routes traffic to the active cluster in Region B.

This preserves regional locality when the application and database are deployed in both regions. Configure Global Endpoint connectivity for each VPC where the application may run.

Prerequisites

Before configuring a Global Endpoint, confirm that:

  • Smart DR is configured on the cluster being failed over between regions.

  • The databases that you want to protect are being replicated.

  • Replication is active and the secondary cluster is available as the failover destination.

  • The cluster uses AWS PrivateLink.

  • An AWS VPC is available for each application environment that will connect to the active cluster.

  • The user has permission to create AWS VPC endpoints in the application VPCs.

Run the AWS CLI command provided by SingleStore to associate the application VPC with the SingleStore managed Private Hosted Zone (PHZ). Once validated, applications in that VPC can use a stable Global Endpoint that connects privately to the active SingleStore cluster.

Configure a Global Endpoint

Complete the following steps for each application VPC that may run during recovery.

Step 1: Configure Smart DR

Create the primary cluster and configure Smart DR replication to a secondary region. Select the databases to protect and verify that replication is active.

Step 2: Pre-provision the Secondary Cluster

Pre-provision the secondary cluster before you need it for recovery. This allows you to configure private connectivity in advance. After private connectivity is configured, you can suspend the secondary cluster if you want to reduce ongoing compute costs.

Step 3: Configure PrivateLink for both Clusters

In the Portal:

  1. Open Access and Security for the primary cluster.

  2. Create an inbound PrivateLink connection.

  3. Enable cross-region access for the secondary region.

  4. Repeat the configuration for the secondary cluster, enabling access from the primary region.

Step 4: Create AWS VPC Endpoints

In each application VPC, create two AWS VPC endpoints:

  • One endpoint for the primary SingleStore cluster.

  • One endpoint for the secondary SingleStore cluster.

Note the DNS names of both VPC endpoints.

Step 5: Add the PrivateLink Configuration to Smart DR

In the Portal, open PrivateLinks for Smart DR and provide:

  • The application VPC ID.

  • The AWS region for the application VPC.

  • The DNS name of the primary VPC endpoint.

  • The DNS name of the secondary VPC endpoint.

Repeat this step for every VPC where the application may run.

Step 6: Authorize and Validate Private DNS

SingleStore creates the private DNS configuration and provides an AWS CLI command to associate it with your VPC.

  1. Run the provided command from the AWS account that owns the VPC.

  2. Return to the Portal.

  3. Validate the association.

  4. Confirm that the Global Endpoint resolves from the application VPC.

Step 7: Update the Application Connection String

Update the application to use the Global Endpoint instead of the regional endpoint for either cluster. This is the only endpoint change required in the application configuration.

Use the same connection string during:

  • Normal operation.

  • Smart DR failover.

  • Smart DR failback.

Failover and Failback Behavior

Global Endpoints follow the active cluster, but you remain responsible for initiating Smart DR operations.

During Failover

  1. Initiate Smart DR failover through the Portal or API.

  2. Smart DR promotes the secondary cluster.

  3. SingleStore updates the Global Endpoint routing.

  4. Applications reconnect through the same hostname after the secondary cluster is ready.

During Failback

  1. Confirm that the original primary cluster is healthy.

  2. Initiate Smart DR failback through the Portal or API.

  3. Smart DR returns the active role to the original primary cluster.

  4. SingleStore routes the Global Endpoint back to that cluster.

  5. Applications continue using the same connection string.

Design Applications for Reconnects

A Global Endpoint removes the need to change connection strings. It does not preserve connections that were established with the previous active cluster.

When failover begins, existing connections may be interrupted. Applications may temporarily receive connection errors, timeouts, or unavailable responses while the secondary cluster is promoted and endpoint routing changes take effect.

Configure standard retry and reconnect behavior in the application or database client:

  • Check for failed or stale connections.

  • Close and recreate connections when required.

  • Retry requests according to your application's safety and idempotency requirements.

  • Use bounded backoff rather than retrying continuously.

  • Allow enough time for the secondary cluster and endpoint routing to become ready.

  • Log reconnect attempts and failures so that recovery can be monitored.

Test this behavior during a planned DR exercise. Test both the remote cross-region and local-access patterns when both are part of your recovery plan.

Troubleshooting Checklist

If an application cannot connect through the Global Endpoint, verify the following:

  • The application is running in a VPC configured under Private Links for Smart DR.

  • Both primary and secondary AWS VPC endpoints were created in that VPC.

  • The submitted VPC endpoint DNS names are correct.

  • The private DNS association command was run from the AWS account that owns the VPC.

  • Private DNS association was successfully validated in the Portal.

  • Smart DR has completed the failover or failback and the target cluster is ready.

  • The application has retried or recreated connections that were open before failover.

  • Cross-region latency is acceptable when using the remote cross-region pattern.

Last modified:

Was this article helpful?

On this page

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined

  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined

  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
        cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
          --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
          --bundle undefined \
          --new-bundle-format -
    Verified OK

Try Out This Notebook to See What’s Possible in SingleStore

Get access to other groundbreaking datasets and engage with our community for expert advice.

Sign UpLog In