Make WordPress Core

Opened 5 weeks ago

Last modified 5 days ago

#47738 reopened defect (bug)

Misleading database server version shown when using proxySQL

Reported by: wpfed Owned by: SergeyBiryukov
Milestone: 5.3 Priority: normal
Severity: minor Version: 5.2.2
Component: Site Health Keywords: has-patch commit dev-feedback 2nd-opinion
Focuses: Cc:



My current hosting company uses a proxySQL instance between the site and the actual DB servers, this causes site-health checkup tool to report the proxySQL server version as 5.5.30 when the actual DB MySQL servers(backing cluster) are version 5.7.26.

Is this correct behavior for the site-health checkup tool or misleading?

This information is found in WordPress admin dashboard under tools->Site Health->Info->Database

Attachments (1)

47738.patch (1.6 KB) - added by Clorith 4 weeks ago.

Download all attachments as: .zip

Change History (12)

#1 follow-up: @Clorith
5 weeks ago

Hi there, and welcome to WordPress trac!

Is this only being misreported on the Info page, or is it also incorrect on the Site Health page that runs the automated checks against your site as well for you?

#2 in reply to: ↑ 1 @wpfed
5 weeks ago

Replying to Clorith:

Hi there, and welcome to WordPress trac!

Is this only being misreported on the Info page, or is it also incorrect on the Site Health page that runs the automated checks against your site as well for you?

Hi, thanks!

Only on the Info Page, I have no error relating to MySQL version on the status page.
The info page also lists: Database host mysql_proxy

Is their a check done to disregard version number if mysql_proxy is detected?

4 weeks ago

#3 @Clorith
4 weeks ago

  • Keywords has-patch commit added
  • Milestone changed from Awaiting Review to 5.2.3

I see the version check is doing it in two different ways here, and it looks like the one done for the debug information lands on the proxy server (relying on the connection details provided by mysqli_get_server_info, which would be the proxy, while the site health section actually performs an SQL query of SELECT VERSION(), so that's the actual backend server.

After some investigating, it seems like the debug page is the correct approach here, as doing version verification should be performed using native features when possible.

These areas are also doing the checks within the code, and not using the WP wrapper, we'll resolve this by moving both checks over to using WPDB::db_version() (which uses mysqli_get_server_info() behind the scenes at this time, and is what anything using WP should be checking against).

47738.patch changes this behavior in both places. In your case this does mean you'll receive a warning about a version mismatch in the site health module as well in the future, unless the proxy server is configured to report a version that matches the back-end server.

#4 @SergeyBiryukov
4 weeks ago

  • Owner set to SergeyBiryukov
  • Resolution set to fixed
  • Status changed from new to closed

In 45691:

Site Health: Consistently use wpdb::db_version() for checking the database server version, instead of partically replicating its functionality.

Props Clorith, wpfed.
Fixes #47738.

#5 @SergeyBiryukov
4 weeks ago

  • Keywords fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for 5.2.3 consideration.

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.

10 days ago

#7 @Clorith
9 days ago

So I just pushed this change to the Health Check plugin, which has shown a possible issue with this implementation.

At some point, I don't know when, PHP's native drivers for MySQL seems to have stopped stripping a prefix-hack away from the MariaDB version string, making the use of $wpdb->db_version() give incorrect outputs in a lot of cases.

I'm not sure if the right approach is to revert this and use the manual approach like before, but in both locations, or to make changes to the db_version() function call. (I see there's quite a few tickets about the latter). The most accurate approach of course being to perform a SQL query, but that's not reliable if an SQL connection doesn't exist (for the core context at least).

#8 @JeffPaul
7 days ago

  • Keywords dev-feedback 2nd-opinion added

This ticket was mentioned in Slack in #core by marybaum. View the logs.

5 days ago

#10 @marybaum
5 days ago

  • Milestone changed from 5.2.3 to 5.3

#11 @SergeyBiryukov
5 days ago

  • Keywords fixed-major removed

Keeping open for now to address the concerns in comment:7.

Note: See TracTickets for help on using tickets.