一個簡單的MySQL引數導致的連線問題解惑

最近在做一套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的引數也需要好好琢磨琢磨了，還有一大堆的坑等著我去踩：）