存档

2018年7月 的存档

触发器报错The user specified as a definer root@ip does not exist

2018年7月27日 没有评论

如果你的某个表加了触发器TRIGGER,有可能莫名其妙的出现错误提示:
The user specified as a definer root@ip does not exist
这个问题可能是这样的,比如你有A服务器,A服务器的mysql用户中有用户名为root且host地址为:
localhost+127.0.0.1+%+固定ip(比如192.168.1.110),4个用户
你用远程连接连接了mysql,比如本地的ip是192.168.1.110,当你用192.168.1.110连接mysql的时候,创建的触发器TRIGGER(从上面4个用户中固定ip的优先级最高,所以这个时候使用的是root@192.168.1.110)
这个时候,创建触发器之后,会在information_schema库中的TRIGGERS表中DEFINER字段,增加相应记录;
值为:root@192.168.1.110
如果后来你把A服务器的root@192.168.1.110用户删除了,就会提示这个错误。

再比如,你是用其他ip链接mysql,则使用的是root@%这个用户链接,则值为:root@%
同样,你如果删除了root@%,也会出现错误

所以,我建议在创建触发器的时候,直接登录A服务器,用命令行创建触发器,这个时候,就会是:root@localhost
因为我们肯定要保证mysql用户中至少有root@localhost和root@127.0.0.1存在
这样后期添加其他或者删除其他用户,都不会影响触发器的执行,也不会报这个错误了。

另外提醒:登录服务器用命令行创建触发器,默认的时候用英文的分号(;)结束会报错,所以可以类似:

DELIMITER $
触发器语句
END$

这样完整的触发器语句才会被正确的执行,否则会报错
当然如果你用远程连接比如navicat连接,可以不用上面的语句,但是后期可能又会出现刚才的错误提示。
所以还是登陆服务器用命令行创建吧。

比如:

DELIMITER $

CREATE TRIGGER `copy` AFTER INSERT ON `infos` FOR EACH ROW BEGIN

INSERT INTO binfos SELECT * FROM infos WHERE id= NEW.id;

IF NEW.isyp=1 THEN
INSERT INTO cinfos SELECT * FROM infos WHERE id=NEW.id;
END IF;

END$

DELIMITER $
CREATE TRIGGER `update` AFTER UPDATE ON `infos` FOR EACH ROW BEGIN

IF NEW.isyp=1 THEN
DELETE FROM cinfos WHERE id=NEW.id;
INSERT INTO cinfos SELECT * FROM infos WHERE id=NEW.id;
END IF;

IF NEW.isyp=0 THEN
DELETE FROM cinfos Where id=NEW.id;
END IF;

END$

DELIMITER $
CREATE TRIGGER `delete` AFTER DELETE ON `infos` FOR EACH ROW BEGIN

IF OLD.isyp=1 THEN
DELETE FROM cinfos WHERE id=OLD.id;
END IF;

END$

php-fpm模式下间歇性无法获取不到$_SERVER或者$_REQUEST数据

2018年7月3日 没有评论

最近安装了一台新的服务器,nginx+php-fpm模式

使用过程中发现$_SERVER或者$_REQUEST(不排除$_POST或者$_GET)间歇性无法获取数据

但是只要重启php-fpm服务就可以解决,但是运行一段时间之后又会反复出现

由此分析应该为php-fpm问题(重启可以解决,个人推测为php-fpm进程问题),一开始以为是当前版本php的bug,后来降低php版本后依然存在,找了很多google资料,都没有遇到类似问题。

花了2天左右时间,对服务器软件配置文件参数逐一排查调试,都没有找到问题所在。

最后,只能从拓展插件上着手,暂时锁定了问题所在:

xcache拓展和opcache拓展建议只开启一个,似乎discuz里面用的是xcache,所以建议只安装xcache
在php-fpm模式下,如果同时安装xcache和opcache,会导致莫名其妙的$_SERVER或者$_REQUEST无法获取数据(间歇性)

所以个人推测:2个都用的话(双层cache)会导致php-fpm的部分进程假死,前段请求发送到假死的进程上后,则无法返回数据,当发送到没假死的进程就可以返回数据(当重启php-fpm服务又正常了)

关闭opcache拓展后,目前运行了近1.5天,已经没有发现此问题。

css.php