Overview

OpenShift Origin provides a container image for running MySQL. This image can provide database services based on username, password, and database name settings provided via configuration.

Versions

Currently, OpenShift Origin provides versions 5.5, 5.6, and 5.7 of MySQL.

Images

This image comes in two flavors, depending on your needs:

  • RHEL 7

  • CentOS 7

RHEL 7 Based Images

The RHEL 7 image is available through the Red Hat Registry:

$ docker pull registry.access.redhat.com/openshift3/mysql-55-rhel7
$ docker pull registry.access.redhat.com/rhscl/mysql-56-rhel7
$ docker pull registry.access.redhat.com/rhscl/mysql-57-rhel7

CentOS 7 Based Images

CentOS images for MySQL 5.5 and 5.6 are available on Docker Hub:

$ docker pull openshift/mysql-55-centos7
$ docker pull openshift/mysql-56-centos7

To use these images, you can either access them directly from these registries or push them into your OpenShift Origin Docker registry. Additionally, you can create an ImageStream that points to the image, either in your Docker registry or at the external location. Your OpenShift Origin resources can then reference the ImageStream. You can find example ImageStream definitions for all the provided OpenShift Origin images.

Configuration and Usage

Initializing the Database

The first time you use the shared volume, the database is created along with the database administrator user and the MySQL root user (if you specify the MYSQL_ROOT_PASSWORD environment variable). Afterwards, the MySQL daemon starts up. If you are re-attaching the volume to another container, then the database, database user, and the administrator user are not created, and the MySQL daemon starts.

The following command creates a new database pod with MySQL running in a container:

$ oc new-app \
    -e MYSQL_USER=<username> \
    -e MYSQL_PASSWORD=<password> \
    -e MYSQL_DATABASE=<database_name> \
    openshift/mysql-55-centos7

Running MySQL Commands in Containers

OpenShift Origin uses Software Collections (SCLs) to install and launch MySQL. If you want to execute a MySQL command inside of a running container (for debugging), you must invoke it using bash.

To do so, first identify the name of the pod. For example, you can view the list of pods in your current project:

$ oc get pods

Then, open a remote shell session to the pod:

$ oc rsh <pod>

When you enter the container, the required SCL is automatically enabled.

You can now run the mysql command from the bash shell to start a MySQL interactive session and perform normal MySQL operations. For example, to authenticate as the database user:

bash-4.2$ mysql -u $MYSQL_USER -p$MYSQL_PASSWORD -h $HOSTNAME $MYSQL_DATABASE
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 4
Server version: 5.5.37 MySQL Community Server (GPL)
...
mysql>

When you are finished, enter quit or exit to leave the MySQL session.

Environment Variables

The MySQL user name, password, and database name must be configured with the following environment variables:

Table 1. MySQL Environment Variables
Variable Name Description

MYSQL_USER

Specifies the user name for the database user that is created for use by your application.

MYSQL_PASSWORD

Password for the MYSQL_USER.

MYSQL_DATABASE

Name of the database to which MYSQL_USER has full rights.

MYSQL_ROOT_PASSWORD

Optional password for the root user. If this is not set, then remote login to the root account is not possible. Local connections from within the container are always permitted without a password.

MYSQL_SERVICE_HOST

Service host variable automatically created by Kubernetes.

MYSQL_SERVICE_PORT

Service port variable automatically created by Kubernetes.

You must specify the user name, password, and database name. If you do not specify all three, the pod will fail to start and OpenShift Origin will continuously try to restart it.

MySQL settings can be configured with the following environment variables:

Table 2. Additional MySQL Settings
Variable Name Description Default

MYSQL_LOWER_CASE_TABLE_NAMES

Sets how the table names are stored and compared.

0

MYSQL_MAX_CONNECTIONS

The maximum permitted number of simultaneous client connections.

151

MYSQL_MAX_ALLOWED_PACKET

The maximum size of one packet or any generated/intermediate string.

200M

MYSQL_FT_MIN_WORD_LEN

The minimum length of the word to be included in a FULLTEXT index.

4

MYSQL_FT_MAX_WORD_LEN

The maximum length of the word to be included in a FULLTEXT index.

20

MYSQL_AIO

Controls the innodb_use_native_aio setting value if the native AIO is broken.

1

MYSQL_TABLE_OPEN_CACHE

The number of open tables for all threads.

400

MYSQL_KEY_BUFFER_SIZE

The size of the buffer used for index blocks.

32M (or 10% of available memory)

MYSQL_SORT_BUFFER_SIZE

The size of the buffer used for sorting.

256K

MYSQL_READ_BUFFER_SIZE

The size of the buffer used for a sequential scan.

8M (or 5% of available memory)

MYSQL_INNODB_BUFFER_POOL_SIZE

The size of the buffer pool where InnoDB caches table and index data.

32M (or 50% of available memory)

MYSQL_INNODB_LOG_FILE_SIZE

The size of each log file in a log group.

8M (or 15% of available memory)

MYSQL_INNODB_LOG_BUFFER_SIZE

The size of the buffer that InnoDB uses to write to the log files on disk.

8M (or 15% of available memory)

Some of the memory-related parameters have two default values. The fixed value is used when a container does not have memory limits assigned. The other value is calculated dynamically during a container’s startup based on available memory.

Volume Mount Points

The MySQL image can be run with mounted volumes to enable persistent storage for the database:

  • /var/lib/mysql/data - This is the data directory where MySQL stores database files.

Changing Passwords

Passwords are part of the image configuration, therefore the only supported method to change passwords for the database user (MYSQL_USER) and root user is by changing the environment variables MYSQL_PASSWORD and MYSQL_ROOT_PASSWORD, respectively.

You can view the current passwords by viewing the pod or deployment configuration in the web console or by listing the environment variables with the CLI:

$ oc set env pod <pod_name> --list

Whenever MYSQL_ROOT_PASSWORD is set, it enables remote access for the root user with the given password, and whenever it is unset, remote access for the root user is disabled. This does not affect the regular user MYSQL_USER, who always has remote access. This also does not affect local access by the root user, who can always log in without a password in localhost.

Changing database passwords through SQL statements or any way other than through the environment variables aforementioned causes a mismatch between the values stored in the variables and the actual passwords. Whenever a database container starts, it resets the passwords to the values stored in the environment variables.

To change these passwords, update one or both of the desired environment variables for the related deployment configuration(s) using the oc set env command. If multiple deployment configurations utilize these environment variables, for example in the case of an application created from a template, you must update the variables on each deployment configuration so that the passwords are in sync everywhere. This can be done all in the same command:

$ oc set env dc <dc_name> [<dc_name_2> ...] \
  MYSQL_PASSWORD=<new_password> \
  MYSQL_ROOT_PASSWORD=<new_root_password>

Depending on your application, there may be other environment variables for passwords in other parts of the application that should also be updated to match. For example, there could be a more generic DATABASE_USER variable in a front-end pod that should match the database user’s password. Ensure that passwords are in sync for all required environment variables per your application, otherwise your pods may fail to redeploy when triggered.

Updating the environment variables triggers the redeployment of the database server if you have a configuration change trigger. Otherwise, you must manually start a new deployment in order to apply the password changes.

To verify that new passwords are in effect, first open a remote shell session to the running MySQL pod:

$ oc rsh <pod>

From the bash shell, verify the database user’s new password:

bash-4.2$ mysql -u $MYSQL_USER -p<new_password> -h $HOSTNAME $MYSQL_DATABASE -te "SELECT * FROM (SELECT database()) db CROSS JOIN (SELECT user()) u"

If the password was changed correctly, you should see a table like this:

+------------+---------------------+
| database() | user()              |
+------------+---------------------+
| sampledb   | user0PG@172.17.42.1 |
+------------+---------------------+

To verify the root user’s new password:

bash-4.2$ mysql -u root -p<new_root_password> -h $HOSTNAME $MYSQL_DATABASE -te "SELECT * FROM (SELECT database()) db CROSS JOIN (SELECT user()) u"

If the password was changed correctly, you should see a table like this:

+------------+------------------+
| database() | user()           |
+------------+------------------+
| sampledb   | root@172.17.42.1 |
+------------+------------------+

Creating a Database Service from a Template

OpenShift Origin provides a template to make creating a new database service easy. The template provides parameter fields to define all the mandatory environment variables (user, password, database name, etc) with predefined defaults including auto-generation of password values. It will also define both a deployment configuration and a service.

The MySQL templates should have been registered in the default openshift project by your cluster administrator during the initial cluster setup. See Loading the Default Image Streams and Templates for more details, if required.

There are two templates available:

  • mysql-ephemeral is for development or testing purposes only because it uses ephemeral storage for the database content. This means that if the database pod is restarted for any reason, such as the pod being moved to another node or the deployment configuration being updated and triggering a redeploy, all data will be lost.

  • mysql-persistent uses a persistent volume store for the database data which means the data will survive a pod restart. Using persistent volumes requires a persistent volume pool be defined in the OpenShift Origin deployment. Cluster administrator instructions for setting up the pool are located here.

You can find instructions for instantiating templates by following these instructions.

Once you have instantiated the service, you can copy the user name, password, and database name environment variables into a deployment configuration for another component that intends to access the database. That component can then access the database via the service that was defined.

Using MySQL Replication

Replication support provided by the MySQL image is experimental and should not be used in production.

endif::openshift-enterprise[[]