feat: gdb failover support#1246
Open
karenc-bq wants to merge 2 commits into
Open
Conversation
karenc-bq
force-pushed
the
feat/gdb-failover
branch
from
410a5e4 to
052135f
Compare
sophia-bq
approved these changes
Jun 9, 2026
Comment on lines
+185
to
+187
| GdbFailoverPlugin.UnsupportedFailoverMode=[GdbFailover] Unsupported failover mode: {} | ||
|
|
||
| GlobalDbFailoverMode.InvalidValue=[GlobalDbFailoverMode] Invalid Global Database failover mode value: '{}'. |
Contributor
There was a problem hiding this comment.
Nit: should we maybe decide on one way to have it presented to the client? ie. Gdb or GlobalDb?Just for consistency
| Please refer to the [failover configuration guide](../FailoverConfigurationGuide.md) for tips to keep in mind when using the failover plugins. | ||
|
|
||
| > [!WARNING] | ||
| > Do not use the `gdb_failover`, `failover`, and/or `failover_v2` plugins (or their combination) at the same time for the same connection! |
Contributor
There was a problem hiding this comment.
Suggested change
| > Do not use the `gdb_failover`, `failover`, and/or `failover_v2` plugins (or their combination) at the same time for the same connection! | |
| > Do not use any combination of the `gdb_failover`, `failover`, and/or `failover_v2` plugins at the same time for the same connection! |
| > [!WARNING] | ||
| > Do not use the `gdb_failover`, `failover`, and/or `failover_v2` plugins (or their combination) at the same time for the same connection! | ||
|
|
||
| The GDB Failover Plugin requires a Global Aurora dialect. Set `dialect` to `global-aurora-mysql` or `global-aurora-pg`, and provide the per-region instance host patterns via `global_cluster_instance_host_patterns`. For complete Aurora Global Database configuration, see the [Aurora Global Databases](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html) documentation. |
Contributor
There was a problem hiding this comment.
Is this the correct link? I feel like it should be a link to our docs for these parameters or that we should have a separate paragraph for the amazon configuration info
|
|
||
| **Example 1** | ||
|
|
||
| When a user application needs a writer connection, it makes sense to define the failover mode to follow the writer (`strict-writer`). However, some applications may choose not to follow a writer node when cross-region failover occurs (see [Configuration Example 3](#configuration-example-3) below). |
Contributor
There was a problem hiding this comment.
Suggested change
| When a user application needs a writer connection, it makes sense to define the failover mode to follow the writer (`strict-writer`). However, some applications may choose not to follow a writer node when cross-region failover occurs (see [Configuration Example 3](#configuration-example-3) below). | |
| When a user application needs a writer connection, it makes sense to define the failover mode to follow the writer (`strict-writer`). However, some applications may choose not to follow a writer host when cross-region failover occurs (see [Configuration Example 3](#configuration-example-3) below). |
Just a note that we probably want to use host over node throughout the docs
| # Roles in the host list might be stale, so verify the role with a query. | ||
| role = plugin_service.get_host_role(candidate_conn) if verify_role is not None else None | ||
| if verify_role is None or verify_role == role: | ||
| updated_host_info = HostInfo( |
Contributor
There was a problem hiding this comment.
Do we always need to update the host - what if the role the query returns is the same as it was before? Just wondering if we lose some aspects of the host info by recreating it?
| self._active_home_failover_mode = GlobalDbFailoverMode.from_value( | ||
| WrapperProperties.ACTIVE_HOME_FAILOVER_MODE.get(self._properties)) | ||
| self._inactive_home_failover_mode = GlobalDbFailoverMode.from_value( | ||
| WrapperProperties.INACTIVE_HOME_FAILOVER_MODE.get(self._properties)) |
Contributor
There was a problem hiding this comment.
I know it's a change to design but we do trigger failover if we are connected to a reader and get a read-only exception on a write in failover v1 and v2 - should we set failover_mode here so that that also happens for gdb?
# For STRICT_WRITER failover mode when connection exception indicate that the connection's in read-only mode, initiate a failover by returning true.
return self._failover_mode == FailoverMode.STRICT_WRITER and \
self._plugin_service.is_read_only_connection_exception(exception)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Added GDB Failover support.
Added retry writer connection logic to GDB Failover and Failover 2 plugin.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.