Skip to content

chore: gdb regions improvements - #679

Open
karenc-bq wants to merge 1 commit into
dev/v3from
chore/gdb-regions
Open

chore: gdb regions improvements#679
karenc-bq wants to merge 1 commit into
dev/v3from
chore/gdb-regions

Conversation

@karenc-bq

Copy link
Copy Markdown
Contributor

Summary

Description

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@karenc-bq
karenc-bq force-pushed the chore/gdb-regions branch from 9af7ec7 to 28c68b9 Compare July 30, 2026 01:35
@karenc-bq
karenc-bq marked this pull request as ready for review August 4, 2026 17:29
@karenc-bq
karenc-bq requested a review from a team as a code owner August 4, 2026 17:29
return undefined;
}

async filterAvailableHosts(hosts: HostInfo[], accessibleRegions: string[]): Promise<HostInfo[]> {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: since the method is optional do we even need the implementations for plain mysql and pg dialects? Does it help performance wise to have them? Bc my understanding is that when this is not implemented it has the same behavior as returning all hosts

);
}

async filterAvailableHosts(hosts: HostInfo[], accessibleRegions: string[]): Promise<HostInfo[]> {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We only call this once it seems, from the failover plugins, I'm curious why we have the same method defined in two dialects that doesn't seem to be dialect independent - can't we handle this filtering in a shared location?

if (!this.accessibleRegions) {
return hosts;
}
return hosts.filter((host) => {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this is similar logic to what is in the dialects - we can probably handle it in the accessible_regions file in utils

"or specific regions. Possible values include: strict-writer-primary, strict-writer-secondary, " +
"strict-reader-primary, strict-reader-secondary, writer-or-reader-primary, writer-or-reader-secondary, " +
"or a specific AWS region name.",
null

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't the default be strict-writer-primary

const lowerRegions = accessibleRegions.map((r) => r.toLowerCase());
return hosts.filter((host) => {
const region = this.rdsUtils.getRdsRegion(host.host);
return region !== null && lowerRegions.includes(region.toLowerCase());

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return region !== null && lowerRegions.includes(region.toLowerCase());
return region !== null && lowerRegions.includes(region);

Pretty sure we put it into lower case accesible_regions parsing

this.accessibleRegions = AccessibleRegions.parse(properties);

if (this.accessibleRegions) {
logger.debug(`GlobalAuroraTopologyMonitor: accessible regions = ${this.accessibleRegions.join(",")}`);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be stored in messages?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants