我在Ubuntu 14.04服务器上使用Net-SNMP捕获snmptrapd中的SNMP陷阱,我已经设置了这个陷阱(使用" perl do' / path / to / traphandler .pl'"在/etc/snmp/snmptrapd.conf中)调用Perl :: DBI脚本将数据插入mySQL数据库。自3月16日以来一直运行良好,然后昨天上午9点(4月6日 - 银行假日 - 典型)数据库更新停止,尽管系统日志显示陷阱仍在进入。
我在/ var / log中看不到任何明显的东西,所以我想知道数据库连接是否只是过期和关闭。那会发生吗?我停下来重新启动了snmptrapd,这一切都重新开始了,这让我觉得这就是原因。我该怎么检查?
答案 0 :(得分:4)
是的,它是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;
答案 1 :(得分:3)
如果服务需要数据库连接,最好是检查主循环或每次查询之前是否仍然可用。
如果连接不再可用或者它不再起作用,您可以正确关闭它并重新连接。
这样,即使数据库服务器暂时不可用,deamon仍会继续工作。例如,即使数据库服务器重新启动,该服务仍将继续工作。
答案 2 :(得分:3)
不完全是您问题的答案,但您可以在不更改超时或在每次查询之前检查连接的情况下处理丢失的数据库连接。
如果您使用DBI访问MySQL数据库,则可以设置标记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");