【问题标题】:docker and mysql: Got an error reading communication packetsdocker和mysql:读取通信包时出错
【发布时间】:2018-08-03 17:28:28
【问题描述】:

我在 docker 中的连接有问题。我使用官方 mysql 5.7 映像和Prisma 服务器。当我通过 prisma cli 启动它时,它在下面使用docker compose(描述为here)一切正常。

但我需要通过 docker api 以编程方式启动此容器,在这种情况下,来自应用的连接会使用 [Note] Aborted connection 8 to db: 'unconnected' user: 'root' host: '164.20.10.2' (Got an error reading communication packets) 删除。

那我做什么:

  1. 创建桥接网络:

    const network = await docker.network.create({
    Name: manifest.name + '_network',
    IPAM: {
      "Driver": "default",
      "Config": [
        {
          "Subnet": "164.20.0.0/16",
          "IPRange": "164.20.10.0/24"
        }
      ]
    }});
    
  2. 创建 mysql 容器并将其连接到网络

    const mysql = await docker.container.create({
    Image: 'mysql:5.7',
    Hostname: manifest.name + '-mysql',
    Names: ['/' + manifest.name + '-mysql'],
    NetworkingConfig: {
      EndpointsConfig: {
        [manifest.name + '_network']: {
          Aliases: [manifest.name + '-mysql']
        }
      }
    },
    Restart: 'always',
    Args: [
      "mysqld",
      "--max-connections=1000",
      "--sql-mode=ALLOW_INVALID_DATES,ANSI_QUOTES,ERROR_FOR_DIVISION_BY_ZERO,HIGH_NOT_PRECEDENCE,IGNORE_SPACE,NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,NO_BACKSLASH_ESCAPES,NO_DIR_IN_CREATE,NO_ENGINE_SUBSTITUTION,NO_FIELD_OPTIONS,NO_KEY_OPTIONS,NO_TABLE_OPTIONS,NO_UNSIGNED_SUBTRACTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY,PIPES_AS_CONCAT,REAL_AS_FLOAT,STRICT_ALL_TABLES,STRICT_TRANS_TABLES,ANSI,DB2,MAXDB,MSSQL,MYSQL323,MYSQL40,ORACLE,POSTGRESQL,TRADITIONAL"
    ],
    Env: [
      'MYSQL_ROOT_PASSWORD=secret'
    ]
    });
    
    await network.connect({
       Container: mysql.id
    });
    await mysql.start();
    
  3. 然后我等待 Mysql 启动,从 prismagraphql/prisma:1.1 创建所需的数据库和所需的 Prisma 容器并启动它们。应用服务器正确解析 mysql 主机,但连接被 mysql 断开。

3306端口从app容器到mysql容器的Telnet响应正确:

J
5.7.21U;uH  Kem']#45T]2mysql_native_password

我做错了什么?

【问题讨论】:

  • 你试过增加max_allowed_packet吗?

标签: mysql docker docker-api prisma prisma-graphql


【解决方案1】:

检查以下内容:

  • max_allowed_pa​​ckets
  • wait_timeout
  • net_read_timeout

在问题期间还监控 MySQL 进程列表以识别超时。

【讨论】:

    【解决方案2】:

    您可以尝试一下吗,应用程序可能会在准备好接受连接之前尝试连接到 mysql 服务器。要对此进行测试,请在启动时添加一些等待或运行 mysql,然后运行应用程序作为不同的部署。

    【讨论】:

      【解决方案3】:

      解决方法是将--wait-timeout=28800(或更高的数字)添加到 MySQL 参数中:

      Args: [
        "mysqld",
        "--max-connections=1000",
        "--sql-mode=ALLOW_INVALID_DATES,ANSI_QUOTES,ERROR_FOR_DIVISION_BY_ZERO,HIGH_NOT_PRECEDENCE,IGNORE_SPACE,NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,NO_BACKSLASH_ESCAPES,NO_DIR_IN_CREATE,NO_ENGINE_SUBSTITUTION,NO_FIELD_OPTIONS,NO_KEY_OPTIONS,NO_TABLE_OPTIONS,NO_UNSIGNED_SUBTRACTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY,PIPES_AS_CONCAT,REAL_AS_FLOAT,STRICT_ALL_TABLES,STRICT_TRANS_TABLES,ANSI,DB2,MAXDB,MSSQL,MYSQL323,MYSQL40,ORACLE,POSTGRESQL,TRADITIONAL",
        "--wait-timeout=28800" // 28800 sec = 8 hours
      ],
      

      参考:https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_wait_timeout

      但找出空闲连接的根本原因可能更明智。

      【讨论】:

        猜你喜欢
        • 2011-06-26
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2022-10-05
        • 1970-01-01
        • 1970-01-01
        • 2020-06-03
        • 2019-09-17
        相关资源
        最近更新 更多