このページは機械翻訳したものです。
次のほとんどのサンプルコマンドでは、(docker pull コマンドや docker run コマンドなどを使用して) 指定する必要がある場合、mysql/mysql-server
が Docker イメージリポジトリとして使用されます。イメージが別のリポジトリからのものである場合は、次のように変更
My Oracle Support からダウンロードされた mysql/enterprise-server
for MySQL Enterprise Edition イメージ。
Docker 用に最適化された MySQL インストール
MySQL 用の Docker イメージはコードサイズ用に最適化されています。つまり、Docker コンテナで MySQL インスタンスを実行する大部分のユーザーに関連することが予想される重要なコンポーネントのみが含まれています。 MySQL Docker のインストールは、次の点で共通の non-Docker のインストールとは異なります:
-
含まれるバイナリは、次のものに制限されます:
/usr/bin/my_print_defaults
/usr/bin/mysql
/usr/bin/mysql_config
/usr/bin/mysql_install_db
/usr/bin/mysql_tzinfo_to_sql
/usr/bin/mysql_upgrade
/usr/bin/mysqladmin
/usr/bin/mysqlcheck
/usr/bin/mysqldump
/usr/bin/mysqlpump
/usr/bin/mysqlbackup
( MySQL Enterprise Edition 8.0 の場合のみ)/usr/sbin/mysqld
すべてのバイナリが削除され、デバッグ情報は含まれません。
MySQL Server の構成
MySQL Docker コンテナを起動するときに、docker run コマンドを使用して構成オプションをサーバーに渡すことができます。 例:
docker run --name mysql1 -d mysql/mysql-server:tag --character-set-server=utf8mb4 --collation-server=utf8mb4_col
このコマンドは、utf8mb4
をデフォルトの文字セットとして、utf8mb4_col
をデータベースのデフォルトの照合順序として使用して、MySQL Server を起動します。
MySQL Server を構成する別の方法は、構成ファイルを準備し、コンテナ内のサーバー構成ファイルの場所にマウントすることです。 詳細は、データおよび構成の変更の永続化 を参照してください。
データおよび構成の変更の永続化
Docker コンテナは原則的に一時的なものであり、コンテナが削除または破損した場合、データまたは構成は失われることが予想されます (ディスカッション「ここ」を参照)。 ただし、「Docker ボリューム」には、Docker コンテナ内で作成されたデータを永続化するメカニズムが用意されています。 初期化時に、MySQL Server コンテナはサーバーデータディレクトリの Docker ボリュームを作成します。 コンテナで docker inspect コマンドを実行するための JSON 出力には Mount
キーがあり、その値によってデータディレクトリボリュームに関する情報が提供されます:
shell> docker inspect mysql1
...
"Mounts": [
{
"Type": "volume",
"Name": "4f2d463cfc4bdd4baebcb098c97d7da3337195ed2c6572bc0b89f7e845d27652",
"Source": "/var/lib/docker/volumes/4f2d463cfc4bdd4baebcb098c97d7da3337195ed2c6572bc0b89f7e845d27652/_data",
"Destination": "/var/lib/mysql",
"Driver": "local",
"Mode": "",
"RW": true,
"Propagation": ""
}
],
...
出力には、データがホストに永続化されるソースフォルダ/var/lib/docker/volumes/4f2d463cfc4bdd4baebcb098c97d7da3337195ed2c6572bc0b89f7e845d27652/_data
が、コンテナ内のサーバーデータディレクトリである/var/lib/mysql
にマウントされていることが示されています。
データを保持する別の方法は、コンテナの作成時に --mount
オプションを使用してホストディレクトリを bind-mount に保存することです。 同じ方法を使用して、サーバーの構成を永続化できます。 次のコマンドは、MySQL Server コンテナを作成し、データディレクトリとサーバー構成ファイルの両方をバインドマウントします:
docker run --name=mysql1 \
--mount type=bind,src=/path-on-host-machine/my.cnf,dst=/etc/my.cnf \
--mount type=bind,src=/path-on-host-machine/datadir,dst=/var/lib/mysql \
-d mysql/mysql-server:tag
このコマンドは、
をpath-on-host-machine/my.cnf
(コンテナ内のサーバー構成ファイル) にマウントし、/etc/my.cnf
をpath-on-host-machine/datadir
(コンテナ内のデータディレクトリ) にマウントします。 バインドマウントが機能するには、次の条件を満たす必要があります:
/var/lib/mysql
-
構成ファイル
がすでに存在し、ユーザーpath-on-host-machine/my.cnf
mysql
を使用してサーバーを起動するための仕様が含まれている必要があります:[mysqld] user=mysql
ファイルに他のサーバー構成オプションを含めることもできます。
データディレクトリ
がすでに存在している必要があります。 サーバーの初期化を実行するには、ディレクトリが空である必要があります。 データが事前移入されたディレクトリをマウントしてサーバーを起動することもできますが、データを作成したサーバーと同じ構成で Docker コンテナを起動する必要があり、コンテナの起動時に必要なホストファイルまたはディレクトリがマウントされていることを確認する必要があります。path-on-host-machine/datadir
追加の初期化スクリプトの実行
作成直後にデータベースで実行する .sh
または .sql
スクリプトがある場合は、それらをホストディレクトリに配置してから、そのディレクトリをコンテナ内の/docker-entrypoint-initdb.d/
にマウントできます。 例:
docker run --name=mysql1 \
--mount type=bind,src=/path-on-host-machine/scripts/,dst=/docker-entrypoint-initdb.d/ \
-d mysql/mysql-server:tag
別の Docker コンテナ内のアプリケーションから MySQL への接続
Docker ネットワークを設定すると、別の Docker コンテナ内のクライアントアプリケーションがサーバーコンテナ内の MySQL Server にアクセスできるように、複数の Docker コンテナが相互に通信できるようになります。 まず、Docker ネットワークを作成します:
docker network create my-custom-net
次に、サーバーおよびクライアントコンテナを作成して起動するときに、--network
オプションを使用して、作成したネットワークに配置します。 例:
docker run --name=mysql1 --network=my-custom-net -d mysql/mysql-server
docker run --name=myapp1 --network=my-custom-net -d myapp
その後、Docker は指定されたコンテナ名に対して DNS を自動的に設定するため、myapp1
コンテナは mysql1
ホスト名を使用して mysql1
コンテナに接続できます (逆も同様です)。 次の例では、myapp1
コンテナ内から mysq
l クライアントを実行して、独自のコンテナ内のホスト mysql1
に接続します:
docker exec -it myapp1 mysql --host=mysql1 --user=myuser --password
コンテナのその他のネットワーク技術については、Docker ドキュメントの「Docker コンテナネットワーキング」のセクションを参照してください。
サーバーエラーログ
サーバーコンテナを使用して MySQL Server を初めて起動したときに、次のいずれかの条件に該当する場合、server error log は生成されません:
ホストからのサーバー構成ファイルがマウントされていますが、ファイルにシステム変数
log_error
が含まれていません (サーバー構成ファイルのバインドおよびマウントに関する データおよび構成の変更の永続化 を参照)。ホストからのサーバー構成ファイルはマウントされていませんが、Docker 環境変数
MYSQL_LOG_CONSOLE
はtrue
(MySQL 8.0 サーバーコンテナの変数のデフォルト状態) です。 その後、MySQL Server エラーログはstderr
にリダイレクトされるため、エラーログは Docker コンテナログに記録され、docker logsmysqld-container
コマンドを使用して表示できます。
いずれかの条件に該当する場合に MySQL Server でエラーログを生成するには、configure the server の --log-error
オプションを使用して、コンテナ内の特定の場所にエラーログを生成します。 エラーログを永続化するには、データおよび構成の変更の永続化 の説明に従って、コンテナ内のエラーログの場所にホストファイルをマウントします。 ただし、コンテナ内の MySQL Server に、マウントされたホストファイルへの書込みアクセス権があることを確認する必要があります。
Docker での MySQL Enterprise Backup の使用
MySQL Enterprise Backup は、MySQL Enterprise Edition で使用可能な MySQL Server の商用ライセンスバックアップユーティリティです。MySQL Enterprise Backup は MySQL Enterprise Edition の Docker インストールに含まれています。
次の例では、Docker コンテナで MySQL Server がすでに実行されていることを前提としています (Docker で MySQL Server インスタンスを起動する方法については、セクション2.5.6.1「Docker を使用した MySQL Server デプロイメントの基本ステップ」 を参照してください)。 MySQL Enterprise Backup で MySQL Server をバックアップするには、サーバーデータディレクトリにアクセスできる必要があります。 これは、たとえば、サーバーの起動時に bind-mounting a host directory on the data directory of the MySQL Server によって実現できます:
docker run --name=mysqlserver \
--mount type=bind,src=/path-on-host-machine/datadir/,dst=/var/lib/mysql \
-d mysql/enterprise-server:8.0
このコマンドを使用すると、MySQL Server は MySQL Enterprise Edition の Docker イメージで起動され、ホストディレクトリ/path-on-host-machine/datadir/
はサーバーコンテナ内のサーバーデータディレクトリ (/var/lib/mysql
) にマウントされます。 また、サーバーの起動後、MySQL Enterprise Backup がサーバーにアクセスするために必要な権限も設定されていることを前提としています (詳細は、Grant MySQL Privileges to Backup Administrator を参照)。 次のステップを使用して、MySQL Server インスタンスをバックアップおよびリストアします。
Docker とともに MySQL Enterprise Backup を使用して、Docker コンテナで実行されている MySQL Server インスタンスをバックアップするには:
-
MySQL Server コンテナが実行されているのと同じホストで、MySQL Enterprise Edition のイメージを使用して別のコンテナを起動し、MySQL Enterprise Backup コマンド
backup-to-image
を使用してバックアップを実行します。 最後のステップで作成したバインドマウントを使用して、サーバーデータディレクトリへのアクセスを提供します。 また、ホストディレクトリ (この例では/path-on-host-machine/backups/
) をコンテナ内のバックアップの記憶域フォルダ (この例では/data/backups
) にマウントして、作成中のバックアップを永続化します。 次に、My Oracle Support からダウンロードした Docker イメージを使用して MySQL Enterprise Backup を起動する、このステップのサンプルコマンドを示します:shell> docker run \ --mount type=bind,src=/path-on-host-machine/datadir/,dst=/var/lib/mysql \ --mount type=bind,src=/path-on-host-machine/backups/,dst=/data/backups \ --rm mysql/enterprise-server:8.0 \ mysqlbackup -umysqlbackup -ppassword --backup-dir=/tmp/backup-tmp --with-timestamp \ --backup-image=/data/backups/db.mbi backup-to-image [Entrypoint] MySQL Docker Image 8.0.11-1.1.5 MySQL Enterprise Backup version 8.0.11 Linux-4.1.12-61.1.16.el7uek.x86_64-x86_64 [2018-04-08 07:06:45] Copyright (c) 2003, 2018, Oracle and/or its affiliates. All Rights Reserved. 180921 17:27:25 MAIN INFO: A thread created with Id '140594390935680' 180921 17:27:25 MAIN INFO: Starting with following command line ... ... ------------------------------------------------------------- Parameters Summary ------------------------------------------------------------- Start LSN : 29615616 End LSN : 29651854 ------------------------------------------------------------- mysqlbackup completed OK!
mysqlbackup による出力の終わりをチェックして、バックアップが正常に完了していることを確認することが重要です。
-
バックアップジョブが終了するとコンテナは終了し、開始に使用した
--rm
オプションを使用すると、コンテナは終了後に削除されます。 イメージバックアップが作成され、バックアップを格納する最後のステップでマウントされたホストディレクトリにあります:shell> ls /tmp/backups db.mbi
MySQL Enterprise Backup と Docker を使用して Docker コンテナ内の MySQL Server インスタンスをリストアするには:
-
MySQL Server コンテナを停止します。これにより、内部で実行されている MySQL Server も停止されます:
docker stop mysqlserver
-
ホストで、MySQL Server データディレクトリの bind マウント内のすべての内容を削除します:
rm -rf /path-on-host-machine/datadir/*
-
MySQL Enterprise Edition のイメージを使用してコンテナを起動し、MySQL Enterprise Backup コマンド
copy-back-and-apply-log
を使用してリストアを実行します。 サーバーをバックアップしたときと同様に、バックアップのサーバーデータディレクトリとストレージフォルダをバインド/マウントします:shell> docker run \ --mount type=bind,src=/path-on-host-machine/datadir/,dst=/var/lib/mysql \ --mount type=bind,src=/path-on-host-machine/backups/,dst=/data/backups \ --rm mysql/enterprise-server:8.0 \ mysqlbackup --backup-dir=/tmp/backup-tmp --with-timestamp \ --datadir=/var/lib/mysql --backup-image=/data/backups/db.mbi copy-back-and-apply-log [Entrypoint] MySQL Docker Image 8.0.11-1.1.5 MySQL Enterprise Backup version 8.0.11 Linux-4.1.12-61.1.16.el7uek.x86_64-x86_64 [2018-04-08 07:06:45] Copyright (c) 2003, 2018, Oracle and/or its affiliates. All Rights Reserved. 180921 22:06:52 MAIN INFO: A thread created with Id '139768047519872' 180921 22:06:52 MAIN INFO: Starting with following command line ... ... 180921 22:06:52 PCR1 INFO: We were able to parse ibbackup_logfile up to lsn 29680612. 180921 22:06:52 PCR1 INFO: Last MySQL binlog file position 0 155, file name binlog.000003 180921 22:06:52 PCR1 INFO: The first data file is '/var/lib/mysql/ibdata1' and the new created log files are at '/var/lib/mysql' 180921 22:06:52 MAIN INFO: No Keyring file to process. 180921 22:06:52 MAIN INFO: Apply-log operation completed successfully. 180921 22:06:52 MAIN INFO: Full Backup has been restored successfully. mysqlbackup completed OK! with 3 warnings
バックアップジョブが終了するとコンテナは終了し、開始時に
--rm
オプションを使用すると、コンテナは終了後に削除されます。 -
サーバーコンテナを再起動します。これにより、リストアされたサーバーも再起動されます:
docker restart mysqlserver
または、リストアされたデータディレクトリで新しい MySQL Server を起動します:
docker run --name=mysqlserver2 \ --mount type=bind,src=/path-on-host-machine/datadir/,dst=/var/lib/mysql \ -d mysql/enterprise-server:8.0
サーバーにログオンして、リストアされたデータでサーバーが実行されていることを確認します。
既知の問題
サーバーシステム変数
audit_log_file
を使用して監査ログファイル名を構成する場合、それとともにloose
option modifier を使用すると、Docker はサーバーを起動できません。
Docker の環境変数
MySQL Server コンテナを作成する場合、--env
オプション (-e
) を使用して、次の環境変数のいずれかまたは複数を指定することで、MySQL インスタンスを構成できます。
サーバーの初期化が試行されないため、マウントするデータディレクトリが空でない場合、次の変数は何の効果もありません (詳細は データおよび構成の変更の永続化 を参照)。 フォルダ内の既存のコンテンツ (古いサーバー設定を含む) は、コンテナの起動時に変更されません。
MYSQL_RANDOM_ROOT_PASSWORD
、MYSQL_ONETIME_PASSWORD
、MYSQL_ALLOW_EMPTY_PASSWORD
、MYSQL_LOG_CONSOLE
などのブール変数は、長さがゼロ以外の文字列で設定することによって true になります。 したがって、「0」、「false」 または no などに設定しても、false にはなりませんが、実際には true になります。 これは、MySQL Server コンテナの既知の問題です。
MYSQL_RANDOM_ROOT_PASSWORD
: この変数が true (MYSQL_ROOT_PASSWORD
が設定されているか、MYSQL_ALLOW_EMPTY_PASSWORD
が true に設定されていないかぎり、デフォルトの状態) の場合、Docker コンテナの起動時にサーバールートユーザーのランダムパスワードが生成されます。 パスワードはコンテナのstdout
に出力され、コンテナのログを参照して確認できます (MySQL Server インスタンスの起動 を参照)。MYSQL_ONETIME_PASSWORD
: 変数が true (MYSQL_ROOT_PASSWORD
が設定されているか、MYSQL_ALLOW_EMPTY_PASSWORD
が true に設定されていないかぎり、デフォルトの状態) の場合、root ユーザーのパスワードは期限切れとして設定され、MySQL を通常どおり使用する前に変更する必要があります。MYSQL_DATABASE
: この変数を使用すると、イメージの起動時に作成するデータベースの名前を指定できます。MYSQL_USER
およびMYSQL_PASSWORD
でユーザー名とパスワードが指定されている場合、ユーザーが作成され、このデータベース (GRANT ALL
に対応) へのスーパーユーザーアクセス権が付与されます。 指定されたデータベースは CREATE DATABASE IF NOT EXIST ステートメントによって作成されるため、データベースがすでに存在する場合、変数は無効です。-
MYSQL_USER
,MYSQL_PASSWORD
: これらの変数は、ユーザーを作成してそのユーザーパスワードを設定するために組み合せて使用され、ユーザーにはMYSQL_DATABASE
変数で指定されたデータベースに対するスーパーユーザー権限が付与されます。 ユーザーを作成するには、MYSQL_USER
とMYSQL_PASSWORD
の両方が必要です。2 つの変数のいずれかが設定されていない場合、もう一方は無視されます。 両方の変数が設定されているが、MYSQL_DATABASE
が設定されていない場合、ユーザーは権限なしで作成されます。注記このメカニズムを使用してルートスーパーユーザーを作成する必要はありません。このスーパーユーザーは、
MYSQL_ALLOW_EMPTY_PASSWORD
が true でないかぎり、MYSQL_ROOT_PASSWORD
およびMYSQL_RANDOM_ROOT_PASSWORD
の説明で説明されているメカニズムのいずれかによってデフォルトでパスワードが設定されて作成されます。 MYSQL_ROOT_HOST
: デフォルトでは、MySQL によって'root'@'localhost'
アカウントが作成されます。 このアカウントは、コンテナ内から MySQL Server への接続 で説明されているように、コンテナ内からのみ接続できます。 他のホストからのルート接続を許可するには、この環境変数を設定します。 たとえば、デフォルトの Docker ゲートウェイ IP である値172.17.0.1
では、コンテナを実行するホストマシンからの接続が許可されます。 このオプションで使用できるエントリは 1 つのみですが、ワイルドカード (MYSQL_ROOT_HOST=172.*.*.*
やMYSQL_ROOT_HOST=%
など) を使用できます。-
MYSQL_LOG_CONSOLE
: 変数が true (MySQL 8.0 サーバーコンテナのデフォルト状態) の場合、MySQL Server エラーログはstderr
にリダイレクトされるため、エラーログは Docker コンテナログに記録され、docker logsmysqld-container
コマンドを使用して表示できます。注記ホストのサーバー構成ファイルがマウントされている場合、変数は無効です (構成ファイルのバインド時の データおよび構成の変更の永続化 を参照)。
-
MYSQL_ROOT_PASSWORD
: この変数は、MySQL root アカウントに設定されるパスワードを指定します。警告コマンドラインでの MySQL root ユーザーパスワードの設定はセキュアではありません。 パスワードを明示的に指定するかわりに、パスワードファイルのコンテナファイルパスを使用して変数を設定し、コンテナファイルパスにパスワードを含むホストからファイルをマウントすることもできます。 パスワードファイルの場所がまだ公開されているため、これはそれでも安全ではありません。
MYSQL_RANDOM_ROOT_PASSWORD
とMYSQL_ONETIME_PASSWORD
の両方のデフォルト設定を true にすることをお薦めします。 -
MYSQL_ALLOW_EMPTY_PASSWORD
。 root ユーザーのパスワードを空白にしてコンテナを起動できるようにするには、true に設定します。警告この変数を true に設定すると、MySQL インスタンスを完全に保護せずに完全なスーパーユーザーアクセスを取得できるため、セキュアではありません。
MYSQL_RANDOM_ROOT_PASSWORD
とMYSQL_ONETIME_PASSWORD
の両方のデフォルト設定を true にすることをお薦めします。