Add logic for upgrading datadir #215
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
[test-openshift] |
4 similar comments
|
[test-openshift] |
|
[test-openshift] |
|
[test-openshift] |
|
[test-openshift] |
|
@hhorak can you update common scripts to get more waiting time for docker registry? |
|
[test-openshift] |
MySQL and MariaDB use versions that consist of three numbers X.Y.Z (e.g. 5.6.23). For version changes in Z part, the server's binary data format stays compatible and thus no special upgrade procedure is needed. For upgrades from X.Y to X.Y+1, consider doing manual steps as described at https://mariadb.com/kb/en/library/upgrading-from-mariadb-101-to-mariadb-102/ Skipping versions like from X.Y to X.Y+2 or downgrading to lower version is not supported; the only exception is ugrading from MariaDB 5.5 to MariaDB 10.0. **Important**: Upgrading to a new version is always risky and users are expected to make a full back-up of all data before. A safer solution to upgrade is to dump all data using `mysqldump` or `mysqldbexport` and then load the data using `mysql` or `mysqldbimport` into an empty (freshly initialized) database. Another way of proceeding with the upgrade is starting the new version of the `mysqld` daemon and run `mysql_upgrade` right after the start. This so called in-place upgrade is generally faster for large data directory, but only possible if upgrading from the very previous version, so skipping versions is not supported. This container detects whether the data needs to be upgraded using `mysql_upgrade` and we can control it by setting `MYSQL_UPGRADE` variable, which can have one or more of the following values: * `warn` -- If the data version can be determined and the data come from a different version of the daemon, a warning is printed but the container starts. This is the default value. Since historically the version file `mysql_upgrade_info` was not created, when using this option, the version file is created if not exist, but no `mysql_upgrade` will be called. However, this automatic creation will be removed after few months, since the version should be created on most deployments at that point. * `auto` -- `mysql_upgrade` is run at the beginning of the container start, if the data version can be determined and the data come with the very previous version. A warning is printed if the data come from even older or newer version. This value effectively enables automatic upgrades, but it is always risky and users should still back-up all the data before starting the newer container. Set this option only if you have very good back-ups at any moment and you are fine to fail-over from the back-up. * `force` -- `mysql_upgrade` is run right after the daemon has started, no matter what version the data come from. This is also the way to create the missing version file `mysql_upgrade_info` if not present in the root of the data directory; this file holds information about the version of the data. * `optimize` -- runs `mysqlcheck --optimize` before starting the mysqld daemon, no matter what version of the data is detected. It optimizes all the tables. * `analyze` -- runs `mysqlcheck --analyze` before starting the mysqld daemon, no matter what version of the data is detected. It analyzes all the tables. * `disable` -- nothing is done regarding data directory version. Multiple values are separated by comma and run in-order, e.g. `MYSQL_UPGRADE="optimize,analyze"`.
|
[test-openshift] |
|
[test-openshift] |
Also uses correct options for mysqladmin and mysql_upgrade
…s more self-explanatory.
|
Review was done as part of: sclorg/mariadb-container#34, this is effectively same PR, so tests passing should be good for the review. |
gabemontero
reviewed
May 23, 2018
| @@ -14,6 +14,11 @@ export_setting_variables | |||
|
|
|||
| log_volume_info $MYSQL_DATADIR | |||
|
|
|||
| # Just run normal server if the data directory is already initialized | |||
| if [ -d "${MYSQL_DATADIR}/mysql" ]; then | |||
There was a problem hiding this comment.
@hhorak - turns out this change is breaking the mysql replica tests in https://github.com/openshift/origin/blob/master/test/extended/image_ecosystem/mysql_replica.go ... we've had to comment out that test since this change dropped.
In our test, we force a restart of the slave pod by deleting the existing slave pod. On the pod restart, this directory is discovered and we run run-mysqld, without setting MYSQL_RUNNING_AS_SLAVE. As such, the process then attempts to validate various env vars in the 20-validate-variables.sh script, and the slave restart fails.
How would you propose that slave restarts work when a PV is present with this change?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A very same PR as sclorg/mariadb-container#34, so probably doesn't require a special review, let's only consult it in sclorg/mariadb-container#34.