-
-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Blog: MariaDB breaking change in dump format #210
Conversation
Deploying ddev-com-front-end with
|
Latest commit: |
79f80da
|
Status: | ✅ Deploy successful! |
Preview URL: | https://673969e4.ddev-com-front-end.pages.dev |
Branch Preview URL: | https://20240613-mariadb.ddev-com-front-end.pages.dev |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few small nitpicks and suggestions. overall the article is good and helpful!
|
||
You can read the details in the innocently titled article [MariaDB Dump File Compatibility Change](https://mariadb.org/mariadb-dump-file-compatibility-change/) | ||
|
||
## What does it mean To my DDEV projects? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
## What does it mean To my DDEV projects? | |
## What does it mean to my DDEV projects? |
|
||
### DDEV v1.23.1 | ||
|
||
If you are using DDEV v1.23.1, we mitigated this problem at some levels by updating the DDEV v1.23.1 `ddev-dbserver` image. This solved a number of problems related to `ddev import-db` and `ddev export-db` because the format used was the new (breaking-change) MariaDB format. If you see this on `ddev import-db` or `ddev export-db` you can update to the newer version using the appropriate command below: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you are using DDEV v1.23.1, we mitigated this problem at some levels by updating the DDEV v1.23.1 `ddev-dbserver` image. This solved a number of problems related to `ddev import-db` and `ddev export-db` because the format used was the new (breaking-change) MariaDB format. If you see this on `ddev import-db` or `ddev export-db` you can update to the newer version using the appropriate command below: | |
If you are already on DDEV v1.23.1, we've mitigated this problem to a certain extent by updating the `ddev-dbserver` image for this release. This solved a number of problems related to `ddev import-db` and `ddev export-db` because the format used was the new MariaDB format containing the breaking change. If you see this on `ddev import-db` or `ddev export-db` you can update to the newer version using the appropriate command below: |
And what does "if you see this" refer to? to me it is not clear at all. i thought the snippet underneath are the instructions for updating to the newer version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And what does "if you see this" refer to?
If you see the disaster in importing.
We think we have worked around the majority of these cases in DDEV v1.23.2, see below. | ||
|
||
But: | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We think we have worked around the majority of these cases in DDEV v1.23.2, see below. | |
But: | |
We think we have worked around the majority of these cases in DDEV v1.23.2, see the next section. | |
But before, be aware: | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We think we have worked around the majority of these cases in DDEV v1.23.2, see below. | |
But: | |
We think we have worked around the majority of these cases in DDEV v1.23.2 (see the [next section](#what-has-ddev-done-to-mitigate-the-damage-inv1232)). | |
However, be aware: | |
|
||
`/*!999999\- enable the sandbox mode */` | ||
|
||
This directive/content is incompatible with all versions of the `mysql` or `mariadb` database client from all vendors from before that May 17, 2024. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This directive/content is incompatible with all versions of the `mysql` or `mariadb` database client from all vendors from before that May 17, 2024. | |
This directive is incompatible with all versions of the `mysql` or `mariadb` database client from all vendors prior May 17, 2024. |
not sure if the slash content is necessary? content confused me more than that it explained things. is it content or a directive or both? personally i would stick to just directive?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from all vendors prior to May 17, 2024
or you could just go with
from all vendors before May 17, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't even know before that mysqldump
in MariaDB context is just a symlink to mariadb-dump
, or that MariaDB has been rebranding all of its tools. So that's why I used the slash all the time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
10.4 was a symlink to mariadb-dump. 10.5+ was a symlink the other way. As incompatibilities slowly creap in its important for users to know difference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand your point @grooverdan , but a PR to this would be welcome. The current situation (mariadb 10.11 for example, is that mysqldump is a symlink to mariadb-dump:
$ mysql --version
mysql Ver 15.1 Distrib 10.11.8-MariaDB, for debian-linux-gnu (aarch64) using EditLine wrapper
rfay@d10-db:~$ ls -l $(which mysqldump)
lrwxrwxrwx 1 root root 12 May 10 23:02 /usr/bin/mysqldump -> mariadb-dump
- DevOps | ||
--- | ||
|
||
## What happened with MariaDB and MysqlDump? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
## What happened with MariaDB and MysqlDump? | |
## What happened with MariaDB and MySQL Dump? |
since later in the article it is referred to mariadb-dump and mysqldump it is probably better it use the correct word mark for MySQL since isnt referring to mariadb and mysqldump but to mariadb dump and mysql dump?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good article!
I noticed a few mistakes that @rpkoller has already fixed (thanks!), but luckily I didn't finish my review before him, so we avoided conflicts in the suggestions.
Co-authored-by: Ralf Koller <1665422+rpkoller@users.noreply.github.com>
Thanks for your suggestions! |
I reviewed this and it makes sense to me as well. Thanks everyone! |
The Issue
Blog about MariaDB breaking change in dump format
Rendered at https://20240613-mariadb.ddev-com-front-end.pages.dev/blog/mariadb-dump-breaking-change/