docker和mysql：读取通信包时出错

Posted 2023-03-08

【中文标题】docker和mysql：读取通信包时出错

【英文标题】：docker and mysql: Got an error reading communication packets

【发布时间】：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) 删除。

那我做什么：

创建桥接网络：

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"
    
  ]
);

创建 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();

然后我等待 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吗？

【参考方案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

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