现象
今天在验证DM主备集群故障测试时,reboot重启后发现数据库相关进程并没有自启。
分析
数据库进程没有自启可能会有两种原因:
1.没有设置开机自启
2.自启后报错,导致没有启动成功
查看是否开启开机自启
systemctl list-unit-files | grep Dm
已注册数据库开机自启服务
查看相关日志
与liunx开机自启相关的日志有:
/var/log/boot.log #一般包含系统启动时的日志,包括自启动的服务。
/var/log/message #包括整体系统信息,其中也包含系统启动期间的日志。此外,mail,cron,daemon,kern和auth等内容也记录在var/log/messages日志中。
数据库服务日志:
/home/dmdba/dmdbms/log/dm_DMSERVER_202011.log #DM 数据库系统在运行过程中,会在 log 子目录下产生一个“dm_实例名_日期” 命名的事件日志文件。
数据库日志
在日志中可以看到2020-11-02 10:21:15.752数据库服务成功关闭,然后进行reboot,结果开机没有自启。在2020-11-02 10:42:44.827时启动,这个是我手动进行启动,并非开机启动
2020-11-02 10:42:52.934手动启动成功了。查看数据库日志后发现,数据库服务并没有进行自启,排除自启失败的原因
操作系统日志
- boot.log
根据日志可以看到,启动时调用开机自启服务了,但是并没有启动成功,结合数据库数据库日志,自启服务并没有实际去调用数据库服务进行启动,那么只能查看message查找更详细的原因。
2.message
结合数据库日志,Nov 2 10:22:19 调用数据库服务进行启动
接着往下找,发现DmServiceDM.service: Failed to execute command: Permission denied,那么是否有可能是权限原因呢?
权限没有问题,都是dmdba:dinstall。
为了确保不是权限导致启动失败我对数据库安装目录下的所有文件修改权限
chown -R dmdba:dinstall /opt/dmdb
重新进行启动发现还是无法做到开机自启。
SELinux
既然文件权限没有问题,数据库启动没有没有,那么必然是操作系统层做了限制,导致Permission denied,查询到有这样一个安全策略会限制进程资源的使用,那就是SELinux,由于SELinux对资源的限制导致无法进行读写,因此无法开机自启。关于SELinux我就不做讲解了,有兴趣的同学可以查看SELinux讲解
关闭SELinux
关闭SELinx的方法非常简单,将/etc/selinux/config文件中SELINUX由enforcing改为disabled
对SELinux的修改需要重启生效。再次reboot,数据库进程启动成功。
更多资讯请上达梦技术社区了解: https://eco.dameng.com