Global cluster limitations with New Global writer end point

[bhanurhce]

Hello - Thanks for an outstanding wrapper software built around the JDBC driver.

It is regarding the usage of wrapper with Global cluster(Multi-AZ), we tested thoroughly with multiAZ regional failovers. Also, the new Global writer, in both cases the Wrapper plugin for Aurora PostgreSQL seamlessly detected the new writer DNS and we didn't require to restart the Applications pods. We saw application failures while the failover times, however, once the writer is available Application was able to pick the new writer without any pod restarts. Our questions is, are the limitations in using the wrapper with the Global cluster is still a concern and if we tend to use it, any idea on what would be the major unforeseen issue?

Thanks!

[bhanurhce]

Hello - It would be really great, if you get some time to take a look on the above question. Please. Thanks a ton.

[karenc-bq]

Hi @bhanurhce,
This driver current does not support switchover of Amazon Aurora Global Databases, but has limited support with the primary region for planned failover. While it is possible to connect to global databases, failing over to a secondary cluster will result in errors and there may be additional unforeseen errors when working with global databases. Support for Amazon Aurora Global Databases is in the backlog, but we cannot comment on a timeline right now.
See the table below for what is supported:

Failover Mode	Supported Plugins for GDB primary region	Supported Plugins for GDB secondary region
strict_writer	failover and failover2	not supported
strict_reader	failover and failover2	failover
reader_or_writer	failover and failover2	failover

[karenc-bq]

To answer your question about potential unforeseen issues, if you are using a global writer endpoint with the wrapper and failover occurs on a secondary cluster, the initial connection may be compromised. This is because the wrapper does not recognize global writer endpoints and will not be able to replace it with the correct instance endpoint.

[bhanurhce]

Thank you very much for the detailed response Karen.

If i can take leverage to extend our results while testing the JDBC wrapper.

UseCase-1: Global Aurora Postgres cluster with Hikari JDBC+ Wrapper, application has two rest end points, one read and one write. We issued a Multi-AZ Switchover within the region, Wrapper picked up the changes and drastically reduced the write failures with recovery time under 7sec. Also, we repeated the same multiple times within the same cluster and always Wrapper picked host ip's promptly.

UseCase-2: Global Aurora Postgres cluster with Hikari JDBC+ Wrapper, application has two rest end points, one read and one write.
we issued a Regional Switch(usw2-->use2) and vice versa, always Writer IP was promptly picked and handed over to JDBC driver, minimizing the downtimes drastically(No need of POD restarts or config changes).

Our Testing Cluster: Global cluster with - 1 writer, 3 Readers.

We are eager to understand what other factors contributed here to work & curious to know if there is any logging/debug-logging can be enabled to understand more.. So that we can come to a conclusion.

Thank you very much again!
Bhanu.

[sergiyvamz]

Hi @bhanurhce

I'll do my best to explain all scenarios where the wrapper can perform failover successfully and when it couldn't. The main contributing factors are:

• A host used in the driver connection string. It could be a Global writer endpoint, regional writer endpoint, regional reader endpoint, or an instance endpoint. Some of mentioned endpoints may not be applicable in some cases.
• What region (primary or secondary) a user app connects to. Failover support is partially supported in secondary regions.
• Desired failover mode. The wrapper supports strict-writer, reader-or-writer and strict-reader modes. More details are here.
  https://github.com/aws/aws-advanced-jdbc-wrapper/blob/main/docs/using-the-jdbc-driver/using-plugins/UsingTheFailoverPlugin.md#failover-parameters
• Whether cluster failover or switchover occurs within region or between regions.

The use cases you mentioned may work or may not depending on the factors mentioned above. For instance, UseCase-1 works fine if we assume that a user application connects to a primary region. All failover modes are supported in this case.
At the same time, the same UseCase-1 scenario where a user application connects to a secondary region works just partially. If the wrapper is configured with strict-reader failover mode it works properly. However, strict-writer won't work
since the wrapper driver couldn't reconstruct a writer endpoint in a primary region and couldn't connect to it.

To summarize, here's a list of configurations to avoid since they are not supported:

• Avoid using a Global Writer endpoint. The Wrapper driver doesn't recognize it and couldn't effectively replace with a new writer endpoint if needed.
• Avoid using failoverMode=strict-writer when connecting to a secondary region. The Wrapper can't connect to a writer node in another region.
• Using failoverMode=reader-or-writer when connected to a secondary region will effectively reconnect to a reader node in the same secondary region if failover occurs.

You can increase the log level to FINEST in order to get the most of driver internal settings and processes. Please check here for more details.
https://github.com/aws/aws-advanced-jdbc-wrapper/blob/main/docs/using-the-jdbc-driver/UsingTheJdbcDriver.md#enable-logging

Full support for Global Endpoints are on our roadmap, so we do have plans on increasing support in these areas.

I hope that answers your question.