一个简单的MySQL参数导致的连接问题解惑(r7笔记第33天)

最近在做一套MySQL环境的数据迁移，需要把一部分数据从一个站点迁移到另外一个站点，新站点是一套全新的环境，对于MySQL的安装采用了同事建议的 二进制方式。当然安装的过程比起Oracle的安装看起来要简单很多了。基本做到了一键安装的程度。因为对于MySQL还是有很多的盲点，所以感觉还是有 些心虚，当然态度是虚心的了。可能很多问题处理起来就不会像Oracle那样理直气壮了。这可能也是好事。 数据库安装很快就做好了，而且里面的很多参数也采用了一定的规则去匹配一些参数值，所以自己也没做其它的改变就直接使用了。使用mysqldump从源站 点导出数据在目标站点导入。看起来倒也是蛮顺利的。接着按照源站点的用户ip和目标站点的用户ip进行了映射，看似大功告成。然后对相应的客户端开通了防 火墙权限，简单本地测试连接了一下都没问题，就让开发的同事来进行联调了。 但是过了一会儿，他们反馈说连接有问题，自己还是有些心虚，感觉是不是哪里还是有问题， 他们反馈的问题是使用telnet连接端口3308不通。 比如端口是telnet 10.172.13.23 3308 Trying 10.172.13.23... telnet: connect to address 10.172.13.23: Connection refused 对于这个问题，自己也是再三查看了防火墙的设置，没有发现问题。自己也连接到他们所在的客户端去看，发现问题确实存在，但是开了ssh的22端口是没有问题的。 查看数据库中的端口参数，发现竟然是0 > show variables like '%port%'; +---------------------+-------+ | Variable_name | Value | +---------------------+-------+ | extra_port | 0 | | innodb_support_xa | ON | | large_files_support | ON | | port | 0 | | report_host | | | report_password | | | report_port | 0 | | report_user | | +---------------------+-------+ 8 rows in set (0.00 sec) 查看了一下参数文件的设置 #grep port /etc/my.cnf port = 3308 端口也没有发现问题。查看数据库的日志，发现了下面这么一段内容。 2015-11-27 18:28:32 9364 [Note] Event Scheduler: Loaded 0 events 2015-11-27 18:28:32 9364 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.6.23-72.1' socket: '/home/mysql/mysql.sock' port: 0 Percona Server (GPL), Release 72.1, Revision 0503478 从日志来看也没有提示警告或者错误。 于是带着疑问去问几个同事，他们可能认为这个问题不是一个简单的问题，我们也分析了一下参数文件的设置格式，端口，防火墙的限制等等。 我们也在怀疑是不是网络层做了什么限制，导致3308的端口无法启用，然后找到系统组的同事帮忙看看，他们直接用了nc的方式开启一个3308的端口，然后使用telnet连接就成功了，看来不是系统中网络层设置的限制，那么问题又回到了数据库层面。 但是做了多次尝试，还是无果，最后感觉是不是提供的经典模板不靠谱啊。于是从原来的环境中拷贝了一份参数文件，除了个别参数不兼容外，做了修改，总算是把库给带起来了，查看端口，这次终于对了，是3308. 但是两个参数文件的参数其实设置也还是蛮多的，自己最开始也就想跳过就算了。不过感觉这种问题处理，这次侥幸通过了，下次还是会出现。没找到根本，自己感觉也不踏实。 同事也建议我做一个strace来看看。 strace /usr/local/mysql/bin/mysqld —defaults-file=/etc/my.cnf & 但是从trace的情况来看，还是没有找到更多的有效信息。 在大晚上开始准备试一试，准备好两个参数文件，准备sdiff一下来看看。比较的结果如下，左边的是没有问题的，端口正常开放的，右边的是存在连接问题的。

这是一部分的参数对比情况，自己也是对比了一部分，但是从个别几个参数调整来重启测试，还是没有找到答案。 今天在和同事聊天的过程中，经同事提醒才发现原来是skip-networking导致的，这个参数启用，则意味着没有了网络访问，只有本机的访问连接， 一种用法其实在做维护的时候，为了防止更多的客户端连接进来，就可以采用这种方式。看来自己绕了一个大圈子，最后竟然原因是一个看似简单的参数导致。简答 调整之后，问题就自然修复了。 所谓吃一堑长一智，这种错误以后碰到就会更加从容。看来MySQL的参数也需要好好琢磨琢磨了，还有一大堆的坑等着我去踩：）