是否存在mySQL連接時間限制？

我在Ubuntu 14.04服務器上使用Net-SNMP來捕獲snmptrapd中的SNMP陷阱，我已經設置了它（使用/ etc/snmp目錄中的「perl do'/path/to/traphandler.pl'」） snmptrapd.conf）調用Perl :: DBI腳本將數據插入到mySQL數據庫中。自3月16日以來，一切運行良好，然後在昨天上午9點左右（4月6日 - 銀行假期 - 典型）數據庫更新停止，但系統日誌顯示陷阱仍在進入。是否存在mySQL連接時間限制？

我看不到任何明顯在/ var/log中，所以我想知道數據庫連接是否過期並關閉。這是否發生？我停了下來，重新啓動了snmptrapd，這一切都再次開始工作，這讓我認爲這是原因。我將如何檢查？

來源

2015-04-07 kbro

是的，它是28800秒

connect_timeout=28800 
wait_timeout=28800 
interactive_timeout=28800

如果你想改變它，那麼你就無法運行此查詢，您可以在/etc/my.cnf

設定值：

SET GLOBAL interactive_timeout = 100; //Change it if you want 
SET GLOBAL wait_timeout = 100;

來源

2015-04-07 09:48:52

貌似WAIT_TIMEOUT那樣的損傷。 28800秒= 8小時，週日復活節/銀行假日週一，SNMP陷阱守護程序停止接收陷阱，因此數據庫連接超時。在此之前，它似乎從來沒有陷入陷阱信息8小時中斷。 – kbro

如果服務需要數據庫連接，最好的辦法是檢查主循環，或者在每個查詢之前檢查連接是否仍然可用。

如果連接不再可用或者它不再工作，可以正確關閉並重新連接。

這樣，即使數據庫服務器暫時不可用，deamon也會繼續工作。例如，即使數據庫服務器重新啓動，該服務也將繼續工作。

來源

2015-04-07 09:56:38

合理的建議。我會將檢查/重新連接代碼添加到我的陷阱處理程序。我沒有將您標記爲「已接受」的答案的唯一原因是您尚未直接回答是否有超時問題。 – kbro

不完全是你的問題的答案，但你可以處理丟失的數據庫連接，而不會在每次查詢之前改變超時或檢查連接。

如果訪問MySQL數據庫與DBI可以設置標誌mysql_auto_reconnect（見DBD::mysql）

此屬性確定是否DBD :: MySQL將自動重新連接到MySQL，如果連接丟失。此功能默認爲關閉; [..] 如果使用'lock tables'，則不建議將mysql_auto_reconnect設置爲on，因爲如果DBD :: mysql重新連接到mysql，則所有表鎖都將丟失。

實施例：

my $dbh = DBI->connect(
    $host, 
    $user, 
    $password, 
    {  
     mysql_auto_reconnect => 1            
    }  
) or die("DB connect failed: : $DBI::errstr");

來源

2015-04-07 11:16:46 dennis

整潔！這將節省我不得不放在代碼檢測一滴，所以我可以重新連接:-) – kbro

是否存在mySQL連接時間限制？

回答

相關問題