## 背景 用戶在使用mysqldump導數據上云的時候碰到兩個“詭異”的問題，簡單分析分享下。 ## TIP 1 --port端口無效? 本地有3306和3307兩個端口的實例，執行命令為: ~~~ mysqldump --host=localhost --port=300x -Ddb1 db1 -r outputfile ~~~ 發現無論執行端口寫入3306還是3307，導出的都是3306端口實例的數據。 ## 代碼分析 實際上不論是mysqldump還是mysql客戶端，在連接數據庫時都調用了?`CLI_MYSQL_REAL_CONNECT`?這個函數，里面的一段代碼邏輯如下 ~~~ if(!host || !strcmp(host,LOCAL_HOST) { vio_socket_connect(... } 其中 #define LOCAL_HOST "localhost" ~~~ 也就是說，當host參數值為localhost的時候，mysql和mysqldump客戶端使用的是–socket參數，如果未指定，則使用默認的/tmp/mysql.sock。 因此上面用戶的輸入，不論–port 輸入多少，都被忽略。而他的/tmp/mysql.sock 就是屬于3306端口實例。 從代碼中可以看到，必須是全小寫的localhost才滿足條件，若是Localhost，則解析成127.0.0.1，用的是 ip + port 的模式，此時 –socket 參數無效。 ## TIP 2 導出的數據無法導入？ 使用mysqldump默認參數導出5.6 的數據，無法導入到目標庫。 當源庫使用了GTID模式時，在dump出來的文件中為了保持目標庫和源庫GTID值相同，增加了兩個語句,?`SET @@SESSION.SQL_LOG_BIN= 0`?和?`SET @@GLOBAL.GTID_PURGED='xxxx'`。 而實際上增加這兩個語句會有諸多問題： 1. 關閉binlog首先需要super權限，如果目標庫只能使用普通賬號，則會導致執行失敗； 2. 即使有super權限，也會導致這些操作不記錄到binlog，會導致主備不一致。當然也可以說，這就要求同一份dump要restore到目標庫的主庫和所有備庫才能保持主備一致； 3. `SET @@GLOBAL.GTID_PURGED='xxxx'`這個命令要求目標庫的`gtid_executed`值是空。若非空，這個命令執行失敗； 4. reset master可以清空`gtid_executed`值，也需要super權限。 因此在導出5.6的數據時，有兩種可選方案： 1. 在有目標庫的super權限時，用默認dump參數，在導入到目標庫之前，先執行reset master；這樣需要在主庫和所有備庫都執行相同個導入動作； 2. mysqldump需要增加參數 –set-gtid-purged=off，這樣不會生成上述兩個語句，數據能夠直接導入。但是目標庫的gtid set就與源庫不同。 需要根據業務需求選擇。