Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
Description
mariadb-upgrade-service.exe is currently not tested prior to releases. It is broken (as in completely disfunctional), currently due to CONC-760, and it was similarly broken before in MDEV-30639
While the intention is to use it for cross-version upgrades on Windows, neither old nor new buildbot had integrated upgrade scenarios, with 2 major version side-by-side. where a service instance is migrated from 10.x->11.x
First step to avoid regression, would be just to tests mariadb-upgrade-service.exe using windows service, to emulate "upgrade" from/to the same version, in MTR
What the utility does is service stop, start mariadbd for upgrade, run mariadb-upgrade, change service definition to point to mariadbd.exe with different full path, restart service
All of that can be tried with single version only, "path to different mariadbd.exe in service config" will actually be path to the same mysqld.exe
With even such a trivial test is in place, we could have caught both CONC-760 and MDEV-30639
A slight challenge is that the utility assumes that mysqld.exe, mysql_upgrade.exe and mariadbd.exe all reside in the same directory, which is true for installations, but currently the "build" layout differs from that.
Update: according to a comment in MDEV-19430, this scenario of cross-version upgrades is allegedly tested on enterprise builds by the CI, but it is not and never was in community server.
Attachments
Issue Links
- relates to
-
CONC-760 valid named pipe connection is closed, if reconnect is set
-
- Closed
-
-
-
- Closed
-
-
-
- Open
-
-
-
- Closed
-
- links to
Activity
| Field | Original Value | New Value |
|---|---|---|
| Priority | Critical [ 2 ] | Major [ 3 ] |
| Description |
mariadb-upgrade-service.exe is currently not tested prior to releases. It is broken (as in completely disfunctional), currently due to While the intention is to use it for cross-version upgrades on Windows, neither old nor new buildbot had integrated upgrade scenarios, with 2 major version side-by-side. where a service instance is migrated from 10.x->11.x A first step would be just to use it on windows service without actual upgrade. Basics can be tested with single version only What the utility does is service stop, start mariadbd for upgrade, run mariadb-upgrade, change service definition to point to mariadbd.exe with different full path, restart service All of that can be tried with single version only, path to different mariadbd.exe in service config will be path to the same mysqld.exe A slight challenge is that the utility assumes that mysqld.exe, mysql_upgrade.exe and mariadbd.exe all reside in the same directory, which is true for installations, but currently the "build" layout differs from that. |
mariadb-upgrade-service.exe is currently not tested prior to releases. It is broken (as in completely disfunctional), currently due to While the intention is to use it for cross-version upgrades on Windows, neither old nor new buildbot had integrated upgrade scenarios, with 2 major version side-by-side. where a service instance is migrated from 10.x->11.x A first step would be just to use it on windows service without actual upgrade. Basics can be tested with single version only What the utility does is service stop, start mariadbd for upgrade, run mariadb-upgrade, change service definition to point to mariadbd.exe with different full path, restart service All of that can be tried with single version only, path to different mariadbd.exe in service config will be path to the same mysqld.exe A slight challenge is that the utility assumes that mysqld.exe, mysql_upgrade.exe and mariadbd.exe all reside in the same directory, which is true for installations, but currently the "build" layout differs from that. |
| Link | This issue relates to MDEV-19430 [ MDEV-19430 ] |
| Description |
mariadb-upgrade-service.exe is currently not tested prior to releases. It is broken (as in completely disfunctional), currently due to While the intention is to use it for cross-version upgrades on Windows, neither old nor new buildbot had integrated upgrade scenarios, with 2 major version side-by-side. where a service instance is migrated from 10.x->11.x A first step would be just to use it on windows service without actual upgrade. Basics can be tested with single version only What the utility does is service stop, start mariadbd for upgrade, run mariadb-upgrade, change service definition to point to mariadbd.exe with different full path, restart service All of that can be tried with single version only, path to different mariadbd.exe in service config will be path to the same mysqld.exe A slight challenge is that the utility assumes that mysqld.exe, mysql_upgrade.exe and mariadbd.exe all reside in the same directory, which is true for installations, but currently the "build" layout differs from that. |
mariadb-upgrade-service.exe is currently not tested prior to releases. It is broken (as in completely disfunctional), currently due to While the intention is to use it for cross-version upgrades on Windows, neither old nor new buildbot had integrated upgrade scenarios, with 2 major version side-by-side. where a service instance is migrated from 10.x->11.x First step, and a better place to catch, would be just to use it on windows service without actual upgrade. Basics can be tested with single version only, as we already have some tests for services in MTR. What the utility does is service stop, start mariadbd for upgrade, run mariadb-upgrade, change service definition to point to mariadbd.exe with different full path, restart service All of that can be tried with single version only, path to different mariadbd.exe in service config will be path to the same mysqld.exe A slight challenge is that the utility assumes that mysqld.exe, mysql_upgrade.exe and mariadbd.exe all reside in the same directory, which is true for installations, but currently the "build" layout differs from that. Update: according to a comment in MDEV-19430, this scenario of cross-version upgrades is allegedly tested on enterprise builds by the CI, but it is not and never was in community server. |
| Description |
mariadb-upgrade-service.exe is currently not tested prior to releases. It is broken (as in completely disfunctional), currently due to While the intention is to use it for cross-version upgrades on Windows, neither old nor new buildbot had integrated upgrade scenarios, with 2 major version side-by-side. where a service instance is migrated from 10.x->11.x First step, and a better place to catch, would be just to use it on windows service without actual upgrade. Basics can be tested with single version only, as we already have some tests for services in MTR. What the utility does is service stop, start mariadbd for upgrade, run mariadb-upgrade, change service definition to point to mariadbd.exe with different full path, restart service All of that can be tried with single version only, path to different mariadbd.exe in service config will be path to the same mysqld.exe A slight challenge is that the utility assumes that mysqld.exe, mysql_upgrade.exe and mariadbd.exe all reside in the same directory, which is true for installations, but currently the "build" layout differs from that. Update: according to a comment in MDEV-19430, this scenario of cross-version upgrades is allegedly tested on enterprise builds by the CI, but it is not and never was in community server. |
mariadb-upgrade-service.exe is currently not tested prior to releases. It is broken (as in completely disfunctional), currently due to While the intention is to use it for cross-version upgrades on Windows, neither old nor new buildbot had integrated upgrade scenarios, with 2 major version side-by-side. where a service instance is migrated from 10.x->11.x First step, and a better place to catch, would be just to use it on windows service without actual upgrade. Basics can be tested with single version only, as we already have some tests for services in MTR. What the utility does is service stop, start mariadbd for upgrade, run mariadb-upgrade, change service definition to point to mariadbd.exe with different full path, restart service All of that can be tried with single version only, "path to different mariadbd.exe in service config" will actually be path to the same mysqld.exe A slight challenge is that the utility assumes that mysqld.exe, mysql_upgrade.exe and mariadbd.exe all reside in the same directory, which is true for installations, but currently the "build" layout differs from that. Update: according to a comment in MDEV-19430, this scenario of cross-version upgrades is allegedly tested on enterprise builds by the CI, but it is not and never was in community server. |
| Link |
This issue relates to |
| Description |
mariadb-upgrade-service.exe is currently not tested prior to releases. It is broken (as in completely disfunctional), currently due to While the intention is to use it for cross-version upgrades on Windows, neither old nor new buildbot had integrated upgrade scenarios, with 2 major version side-by-side. where a service instance is migrated from 10.x->11.x First step, and a better place to catch, would be just to use it on windows service without actual upgrade. Basics can be tested with single version only, as we already have some tests for services in MTR. What the utility does is service stop, start mariadbd for upgrade, run mariadb-upgrade, change service definition to point to mariadbd.exe with different full path, restart service All of that can be tried with single version only, "path to different mariadbd.exe in service config" will actually be path to the same mysqld.exe A slight challenge is that the utility assumes that mysqld.exe, mysql_upgrade.exe and mariadbd.exe all reside in the same directory, which is true for installations, but currently the "build" layout differs from that. Update: according to a comment in MDEV-19430, this scenario of cross-version upgrades is allegedly tested on enterprise builds by the CI, but it is not and never was in community server. |
mariadb-upgrade-service.exe is currently not tested prior to releases. It is broken (as in completely disfunctional), currently due to While the intention is to use it for cross-version upgrades on Windows, neither old nor new buildbot had integrated upgrade scenarios, with 2 major version side-by-side. where a service instance is migrated from 10.x->11.x First step, and a better place to catch, would be just to use it on windows service without actual upgrade. Basics can be tested with single version only, as we already have some tests for services in MTR. What the utility does is service stop, start mariadbd for upgrade, run mariadb-upgrade, change service definition to point to mariadbd.exe with different full path, restart service All of that can be tried with single version only, "path to different mariadbd.exe in service config" will actually be path to the same mysqld.exe With even such a trivial test is in place, we could have caught both A slight challenge is that the utility assumes that mysqld.exe, mysql_upgrade.exe and mariadbd.exe all reside in the same directory, which is true for installations, but currently the "build" layout differs from that. Update: according to a comment in MDEV-19430, this scenario of cross-version upgrades is allegedly tested on enterprise builds by the CI, but it is not and never was in community server. |
| Affects Version/s | 10.6 [ 24028 ] | |
| Affects Version/s | 10.11 [ 27614 ] | |
| Affects Version/s | 11.4 [ 29301 ] | |
| Affects Version/s | 11.8 [ 29921 ] | |
| Issue Type | Bug [ 1 ] | Task [ 3 ] |
| Description |
mariadb-upgrade-service.exe is currently not tested prior to releases. It is broken (as in completely disfunctional), currently due to While the intention is to use it for cross-version upgrades on Windows, neither old nor new buildbot had integrated upgrade scenarios, with 2 major version side-by-side. where a service instance is migrated from 10.x->11.x First step, and a better place to catch, would be just to use it on windows service without actual upgrade. Basics can be tested with single version only, as we already have some tests for services in MTR. What the utility does is service stop, start mariadbd for upgrade, run mariadb-upgrade, change service definition to point to mariadbd.exe with different full path, restart service All of that can be tried with single version only, "path to different mariadbd.exe in service config" will actually be path to the same mysqld.exe With even such a trivial test is in place, we could have caught both A slight challenge is that the utility assumes that mysqld.exe, mysql_upgrade.exe and mariadbd.exe all reside in the same directory, which is true for installations, but currently the "build" layout differs from that. Update: according to a comment in MDEV-19430, this scenario of cross-version upgrades is allegedly tested on enterprise builds by the CI, but it is not and never was in community server. |
mariadb-upgrade-service.exe is currently not tested prior to releases. It is broken (as in completely disfunctional), currently due to While the intention is to use it for cross-version upgrades on Windows, neither old nor new buildbot had integrated upgrade scenarios, with 2 major version side-by-side. where a service instance is migrated from 10.x->11.x First step to avoid regression, would be just to tests mariadb-upgrade-service.exe using windows service, to emulate "upgrade" from/to the same version, in MTR What the utility does is service stop, start mariadbd for upgrade, run mariadb-upgrade, change service definition to point to mariadbd.exe with different full path, restart service All of that can be tried with single version only, "path to different mariadbd.exe in service config" will actually be path to the same mysqld.exe With even such a trivial test is in place, we could have caught both A slight challenge is that the utility assumes that mysqld.exe, mysql_upgrade.exe and mariadbd.exe all reside in the same directory, which is true for installations, but currently the "build" layout differs from that. Update: according to a comment in MDEV-19430, this scenario of cross-version upgrades is allegedly tested on enterprise builds by the CI, but it is not and never was in community server. |
| Remote Link | This issue links to "Bug report from a user, on Zulip (Web Link)" [ 37417 ] |
| Link |
This issue causes |
| Link |
This issue causes |
| Link |
This issue relates to |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Assignee | Vladislav Vaintroub [ wlad ] | Oleksandr Byelkin [ sanja ] |
| Status | In Progress [ 3 ] | In Review [ 10002 ] |
| Assignee | Oleksandr Byelkin [ sanja ] | Vladislav Vaintroub [ wlad ] |
| Status | In Review [ 10002 ] | Stalled [ 10000 ] |
| issue.field.resolutiondate | 2025-03-31 17:07:32.0 | 2025-03-31 17:07:32.055 |
| Fix Version/s | 10.11.12 [ 29998 ] | |
| Fix Version/s | 10.11 [ 27614 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Stalled [ 10000 ] | Closed [ 6 ] |