Proxy-based disaster recovery

Proxy-based disaster recovery for Active-Active databases.

If you add a lightweight proxy software component between the clients and the Active-Active database, applications can dynamically route requests to the optimal endpoint.

Advantages:

• Proxies provide proactive and reactive health check methods, such as polling target health periodically using either a TCP connection or an HTTP request, or monitoring live operations for errors.

• Proxies can be configured to run Active-Active health checks, such as the lag-aware database availability requests.

• If an Active-Active database member fails, a proxy can automatically detect the issue and redirect traffic to a healthy Active-Active database member without requiring DNS propagation delays or client disconnections. This enables fast, controlled failover and minimizes downtime.

Considerations:

• If you do not use DNS to resolve the Active-Active database members' FQDNs:

  • The proxies must have static IPs.

  • If you add a new node to the cluster, you must configure the proxy with the new endpoint.

  • A configuration syncer component is required to discover topology changes and reconfigure the proxy.

• Proxies introduce latency.

• Proxy failures can disconnect clients and cause disruptions.

Avoid concurrent access across replicas

If concurrent access across replicas must be avoided in every scenario, you can use a centralized proxy with a standby proxy instance for high availability.

Advantages:

• Prevents concurrent access across replicas.

• Failover and failback are simultaneous regardless of the Active-Active health check policy.

Considerations:

• Although the proxy can be monitored with a watchdog and restarted in case of failure, this setup does not grant high availability for the proxy.

• Limited scalability.

The following diagram shows a centralized proxy architecture with a standby proxy instance:

Co-locate to reduce latency and improve scalability

To reduce latency and improve scalability, you can use a proxy co-located in the application server.

Advantages:

• Reduced latency.

• Better scalability.

Considerations:

• Failover and failback might not be simultaneous depending on the Active-Active health check policy.

The following diagram shows a co-located proxy architecture where each application server has its own proxy:

Pool proxies for scalability

You can use a pool of active proxies to scale the routing layer. Application servers can balance new connections to the pool of proxies using a round-robin distribution algorithm, such as DNS-based round robin.

Advantages:

• High availability without complex monitoring and failover solutions.

• Flexible scalability of the routing layer.

Considerations:

• Concurrent access across replicas is possible, but can be mitigated using database availability API requests.

The following diagram shows a pool of proxies: