Mysql에는 오류 로그, 일반 쿼리 로그, 바이너리 로그, 느린 쿼리 로그의 4가지 로그 유형이 있습니다**
1. 오류 로그
는 Mysql 작업 중 오류를 기록합니다. 기타 정보, 시스템 오류나 특정 기록에 문제가 있는 경우 오류 로그를 확인할 수 있습니다.
-
Mysql 오류 로그는 기본적으로 MySQL 로그 디렉터리에 호스트 이름.err로 저장됩니다.
mysql> show variables like "log_error";
+---------------+----------------+
| Variable_name | Value |
+---------------+----------------+
| log_error | /tmp/mysql.log |
+---------------+---------------
로그인 후 복사
오류 로그 수정 mysql 오류 로그를 활성화하려면 /etc/my.cnf에 --log-error = [filename]을 추가할 수 있습니다. 내 것은:
log_error = /tmp/mysql.log
로그인 후 복사
먼저 확인해 보자: tail -f /tmp/mysql.log
bash-3.2# tail -f /tmp/mysql.log
2015-12-23T02:22:41.467311Z 0 [Note] IPv6 is available.
2015-12-23T02:22:41.467324Z 0 [Note] - '::' resolves to '::';
2015-12-23T02:22:41.467350Z 0 [Note] Server socket created on IP: '::'.
2015-12-23T02:22:41.584287Z 0 [Note] Event Scheduler: Loaded 0 events
2015-12-23T02:22:41.584390Z 0 [Note] /usr/local/Cellar/mysql/5.7.9/bin/mysqld: ready for connections.
Version: '5.7.9' socket: '/tmp/mysql.sock' port: 3306 Homebrew
2015-12-23T02:22:42.540786Z 0 [Note] InnoDB: Buffer pool(s) load completed at 151223 10:22:42
151223 10:22:51 mysqld_safe A mysqld process already exists
2015-12-23T02:25:30.984395Z 2 [ERROR] Could not use /tmp/mysql_query.log for logging (error 13 - Permission denied). Turning logging off for the server process. To turn it on again: fix the cause, then either restart the query logging by using "SET GLOBAL GENERAL_LOG=ON" or restart the MySQL server.
2015-12-23T07:28:03.923562Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 61473ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)
로그인 후 복사
정보의 양이 상대적으로 많다 대형, 일시적으로 더 이상 분석이 없습니다. . . . 물론, mysql 구성이나 연결에 오류가 있는 경우에도 tail -f를 통해 로그를 추적할 수 있습니다
2. 일반 쿼리 로그
를 포함한 mysql의 일일 로그를 기록합니다. 쿼리, 수정, 업데이트 등 각 SQL.
먼저 mysql에 쿼리 로그가 활성화되어 있는지 확인하세요. "%genera%"와 같은 전역 변수 표시
mysql> show global variables like "%genera%";
+----------------------------------------+----------------------+
| Variable_name | Value |
+----------------------------------------+----------------------+
| auto_generate_certs | ON |
| general_log | OFF |
| general_log_file | /tmp/mysql_query.log |
| sha256_password_auto_generate_rsa_keys | ON |
+----------------------------------------+----------------------+
4 rows in set (0.00 sec)
로그인 후 복사
여기서 로그 출력을 구성했습니다. 파일 : /tmp/mysql_query.log, 로그 기능이 꺼진 상태
쿼리 로그 출력 파일은 /etc/my.cnf에 추가 가능 general -log-file = [filename]
Mysql이 일반 로그를 연 후, 일반 로그 파일을 열면 모든 쿼리문이 출력될 수 있다. , 파일이 매우 큽니다. 디버깅 중에 켜고 정상적으로 끄는 것이 좋습니다
mysql> set global general_log = on;
Query OK, 0 rows affected (0.01 sec)
mysql> set global general_log = off;
Query OK, 0 rows affected (0.01 sec)
로그인 후 복사
참고:
로그 기능이 켜져 있지만 로그가 기록되지 않으면 mysql에 로그 파일에 대한 권한이 충분하지 않을 수 있으므로 내 로그 파일은 /tmp/mysql_query.log에 지정해야 합니다.
chown mysql:mysql /tmp/mysql_query.log
로그인 후 복사
3. 바이너리 로그
바이너리 로그에는 테이블 생성, 데이터 변경 등 데이터베이스 변경을 설명하는 일부 이벤트가 포함됩니다. 주로 백업에 사용되며, 복구, 롤백 작업 등
1. 기능:
2. 형식
Binlog에는 3가지 형식이 있습니다
- STATMENT: 데이터를 수정하는 모든 sql은 마스터의 binlog에 기록되며 슬레이브가 복사할 때 sql 프로세스가 복사되어 구문 분석됩니다. 마스터 측의 원래 실행과 동일한 SQL로 변환한 다음 실행됩니다.
약간: 명령문 모드에서는 행 모드의 단점이 먼저 해결됩니다. 각 데이터 행의 변경 사항을 기록할 필요가 없으므로 binlog 로그의 양이 줄어들고 I/O 및 스토리지 리소스가 절약됩니다. 성능을 향상시킵니다. 마스터에서 실행된 문의 세부 사항과 해당 문이 실행될 때 컨텍스트 정보만 자극하면 되기 때문입니다.
단점: 명령문 모드에서는 기록된 실행 명령문이므로 이러한 명령문이 슬레이브 측에서 올바르게 실행되기 위해서는 각 명령문이 실행될 때 일부 관련 정보도 기록해야 하며 이는 컨텍스트 정보입니다. 슬레이브 측에서 실행될 때 모든 명령문이 마스터 측에서 실행될 때와 동일한 결과를 얻을 수 있는지 확인하십시오. 또한, 현재 mysql은 빠르게 발전하고 있기 때문에 많은 새로운 기능이 지속적으로 추가되고 있으며 이로 인해 mysql 복제에는 많은 어려움이 따릅니다. 당연히 복제에 관련된 내용이 복잡할수록 버그가 나타나기 쉽습니다. 성명서에서는 주로 데이터를 수정할 때 특정 기능이나 기능을 사용할 때 MySQL 복제에 문제가 발생하는 것으로 나타났습니다. 예를 들어 일부 버전에서는 sleep() 기능을 사용할 수 없습니다. last_insert_id() 함수가 저장 프로시저에서 사용되어 슬레이브와 마스터 등의 ID가 일치하지 않을 수 있습니다.
- ROW: 로그는 데이터의 각 행의 수정된 형태를 기록한 후 슬레이브 측에서 동일한 데이터를 수정합니다. 수정되는 데이터만 기록됩니다. 값이 아닌 값입니다. 여러 SQL 테이블이 연결되는 상황이 있습니다.
장점: 행 모드에서 bin-log는 실행된 sql 문의 컨텍스트 관련 정보를 기록할 필요가 없으며 어떤 레코드가 수정되었는지, 수정 내용은 무엇인지만 기록하면 되므로 행 로그 내용이 기록됩니다. be 데이터 수정의 각 행에 대한 세부 사항이 매우 명확하게 기록되어 이해하기 매우 쉽습니다. 또한 특정 상황에서 저장 프로시저와 함수, 트리거 호출 및 트리거가 올바르게 복사되지 않는 문제도 없습니다.
단점: 행 모드에서는 실행된 모든 명령문이 로그에 기록될 때 각 행 레코드의 수정 사항으로 기록되므로 많은 양의 로그 내용이 생성될 수 있습니다.
MIXED：MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式，也就是在 statement 和 row 之间选择一种
3. 配置
log_bin : 用于设定是否启用二进制日志, 由此看是未开启
重点：
You have enabled the binary log, but you haven't provided the mandatory server-id. Please refer to the proper server start-up parameters documentation
说明需要配置一个server-id， 再拿这句话百度，果然是这样。所以在 配置文件/etc/my.cn中添加 server-id = 1，再重启mysql，解决问题。而且在配置的bin-log同级目录增加了mysql-bin.000001 mysql-bin.index mysql-bin.log 三个文件，前两个是自动生成。
参数：
log_bin：设置此参数表示启用binlog功能，并指定路径名称
log_bin_index：设置此参数是指定二进制索引文件的路径与名称
binlog_do_db：此参数表示只记录指定数据库的二进制日志
binlog_ignore_db：此参数表示不记录指定的数据库的二进制日志
max_binlog_cache_size：此参数表示binlog使用的内存最大的尺寸
binlog_cache_size：此参数表示binlog使用的内存大小，可以通过状态变量binlog_cache_use和binlog_cache_disk_use来帮助测试。binlog_cache_use：使用二进制日志缓存的事务数量
binlog_cache_disk_use:使用二进制日志缓存但超过binlog_cache_size值并使用临时文件来保存事务中的语句的事务数量
max_binlog_size：Binlog最大值，最大和默认值是1GB，该设置并不能严格控制Binlog的大小，尤其是Binlog比较靠近最大值而又遇到一个比较大事务时，为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有SQL都记录进当前日志，直到事务结束
sync_binlog：这个参数直接影响mysql的性能和完整性
sync_binlog=0：
当事务提交后，Mysql仅仅是将binlog_cache中的数据写入Binlog文件，但不执行fsync之类的磁盘 同步指令通知文件系统将缓存刷新到磁盘，而让Filesystem自行决定什么时候来做同步，这个是性能最好的。
sync_binlog=n，在进行n次事务提交以后，Mysql将执行一次fsync之类的磁盘同步指令，同志文件系统将Binlog文件缓存刷新到磁盘。
Mysql中默认的设置是sync_binlog=0，即不作任何强制性的磁盘刷新指令，这时性能是最好的，但风险也是最大的。一旦系统绷Crash，在文件系统缓存中的所有Binlog信息都会丢失
自动删除binlog
通过binlog参数（expire_logs_days ）来实现mysql自动删除binlog
mysql> show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 869 |
+------------------+-----------+
1 row in set (0.00 sec)
mysql> show variables like 'expire_logs_days' ;
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| expire_logs_days | 0 |
+------------------+-------+
1 row in set (0.00 sec)
mysql> ;set global expire_logs_days=3;
ERROR:
No query specified
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'expire_logs_days' ;
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| expire_logs_days | 3 |
+------------------+-------+
1 row in set (0.00 sec)로그인 후 복사
手工删除binlog
mysql> reset master; //删除master的binlog
mysql> reset slave; //删除slave的中继日志
mysql> purge master logs before '2012-03-30 17:20:00'; //删除指定日期以前的日志索引中binlog日志文件
mysql> purge master logs to 'mysql-bin.000001'; //删除指定日志文件的日志索引中binlog日志文件로그인 후 복사
或者直接用操作系统命令直接删除
mysql> set sql_log_bin=1/0; //如果用户有super权限，可以启用或禁用当前会话的binlog记录
mysql> show master logs; //查看master的binlog日志
mysql> show binary logs; //查看master的binlog日志
mysql> show master status; //用于提供master二进制日志文件的状态信息
mysql> show slave hosts; //显示当前注册的slave的列表。不以--report-host=slave_name选项为开头的slave不会显示在本列表中로그인 후 복사
四、Slow Query Log
记录Mysql 慢查询的日志
修改配置文件 /etc/my.cnf
1. Mysql 慢查询配置相关命令：
查看日志功能是否开启：show variables like "%slow%";
mysql> show variables like "%slow%";
+---------------------------+----------------------------------------------------+
| Variable_name | Value |
+---------------------------+----------------------------------------------------+
| log_slow_admin_statements | OFF |
| log_slow_slave_statements | OFF |
| slow_launch_time | 2 |
| slow_query_log | OFF |
| slow_query_log_file | /usr/local/var/mysql/tongkundeMacBook-Pro-slow.log |
+---------------------------+----------------------------------------------------+
로그인 후 복사
slow_query_log 配置为OFF ， 说明未开启慢日志
打开慢日志功能：set global slow_query_log = on;
mysql> set global slow_query_log = on;
Query OK, 0 rows affected (0.06 sec)
로그인 후 복사
查看下默认设置的慢查询的时间：show variables like "%long_query%";
mysql> show variables like "%long_query%";
+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
로그인 후 복사
可以看出，默认是10秒，按照这个配置，数据得上n亿才能达到，为了测试我们修改一下
2. 修改Mysql配置文件的方式
3. 测试一下
위 내용은 MySQL의 4가지 로그 유형에 대한 자세한 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
