关于数据库:故障分析-一个因-SSL-配置导致的复制异常报错

在构建 MySQL 复制过程中，IO 线程始终连贯不上主库，重复确认复制账号的权限、账号密码都没问题，最终定位为 SSL 配置的问题。

作者：木板。某全国性股份制银行 DBA。善于 DB2，MySQL 和 Oracle 数据库的运行保护和调优、排错。

本文起源：原创投稿

• 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。

故障背景

在做 MySQL 同构的数据迁徙过程中，咱们通常只须要按流程搭建主从保持数据同步即可。个别构建复制只有网络没问题，根本都能顺利构建胜利。而这次踩了一个小坑，记录一下。

共事反馈做完 change master 后，IO 线程始终显示连贯不上主库，曾经重复确认该复制账号的权限、账号密码都没问题，且也验证了通过 MySQL 客户端的命令行输出雷同的账号密码能失常连贯到主库，曾经做了以下场景的排除工作：

• 排除了账号密码谬误的问题
• 排除了账号权限有余的问题
• 排除了网络不通的问题

故障剖析

• 通过源端主库的谬误日志也能继续观测到该复制用户频繁的尝试连贯但都失败, 谬误日志的报错仅告知用了明码但拜访受限，比拟惯例的报错信息。

2021-06-07T16:56:54.812721+08:00 121 [ERROR] [MY-010584] [Repl] Slave I/O for channel '': error connecting to master'repl@10.186.61.27:3310'- retry-time: 60 retries: 1 message: Access denied for user'repl'@'10.186.61.27' (using password: YES), Error_code: MY-001045

2021-06-07T16:57:54.817711+08:00 121 [ERROR] [MY-010584] [Repl] Slave I/O for channel '': error connecting to master'repl@10.186.61.27:3310'- retry-time: 60 retries: 2 message: Access denied for user'repl'@'10.186.61.27' (using password: YES), Error_code: MY-001045

通过 mysql.user 表观测复制用户的权限细节，观测到该用户有一个非凡的属性设置，ssl_type=ANY 该设置引起了留神。基于官网文档得悉，该选项是用来管制用户是否开启 SSL 形式登录。如果为 ANY 则示意用该用户连贯时，必须应用 SSL 形式，否则无奈登录。

MySQL 客户端在 5.7 当前默认就开启 SSL，所以失常状况下无需明确指定即是 SSL 形式。

 10.186.61.27:3310  SQL > select user,host,ssl_type from mysql.user;
+------------------+-----------+----------+
| user             | host      | ssl_type |
+------------------+-----------+----------+
| repl             | %         | ANY      |
| root             | %         |          |
| zhenxing         | %         |          |
| sysbench         | 10.186.%  |          |
| mysql.infoschema | localhost |          |
| mysql.session    | localhost |          |
| mysql.sys        | localhost |          |
| root             | localhost |          |
+------------------+-----------+----------+


CHANGE MASTER TO
  MASTER_HOST='10.186.61.27',
  MASTER_USER='repl',
  MASTER_PASSWORD='xxxx',
  MASTER_PORT=3310,
  MASTER_AUTO_POSITION=1;
  
Last_IO_Errno: 1045
Last_IO_Error: error connecting to master 'repl@10.186.61.27:3310' - retry-time: 60 retries: 1 message: Access denied for user 'repl'@'10.186.61.27' (using password: YES)

问题复现

尝试复现验证是否为该属性导致，在用 MySQL 登录数据库时明确的敞开 SSL 尝试 mysql --ssl-mode=disable，后果如预期的一样，报错无奈连贯，但并没有报错是因为 SSL 的起因。

[root@10-186-61-27 ~]# mysql -h10.186.61.27 -urepl -p -P3310
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 29
Server version: 8.0.22-commercial MySQL Enterprise Server - Commercial
Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
repl@10.186.61.27[(none)]>


-- --ssl-mode=disable
[root@10-186-61-27 ~]# mysql -h10.186.61.27 -urepl -p -P3310 --ssl-mode=disable
ERROR 1045 (28000): Access denied for user 'repl'@'10.186.61.27' (using password: YES)

问题总结

1. 默认状况下，复制构建是不应用 SSL 的，除非明确的指定 SSL 相干的参数。具体配置形式可参考官网文档。

2. 用户连贯异样的状况，不仅波及权限、明码等问题，对于用户的连贯管制属性也须要进行观测，如 mysql.user 表的以下字段：

   • ssl_type
   • max_questions
   • max_updates
   • max_connections
   • max_user_connections
   • plugin
   • password_expired
   • password_lifetime
   • account_locked

3. 1045 ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) 常见报错场景：

   • 用户名不正确
   • 数据库用户受到连贯主机限度，以后主机不容许连贯

   • 明码谬误

     • 明码填写谬误
     • 当明码呈现在 Shell 脚本中，并且蕴含特殊字符如 $，#，! 等时
     • 当明码呈现在配置文件中，并且蕴含特殊字符 # 时，须要用双引号将明码括起来
   • 开启了 SSL 连贯属性
   • DNS 服务器解析主机名异样
   • 指定的数据库 IP 谬误
   • 应用了内部的认证形式，（如 AD、PAM、LDAP 等），但配置不正确

解决办法

1. 敞开该用户强制须要 SSL 连贯的属性

   alter user xxx REQUIRE NONE;

2. change master 操作时，明确指定 MASTER_SSL 等 SSL 参数配置

CHANGE MASTER TO
  MASTER_HOST='10.186.61.27',
  MASTER_USER='repl',
  MASTER_PASSWORD='xxxx',
  MASTER_PORT=3310,
  MASTER_AUTO_POSITION=1,
  MASTER_SSL=1;

对于 SQLE

爱可生开源社区的 SQLE 是一款面向数据库使用者和管理者，反对多场景审核，反对标准化上线流程，原生反对 MySQL 审核且数据库类型可扩大的 SQL 审核工具。

SQLE 获取