最近在做一套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一下来看看。比较的结果如下，左边的是没有问题的，端口正常开放的，右边的是存在连接问题的。
character-set-server = utf8 character-set-server = utf8
#performance #performance
net_read_timeout = 60 net_read_timeout = 60
open_files_limit = 65535 open_files_limit = 65535
back_log = 150 back_log = 150
max_connections = 500 | max_connections = 350
max_connect_errors = 100000 max_connect_errors = 100000
external-locking = FALSE external-locking = FALSE
binlog_cache_size = 4M binlog_cache_size = 4M
performance_schema = 1 performance_schema = 1
timed_mutexes = 1 timed_mutexes = 1
#locked_in_memory = 1 #locked_in_memory = 1
#max_binlog_cache_size = 2G | thread_handling=pool-of-threads
#skip-networking | extra_port=3300
> extra_max_connections = 1
> thread_pool_max_threads = 300
这是一部分的参数对比情况，自己也是对比了一部分，但是从个别几个参数调整来重启测试，还是没有找到答案。
今天在和同事聊天的过程中，经同事提醒才发现原来是skip-networking导致的，这个参数启用，则意味着没有了网络访问，只有本机的访问连接，一种用法其实在做维护的时候，为了防止更多的客户端连接进来，就可以采用这种方式。看来自己绕了一个大圈子，最后竟然原因是一个看似简单的参数导致。简答调整之后，问题就自然修复了。
所谓吃一堑长一智，这种错误以后碰到就会更加从容。看来MySQL的参数也需要好好琢磨琢磨了，还有一大堆的坑等着我去踩：）
数据库安装很快就做好了，而且里面的很多参数也采用了一定的规则去匹配一些参数值，所以自己也没做其它的改变就直接使用了。使用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一下来看看。比较的结果如下，左边的是没有问题的，端口正常开放的，右边的是存在连接问题的。
character-set-server = utf8 character-set-server = utf8
#performance #performance
net_read_timeout = 60 net_read_timeout = 60
open_files_limit = 65535 open_files_limit = 65535
back_log = 150 back_log = 150
max_connections = 500 | max_connections = 350
max_connect_errors = 100000 max_connect_errors = 100000
external-locking = FALSE external-locking = FALSE
binlog_cache_size = 4M binlog_cache_size = 4M
performance_schema = 1 performance_schema = 1
timed_mutexes = 1 timed_mutexes = 1
#locked_in_memory = 1 #locked_in_memory = 1
#max_binlog_cache_size = 2G | thread_handling=pool-of-threads
#skip-networking | extra_port=3300
> extra_max_connections = 1
> thread_pool_max_threads = 300
这是一部分的参数对比情况，自己也是对比了一部分，但是从个别几个参数调整来重启测试，还是没有找到答案。
今天在和同事聊天的过程中，经同事提醒才发现原来是skip-networking导致的，这个参数启用，则意味着没有了网络访问，只有本机的访问连接，一种用法其实在做维护的时候，为了防止更多的客户端连接进来，就可以采用这种方式。看来自己绕了一个大圈子，最后竟然原因是一个看似简单的参数导致。简答调整之后，问题就自然修复了。
所谓吃一堑长一智，这种错误以后碰到就会更加从容。看来MySQL的参数也需要好好琢磨琢磨了，还有一大堆的坑等着我去踩：）
