linux Can't connect to local MySQL server through socket '/opt/lampp/var/m...
问题背景这个项目是某省教育考试院的门禁管理系统，采用PHP+MySQL技术栈开发，服务部署在Linux系统上，保密级别特别高，远程连接需要使用内部工具连接到堡垒机，再从堡垒机远程服务器。负责这个项目的开发人员已全部离职，PHP部门解散，当初的开发公司只留下一份最早的部署文档。而我作为接手这个项目的项目经理，并不懂PHP语言开发。问题现象首先是网站页面打不开，报错信息：
Unable to connect to your database server using the provided settings.
这个问题是很好解决的，按照提示，找到报错的文件和行：
root@menjin:/data/wwwroot/face360/system/core# vim Loader.php
找到数据库配置文件
vim /application/config/database.php
修改：
$db['default']['pconnect'] = TRUE;$db['default']['db_debug'] = TRUE;
修改后:
$db['default']['pconnect'] = FALSE;$db['default']['db_debug'] = FALSE;
此时可以打开网站了，但是无法登录，提示帐号密码错误，但可以肯定帐号密码是对的。于是怀疑是数据库出了问题没有正常启动，马上用xshell 和xftp工具连接linux服务器看下，启动xampp mysql，命令：
/opt/lampp/lampp startmysql
/opt/lampp/bin/mysql.server: line 260: kill: (11145) - No such process
执行mysql start命令mysql start //进入bin目录，执行mysql start命令，提示错误：
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/opt/lampp/var/mysql/mysql.sock' (2 "No such file or directory")
xampp程序以及配置文件都没有任何改动，前几天，网站还正常运行，今天就莫名其妙的显示mysql无法正常连接。初步判断不是程序的问题。
所以第一步开始去排查服务器的系统盘占用情况
df -l –执行命令，查看系统盘空间占用情况
结果发现：系统盘被占用了100%在根目录执行命令，看下具体子目录占用大小情况：
du -s -h ./*
经过一层一层排查，知道了是Tomcat日志文件过大导致的。具体过大文件在：/usr/java/tomcat/apache-tomcat-8.5.30/logs 路径下面。先关闭Tomcat进程，然后删除日志文件。因为被进程占用的话，即使删除了日志文件，以后会显示系统盘被占用100%再次执行命令df -l 或者 df -lh
经过上面的步骤，继续启动xmapp mysql发现，依然没用，怎么回事?这次要拿出杀手锏来了，分析mysql启动日志启动日志路径在：
/opt/lampp/var/mysql
利用Notepad ++打开改文件，或者利用linux自带的vim打开。日志文件：
2018-12-24 10:50:50 10085 mysqld_safe Starting mysqld daemon with databases from /opt/lampp/var/mysql
2018-12-24 10:50:50 140491172915008 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.
2018-12-24 10:50:50 140491172915008 [Note] Using unique option prefix 'key_buffer' is error-prone and can break in the future. Please use the full name 'key_buffer_size' instead.
2018-12-24 10:50:50 140491172915008 [Note] /opt/lampp/sbin/mysqld (mysqld 10.1.37-MariaDB) starting as process 10231 ...
2018-12-24 10:50:51 140491172915008 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2018-12-24 10:50:51 140491172915008 [Note] InnoDB: The InnoDB memory heap is disabled
2018-12-24 10:50:51 140491172915008 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2018-12-24 10:50:51 140491172915008 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2018-12-24 10:50:51 140491172915008 [Note] InnoDB: Compressed tables use zlib 1.2.11
2018-12-24 10:50:51 140491172915008 [Note] InnoDB: Using SSE crc32 instructions
2018-12-24 10:50:51 140491172915008 [Note] InnoDB: Initializing buffer pool, size = 16.0M
2018-12-24 10:50:51 140491172915008 [Note] InnoDB: Completed initialization of buffer pool
2018-12-24 10:50:51 140491172915008 [Note] InnoDB: Highest supported file format is Barracuda.
2018-12-24 10:50:51 140491172915008 [Note] InnoDB: 128 rollback segment(s) are active.
2018-12-24 10:50:51 140491172915008 [Note] InnoDB: Waiting for purge to start
2018-12-24 10:50:51 140491172915008 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.41-84.1 started; log sequence number 17666815
2018-12-24 10:50:51 140491172915008 [Note] Plugin 'FEEDBACK' is disabled.
2018-12-24 10:50:51 140491172915008 [Note] Recovering after a crash using tc.log
2018-12-24 10:50:51 140491172915008 [ERROR] Can't init tc log
2018-12-24 10:50:51 140491172915008 [ERROR] Aborting
2018-12-24 10:50:53 10085 mysqld_safe mysqld from pid file /opt/lampp/var/mysql/izuf655vwf6dndsynw1j3mz.pid ended
问题关键出来了： Can’t init tc log在目录下/opt/lampp/var/mysql 找到 这个文件，删除即可!然后重启xammp mysql 启动正常/opt/lampp/lampp startmysql总结1）清除linux服务器上的无用的日志文件，这里主要是tomcat日志文件产生的，因为我的服务器同时部署了xampp以及tomcat2）分析mysql错误日志文件，然后针对性的对错误进行解决。但是问题的根本原因是因为系统盘被tomcat日志文件占用导致，所以部署tomcat程序的时候，要特别注意限制日志文件的输入，控制其大小，否则会导致系统盘被占满，网站不可用。
