+On 2021-11-21, a member of the QA project accidentially de-keyworded +MariaDB 10.6 to address a file collision, users, who also had latest +dev-db/mariadb-connector-c installed, experienced (NOTE: The default
+MySQL connector in Gentoo Linux is provided by
+dev-db/mysql-connector-c) [Link 1].
+However, downgrades are not supported in MySQL/MariaDB [Link 2].
+
+In case you already fully upgraded to MariaDB 10.6 (which includes +executing mysql_upgrade command) and forcefully downgraded your
+MariaDB instance afterwards during the time window when keywords were +removed, you maybe experiencing different problems:
+
+At best, your forcefully downgraded MariaDB instance prevented startup
+so all you have to do is upgrade to MariaDB 10.6 again to resume
+services.
On Thu, 25 Nov 2021, Mike Gilbert wrote:
On Wed, Nov 24, 2021 at 10:21 PM Thomas Deutschmann <whissi@gentoo.org> wrote:
+On 2021-11-21, a member of the QA project accidentially de-keyworded
+MariaDB 10.6 to address a file collision, users, who also had latest
+dev-db/mariadb-connector-c installed, experienced (NOTE: The default
+MySQL connector in Gentoo Linux is provided by
+dev-db/mysql-connector-c) [Link 1].
This sentence is very difficult to read. Also, I don't think it is
relevant to call out the mistake by the QA team in a news item
intended for end users. I would rewrite this as:
On 2021-11-21, keywords for dev-db/mariadb-10.6 were removed to
address a file collision with dev-db/mariadb-connector-c. This unintentionally triggered a version downgrade for users who had
successfully upgraded to dev-db/mariadb-10.6 already.
Bug: https://bugs.gentoo.org/825234Agreed with others in the thread, this is not professional.
Signed-off-by: Thomas Deutschmann <whissi@gentoo.org>
---
...adb-database-restore-maybe-required.en.txt | 46 +++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt
diff --git a/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt b/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt
new file mode 100644
index 0000000..c4a698e
--- /dev/null
+++ b/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt
@@ -0,0 +1,46 @@
+Title: Full MariaDB database restore maybe required
+Author: Thomas Deutschmann <whissi@gentoo.org>
+Posted: 2021-11-23
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Installed: dev-db/mariadb
+Display-If-Installed: sys-cluster/galera
+
+On 2021-11-21, a member of the QA project accidentially de-keyworded
+MariaDB 10.6 to address a file collision, users, who also had latest +dev-db/mariadb-connector-c installed, experienced (NOTE: The defaultThis ^ is a very confusing sentence and is way too long. Needs shortening and re-wording, too much commas.
+MySQL connector in Gentoo Linux is provided by
+dev-db/mysql-connector-c) [Link 1].
+
+However, downgrades are not supported in MySQL/MariaDB [Link 2].
+
+In case you already fully upgraded to MariaDB 10.6 (which includes +executing mysql_upgrade command) and forcefully downgraded your
+MariaDB instance afterwards during the time window when keywords were +removed, you maybe experiencing different problems:
+
+At best, your forcefully downgraded MariaDB instance prevented startup
+so all you have to do is upgrade to MariaDB 10.6 again to resume
+services.
+
+In case previous MariaDB version was able to start, you are encouraged
+to do a full backup as soon as possible using mysqldump command and +manually restore each database ("logical downgrade") to prevent any
+data corruption.
+
+Depending on used feature set and from which version you upgraded,
+it is maybe required to do a full restore from a previous backup before +MariaDB 10.6 upgrade to restore services and prevent any data loss or +future runtime errors.
+
+In case you are using MariaDB in a cluster and/or Galera setup you
+probably have to rebuild the entire cluster in case the upgrade to
+MariaDB 10.6 was already replicated (using pt-table-checksum from +dev-db/percona-toolkit can help you to validate your cluster).
+
+Keep in mind that due to the forced downgraded, point-in-time recovery
+may not be available to the extent that you are used to.
+
+Link 1: https://bugs.gentoo.org/825234#c8
+
+Link 2: https://mariadb.com/kb/en/downgrading-between-major-versions-of-mariadb/
--
2.34.0
Hi,
On 2021-11-25 04:49, Mike Gilbert wrote:
On 2021-11-21, keywords for dev-db/mariadb-10.6 were removed to
address a file collision with dev-db/mariadb-connector-c. This unintentionally triggered a version downgrade for users who had successfully upgraded to dev-db/mariadb-10.6 already.
Works for me. However, I would write dev-db/mariadb:10.6. Is that
acceptable for you?
I don't like the phrase "forcefully downgraded" here. This implies
that something happened without the user's consent. emerge would have informed them of the downgrade before it happened. I would suggest
removing the word "forcefully" from these paragraphs.
If you do a normal world upgrade, this is the default portage behavior,
not? I.e. package manager will downgrade if you don't stop. And
especially on servers, people tend to use cronjobs/scripts to do that...
And forcefully here refers to the undesirable result (at least that was
my intention). Something the user doesn't want.
I don't like the phrase "forcefully downgraded" here. This implies
that something happened without the user's consent. emerge would have informed them of the downgrade before it happened. I would suggest removing the word "forcefully" from these paragraphs.
If you do a normal world upgrade, this is the default portage behavior, not? I.e. package manager will downgrade if you don't stop. And
especially on servers, people tend to use cronjobs/scripts to do that...
Something happening by default is not the same as forcing it to happen.
Using a cron job or other blind automation to do package upgrades on
any production system is a bad idea. We certainly do not recommend
that to people, nor force them to do it.
As a side note, maybe ebuild should add sanity checks (like those from glibc) to
prevent downgrades, otherwise people could still accidentally hit the issue
Hi,
On 25/11/2021 16.50, Pacho Ramos wrote:
As a side note, maybe ebuild should add sanity checks (like those from glibc) to
prevent downgrades, otherwise people could still accidentally hit the
issue
You might have valid use cases to downgrade mysql, if you are okay not preserving data. I'd assume it's a common knowledge that downgrade of
any data store, be that database or likes like elasticsearch, will
corrupt the data.
To make it actually useful I think we'd need new EAPI feature 'downgrade-protection', that unless is explicit ignored like --ignore-downgrade-protection mysql, it would prevent it from happening.
-- Piotr.
https://github.com/gentoo/gentoo/blob/master/sys-libs/glibc/glibc-2.34-r2.ebuild#L643
Would you see something like this on more ebuilds, postgres, mysql, elasticsearch, or have proper FEATURE flag for it instead?
It's all cool and giggles until you realize that even such random
variable is not even prefixed with PORTAGE_ or anything, meaning it
could be taken out of shell and meant for entirely different thing.
https://github.com/gentoo/gentoo/blob/master/sys-libs/glibc/glibc-2.34-r2.ebuild#L643
https://github.com/gentoo/gentoo/blob/master/sys-libs/glibc/glibc-2.34-r2.ebuild#L643
Would you see something like this on more ebuilds, postgres, mysql, elasticsearch, or have proper FEATURE flag for it instead?
On 25 Nov 2021, at 03:21, Thomas Deutschmann <whissi@gentoo.org> wrote:
Bug: https://bugs.gentoo.org/825234
Signed-off-by: Thomas Deutschmann <whissi@gentoo.org>
---
[snip]
+On 2021-11-21, a member of the QA project accidentially de-keyworded +MariaDB 10.6 to address a file collision, users, who also had latest +dev-db/mariadb-connector-c installed, experienced (NOTE: The default
+MySQL connector in Gentoo Linux is provided by
+dev-db/mysql-connector-c) [Link 1].
+
+However, downgrades are not supported in MySQL/MariaDB [Link 2].
+Link 1: https://bugs.gentoo.org/825234#c8
On 25 Nov 2021, at 17:07, Thomas Deutschmann <whissi@gentoo.org> wrote:
On 2021-11-25 18:01, Piotr Karbowski wrote:
https://github.com/gentoo/gentoo/blob/master/sys-libs/glibc/glibc-2.34-r2.ebuild#L643Would you see something like this on more ebuilds, postgres, mysql, elasticsearch, or have proper FEATURE flag for it instead?
It's all cool and giggles until you realize that even such random variable is not even prefixed with PORTAGE_ or anything, meaning it could be taken out of shell and meant for entirely different thing.
Yeah, sounds like the I_KNOW_WHAT_I_AM_DOING thing which you end up having enabled globally for various reasons.
On 25 Nov 2021, at 17:07, Thomas Deutschmann <whissi@gentoo.org> wrote:
On 2021-11-25 18:01, Piotr Karbowski wrote:
https://github.com/gentoo/gentoo/blob/master/sys-libs/glibc/glibc-2.34-r2.ebuild#L643Would you see something like this on more ebuilds, postgres, mysql, elasticsearch, or have proper FEATURE flag for it instead?
It's all cool and giggles until you realize that even such random variable is not even prefixed with PORTAGE_ or anything, meaning it could be taken out of shell and meant for entirely different thing.
Yeah, sounds like the I_KNOW_WHAT_I_AM_DOING thing which you end up having enabled globally for various reasons.
Just like updating in a cron job is a not-great idea, setting this globally and not per-package via /etc/portage/env sounds rather cavalier.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 90:15:41 |
| Calls: | 6,658 |
| Files: | 12,203 |
| Messages: | 5,334,090 |