$ docker pull registry.access.redhat.com/openshift3/mysql-55-rhel7
×
MySQL
Overview
OpenShift provides a Docker image for running MySQL. This image can provide database services based on username, password, and database name settings provided via configuration.
Versions
Currently, OpenShift provides version 5.5 of MySQL.
Images
This image comes in two flavors, depending on your needs:
-
RHEL 7
-
CentOS 7
RHEL 7 Based Image
The RHEL 7 image is available through Red Hat’s subscription registry via:
CentOS 7 Based Image
This image is available on DockerHub. To download it:
$ docker pull openshift/mysql-55-centos7
To use these images, you can either access them directly from these registries or push them into your OpenShift 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 resources can then reference the ImageStream. You can find example ImageStream definitions for all the provided OpenShift 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>,MYSQL_PASSWORD=<password>,MYSQL_DATABASE=<database_name> \
registry.access.redhat.com/openshift3/mysql-55-rhel7
Running MySQL Commands in Containers
OpenShift 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:
| Variable Name | Description |
|---|---|
|
Specifies the user name for the database user that is created for use by your application. |
|
Password for the |
|
Name of the database to which |
|
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. |
|
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 will continuously try to restart it. |
MySQL settings can be configured with the following environment variables:
| Variable Name | Description | Default |
|---|---|---|
|
Sets how the table names are stored and compared. |
0 |
|
The maximum permitted number of simultaneous client connections. |
151 |
|
The minimum length of the word to be included in a FULLTEXT index. |
4 |
|
The maximum length of the word to be included in a FULLTEXT index. |
20 |
|
Controls the innodb_use_native_aio setting value if the native AIO is broken. |
1 |
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 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 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 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 |
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 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 First Steps setup process. There are two templates available:
-
mysql-ephemeralis 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-persistentuses 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 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
|
Enabling clustering for database images is currently in Technology Preview and not intended for production use. |
Red Hat provides a proof-of-concept template for MySQL master-slave replication (clustering); you can obtain the example template from GitHub.
To upload the example template into the current project’s template library:
$ oc create -f \
https://raw.githubusercontent.com/openshift/mysql/master/5.5/examples/replica/mysql_replica.json
The following sections detail the objects defined in the example template and describe how they work together to start a cluster of MySQL servers implementing master-slave replication. This is the recommended replication strategy for MySQL.
Creating the Deployment Configuration for the MySQL master
To set up MySQL replication, a deployment configuration is defined in the example template that defines a replication controller. For MySQL master-slave replication, two deployment configurations are needed. One deployment configuration defines the MySQL master server and second the MySQL slave servers.
To tell a MySQL server to act as the master, the command field in the
container’s definition in the deployment configuration must be set to
run-mysqld-master. This script acts as an alternative entrypoint for the
MySQL image and configures the MySQL server to run as the master in replication.
MySQL replication requires a special user that relays data between the master and slaves. The following environment variables are defined in the template for this purpose:
| Variable Name | Description | Default |
|---|---|---|
|
The user name of the replication user |
master |
|
The password for the replication user |
generated |
Example 1. MySQL master Deployment Configuration Object Definition in the Example Template
{
"kind":"DeploymentConfig",
"apiVersion":"v1",
"metadata":{
"name":"mysql-master"
},
"spec":{
"strategy":{
"type":"Recreate"
},
"triggers":[
{
"type":"ConfigChange"
}
],
"replicas":1,
"selector":{
"name":"mysql-master"
},
"template":{
"metadata":{
"labels":{
"name":"mysql-master"
}
},
"spec":{
"volumes":[
{
"name":"mysql-master-data",
"persistentVolumeClaim":{
"claimName":"mysql-master"
}
}
],
"containers":[
{
"name":"server",
"image":"openshift/mysql-55-centos7",
"command":[
"run-mysqld-master"
],
"ports":[
{
"containerPort":3306,
"protocol":"TCP"
}
],
"env":[
{
"name":"MYSQL_master_USER",
"value":"${MYSQL_master_USER}"
},
{
"name":"MYSQL_master_PASSWORD",
"value":"${MYSQL_master_PASSWORD}"
},
{
"name":"MYSQL_USER",
"value":"${MYSQL_USER}"
},
{
"name":"MYSQL_PASSWORD",
"value":"${MYSQL_PASSWORD}"
},
{
"name":"MYSQL_DATABASE",
"value":"${MYSQL_DATABASE}"
},
{
"name":"MYSQL_ROOT_PASSWORD",
"value":"${MYSQL_ROOT_PASSWORD}"
}
],
"volumeMounts":[
{
"name":"mysql-master-data",
"mountPath":"/var/lib/mysql/data"
}
],
"resources":{
},
"terminationMessagePath":"/dev/termination-log",
"imagePullPolicy":"IfNotPresent",
"securityContext":{
"capabilities":{
},
"privileged":false
}
}
],
"restartPolicy":"Always",
"dnsPolicy":"ClusterFirst"
}
}
}
}Since we claimed a persistent volume in this deployment configuration to have all data persisted for the MySQL master server, you must ask your cluster administrator to create a persistent volume that you can claim the storage from.
After the deployment configuration is created and the pod with MySQL master
server is started, it will create the database defined by MYSQL_DATABASE and
configure the server to replicate this database to slaves.
The example provided defines only one replica of the MySQL master server. This causes OpenShift to start only one instance of the server. Multiple instances (multi-master) is not supported and therefore you can not scale this replication controller.
To replicate the database created by the
MySQL master, a
deployment configuration is defined in the template. This deployment
configuration creates a replication controller that launches the MySQL image
with the command field set to run-mysqld-slave. This alternative
entrypoints skips the initialization of the database and configures the MySQL
server to connect to the mysql-master service, which is also defined in
example template.
Example 2. MySQL Slave Deployment Configuration Object Definition in the Example Template
{
"kind":"DeploymentConfig",
"apiVersion":"v1",
"metadata":{
"name":"mysql-slave"
},
"spec":{
"strategy":{
"type":"Recreate"
},
"triggers":[
{
"type":"ConfigChange"
}
],
"replicas":1,
"selector":{
"name":"mysql-slave"
},
"template":{
"metadata":{
"labels":{
"name":"mysql-slave"
}
},
"spec":{
"containers":[
{
"name":"server",
"image":"openshift/mysql-55-centos7",
"command":[
"run-mysqld-slave"
],
"ports":[
{
"containerPort":3306,
"protocol":"TCP"
}
],
"env":[
{
"name":"MYSQL_master_USER",
"value":"${MYSQL_master_USER}"
},
{
"name":"MYSQL_master_PASSWORD",
"value":"${MYSQL_master_PASSWORD}"
},
{
"name":"MYSQL_DATABASE",
"value":"${MYSQL_DATABASE}"
}
],
"resources":{
},
"terminationMessagePath":"/dev/termination-log",
"imagePullPolicy":"IfNotPresent",
"securityContext":{
"capabilities":{
},
"privileged":false
}
}
],
"restartPolicy":"Always",
"dnsPolicy":"ClusterFirst"
}
}
}
}This example deployment configuration starts the replication controller with the initial number of replicas set to 1. You can scale this replication controller in both directions, up to the resources capacity of your account.
Creating a Headless Service
The pods created by the MySQL slave replication controller must reach the MySQL master server in order to register for replication. The example template defines a headless service named mysql-master for this purpose. This service is not used only for replication, but the clients can also send the queries to mysql-master:3306 as the MySQL host.
To have a headless service, the portalIP parameter in the service definition
is set to None. Then you can use a DNS query to get a list of the pod IP
addresses that represents the current endpoints for this service.
Example 3. Headless Service Object Definition in the Example Template
{
"kind":"Service",
"apiVersion":"v1",
"metadata":{
"name":"mysql-master",
"labels":{
"name":"mysql-master"
}
},
"spec":{
"ports":[
{
"protocol":"TCP",
"port":3306,
"targetPort":3306,
"nodePort":0
}
],
"selector":{
"name":"mysql-master"
},
"portalIP":"None",
"type":"ClusterIP",
"sessionAffinity":"None"
},
"status":{
"loadBalancer":{
}
}
}Scaling the MySQL Slaves
To increase the number of members in the cluster:
$ oc scale rc mysql-slave-1 --replicas=<number>
This tells the replication controller to create a new MySQL slave pod. When a new slave is created, the slave entrypoint first attempts to contact the mysql-master service and register itself to the replication set. Once that is done, the MySQL master server sends the slave the replicated database.
When scaling down, the MySQL slave is shut down and, because the slave does not have any persistent storage defined, all data on the slave is lost. The MySQL master server then discovers that the slave is not reachable anymore, and it automatically removes it from the replication.