Mariadb upgrade scenario testing #594
Conversation
rcmadhankumar
force-pushed
the
tes-mariadb-upgrade
branch
from
4b5f69f
to
0897e5e
Compare
rcmadhankumar
force-pushed
the
tes-mariadb-upgrade
branch
from
0897e5e
to
24e7b06
Compare
| ) -> None: | ||
| mounts = [BindMount(host_path=tmp_path, container_path="/var/lib/mysql")] | ||
| mariadb_old = DerivedContainer( | ||
| base="registry.suse.com/suse/mariadb:10.6", |
There was a problem hiding this comment.
There's no guarantee that you will be able to migrate from 10.6 to newer MariaDB containers.
I believe the test should include a mapping from which version to which newer version, otherwise this test could fail on a new container image, not because it is broken, but because MariaDB does not support migrating 10.6 to version X.Y.
So instead of MARIADB_CONTAINERS it should be passed something like MARIADB_CONTAINERS_UPGRADE_VERSIONS, which would be a tuple, or another map style type.
| f'echo "CREATE TABLE test (id serial PRIMARY KEY, num integer, data varchar(32));" | {mariadb_cmd}' | ||
| ) | ||
| con.check_output( | ||
| f"echo 'INSERT INTO test (num, data) VALUES (100, \"abcdef\")' | {mariadb_cmd}" |
There was a problem hiding this comment.
According to the docs the upgrade touches these:
- Updating the system tables in the mysql database to the newest version. This is very quick.
- mariadb-upgrade also runs mariadb-check --check-upgrade to check if there have been any collation changes between the major versions. This recreates indexes in old tables that are using any of the changed collations. This can take a bit of time if there are a lot of tables or there are many tables which used the changed collation. The last time a collation changed was in MariaDB/MySQL 5.1.23.
It would be nice to touch system tables, such as changing the database charset to a non-standard one.
It would be nice to have a data file that has multiple commands and tables. Ideally creating indexes, so we know that MariaDB can migrate indexes, plus perhaps including more data types than just integer and varchar.
Regular tables are not very likely to break or change unless there's a change in the data type of a column I believe.
There was a problem hiding this comment.
Do we have any existing SQL file that has a good load of data(we might have used in earlier experiments) or would you like to recommend any specific dataset for this or we can create our own random data(with indexes for sure)?
There was a problem hiding this comment.
I don't have any, maybe the maintainer has one. Otherwise, we could grab some dataset from Kaggle if needed.
There's no need to be a big dump, just having a few tables, indexes, and changing things that touch system tables would be sufficient I believe.
[CI:TOXENVS] mariadb
fixes: #504