问题描述

我在让 MySQL 容器从 Docker Compose 运行一些初始化脚本(创建一些数据库)时遇到问题.根据 Docker Hub 上的文档，我将 .sql 文件安装在 /docker-entrypoint-initdb.d 中，但无济于事.

I am having issues getting my MySQL container to run some initialisation scripts (creating some databases) from Docker Compose. As per the documentation on Docker Hub, I mount the .sql files in /docker-entrypoint-initdb.d but to no avail.

我的撰写文件如下:

version: '2'

services:
  database:
    image: mysql
    ports:
      - "3307:3306"
    environment:
      MYSQL_ROOT_PASSWORD: root
    volumes:
      - ./scripts/db:/docker-entrypoint-initdb.d

  myservice:
    image: company/myservice
    expose:
      - "10001"
    depends_on:
      - database
    links:
      - database
    environment:
      SERVICE_PORT: 10001
      DATABASE_URL: jdbc:mysql://database:3306/myservice?autoReconnect=true&useSSL=false&characterEncoding=UTF-8

而./scripts/db的内容只有1个文件init-databases.sql:

And the contents of ./scripts/db is just 1 file init-databases.sql:

CREATE DATABASE myservice;

一旦启动，MySQL 正在运行，但没有创建数据库.服务容器也成功链接到 MySQL 容器.冲入 MySQL 容器；init 脚本已成功安装在正确的位置.

Once started up, MySQL is running, but the database is not created. The service container also successfully links to the MySQL container. Bashing into the MySQL container; the init scripts are successfully mounted in the correct location.

有人能在这里看到一些明显的问题吗?

Can anyone see some obvious issues here?

来自撰写的日志

database_1   | 2016-04-01T05:35:55.020279Z 0 [Note] mysqld (mysqld 5.7.11) starting as process 1 ...
database_1   | 2016-04-01T05:35:55.023277Z 0 [Note] InnoDB: PUNCH HOLE support available
database_1   | 2016-04-01T05:35:55.023305Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
database_1   | 2016-04-01T05:35:55.023316Z 0 [Note] InnoDB: Uses event mutexes
database_1   | 2016-04-01T05:35:55.023324Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
database_1   | 2016-04-01T05:35:55.023332Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.8
database_1   | 2016-04-01T05:35:55.023344Z 0 [Note] InnoDB: Using Linux native AIO
database_1   | 2016-04-01T05:35:55.023491Z 0 [Note] InnoDB: Number of pools: 1
database_1   | 2016-04-01T05:35:55.023566Z 0 [Note] InnoDB: Using CPU crc32 instructions
database_1   | 2016-04-01T05:35:55.028689Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
database_1   | 2016-04-01T05:35:55.041026Z 0 [Note] InnoDB: Completed initialization of buffer pool
database_1   | 2016-04-01T05:35:55.047324Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
database_1   | 2016-04-01T05:35:55.061537Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
database_1   | 2016-04-01T05:35:55.076895Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
database_1   | 2016-04-01T05:35:55.076987Z 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
database_1   | 2016-04-01T05:35:55.095683Z 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
database_1   | 2016-04-01T05:35:55.096484Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
database_1   | 2016-04-01T05:35:55.096540Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active.
database_1   | 2016-04-01T05:35:55.096931Z 0 [Note] InnoDB: Waiting for purge to start
database_1   | 2016-04-01T05:35:55.147986Z 0 [Note] InnoDB: 5.7.11 started; log sequence number 11992841
database_1   | 2016-04-01T05:35:55.148204Z 0 [Note] Plugin 'FEDERATED' is disabled.
database_1   | 2016-04-01T05:35:55.149262Z 0 [Note] Found ca.pem, server-cert.pem and server-key.pem in data directory. Trying to enable SSL support using them.
database_1   | 2016-04-01T05:35:55.149443Z 0 [Warning] CA certificate ca.pem is self signed.
database_1   | 2016-04-01T05:35:55.150272Z 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
database_1   | 2016-04-01T05:35:55.151068Z 0 [Note] InnoDB: Buffer pool(s) load completed at 160401  5:35:55
database_1   | 2016-04-01T05:35:55.152775Z 0 [Note] Server hostname (bind-address): '*'; port: 3306
database_1   | 2016-04-01T05:35:55.154441Z 0 [Note] IPv6 is available.
database_1   | 2016-04-01T05:35:55.154553Z 0 [Note]   - '::' resolves to '::';
database_1   | 2016-04-01T05:35:55.154571Z 0 [Note] Server socket created on IP: '::'.
database_1   | 2016-04-01T05:35:55.156680Z 0 [Warning] 'db' entry 'sys mysql.sys@localhost' ignored in --skip-name-resolve mode.
database_1   | 2016-04-01T05:35:55.156738Z 0 [Warning] 'proxies_priv' entry '@ root@localhost' ignored in --skip-name-resolve mode.
database_1   | 2016-04-01T05:35:55.158280Z 0 [Warning] 'tables_priv' entry 'sys_config mysql.sys@localhost' ignored in --skip-name-resolve mode.
database_1   | 2016-04-01T05:35:55.165273Z 0 [Note] Event Scheduler: Loaded 0 events
database_1   | 2016-04-01T05:35:55.173462Z 0 [Note] mysqld: ready for connections.
database_1   | Version: '5.7.11'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server (GPL)

推荐答案

检查这是否是 docker-compose 问题(例如 issue 115 重定向到 issue 2266)

Check if this is a docker-compose issue (like issue 115 which redirected to issue 2266)

我认为错误与构建无关，很可能与体积有关.
Compose 会保留卷，这样您就不会丢失数据(这将在下一个版本中更好地记录).

I don't think the error is related to build, it's mostly likely volumes.
Compose preserves volumes so that you don't lose data (this will be better documented in the next release).

要删除这些卷，请运行 docker-compose rm -vf.下次您 docker-compose up 时，它应该从新的空卷开始.

To remove those volumes run docker-compose rm -vf. The next time you docker-compose up it should start with fresh empty volumes.

根据hub.docker.com/mysql，还要检查这是否不是同步问题:

According to hub.docker.com/mysql, check also if this is not a synchronization issue:

如果容器启动时没有初始化数据库，那么会创建一个默认的数据库.虽然这是预期的行为，但这意味着它不会接受传入连接，直到此类初始化完成.这可能会导致使用自动化工具(例如 docker-compose 同时启动多个容器)时出现问题.

If there is no database initialized when the container starts, then a default database will be created. While this is the expected behavior, this means that it will not accept incoming connections until such initialization completes. This may cause issues when using automation tools, such as docker-compose, which start several containers simultaneously.

这篇关于MySQL 容器无法在 Docker Compose 中运行初始化脚本的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！