아래 편집기는 Mysql 데이터베이스에서 Binlog 로그 사용에 대한 요약을 제공합니다(필독 기사). 에디터가 꽤 좋다고 생각해서 지금 공유해서 참고용으로 올려보겠습니다. 에디터를 따라가서 살펴보겠습니다
binlog 바이너리 로그가 mysql 데이터베이스에 얼마나 중요한지는 여기서 더 말하지 않겠습니다. 다음은 나의 일상 운영 경험을 바탕으로 온라인 참고 자료를 결합하여 binlog 로그 사용을 요약한 것입니다.
1. binlog 로그 소개
1) binlog란 무엇입니까
binlog 로그는 데이터를 업데이트하거나 잠재적으로 업데이트된 데이터가 있는 모든 명령문(예: 어떤 행과도 일치하지 않는 DELETE)을 기록하는 데 사용됩니다. ). 명령문은 데이터 변경을 설명하는 "이벤트"로 저장됩니다.
2) Binlog 기능
데이터 업데이트를 위한 binlog가 있어 실시간 백업에 활용이 가능하며, master/slave 마스터-슬레이브 복제와 결합 가능합니다.
3) binlog 관련 매개변수
log_bin
이 매개변수를 설정한다는 것은 binlog 기능을 활성화하고 경로 이름을 지정하는 것을 의미합니다.
log_bin_index
바이너리 인덱스 파일의 경로와 이름을 지정하려면 이 매개변수를 설정하세요.
binlog_do_db
이 매개변수는 지정된 데이터베이스의 바이너리 로그만 기록됨을 나타냅니다.
binlog_ignore_db
이 매개변수는 바이너리 로그가 기록됨을 나타냅니다. 지정된 데이터베이스의 로그가 기록되지 않습니다
max_binlog_cache_size
이 매개변수는 사용된 메모리의 최대 크기를 나타냅니다. by 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와 같은 디스크 동기화 명령이 최고의 성능을 발휘합니다.
sync_binlog=n, n번의 트랜잭션 제출 후 Mysql은 fsync와 같은 디스크 동기화 명령을 실행하고 Comrade 파일 시스템은 Binlog 파일 캐시를 디스크에 새로 고칩니다.
Mysql의 기본 설정은 sync_binlog=0으로, 이는 필수 디스크 새로 고침 명령이 수행되지 않음을 의미합니다. 이때 성능은 최고이지만 위험도 가장 큽니다. 시스템이 충돌하면 파일 시스템 캐시에 있는 모든 Binlog 정보가 손실됩니다
4) Binlog삭제
Binlog는 수동 또는 자동으로 삭제할 수 있습니다.
a) binlog 매개변수(expire_logs_days)를 통해 binlog 자동 삭제
mysql binlog 자동 삭제
mysql> show binary logs; mysql> show variables like 'expire_logs_days'; //该参数表示binlog日志自动删除/过期的天数，默认值为0，表示不自动删除 mysql> set global expire_logs_days=3; //表示日志保留3天，3天后就自动过期。
b) binlog 수동 삭제
mysql> reset master; //删除master的binlog，即手动删除所有的binlog日志 mysql> reset slave; //删除slave的中继日志 mysql> purge master logs before '2012-03-30 17:20:00'; //删除指定日期以前的日志索引中binlog日志文件 mysql> purge master logs to 'binlog.000002'; //删除指定日志文件的日志索引中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不会显示在本列表中 mysql> flush logs; //产生一个新的binlog日志文件
Mysql binlog 로그 자동 정리 및 수동 삭제 사례 설명:
当开启MySQL数据库主从时，会产生大量如mysql-bin.00000* log的文件，这会大量耗费您的硬盘空间。
mysql-bin.000001
mysql-bin.000002
mysql-bin.000003
mysql-bin.000004
mysql-bin.000005
…
删除这些binlog日志有三种解决方法：
1.关闭mysql主从，关闭binlog；
实例操作如下：
[root@huqniupc ~]# vim /etc/my.cnf //注释掉log-bin和binlog_format
# Replication Master Server (default)
# binary logging is required for replication
# log-bin=mysql-bin
# binary logging format - mixed recommended
# binlog_format=mixed
然后重启数据库
2.开启mysql主从，设置expire_logs_days；
实例操作如下：
[root@huqniupc ~]# vim /etc/my.cnf //修改expire_logs_days,x是自动删除的天数，一般将x设置为短点，如10
expire_logs_days = x //二进制日志自动删除的天数。默认值为0,表示“没有自动删除”
此方法需要重启mysql
当然也可以不重启mysql,开启mysql主从，直接在mysql里设置expire_logs_days
> show binary logs;
> show variables like '%log%';
> set global expire_logs_days = 10;
3.手动清除binlog文件，(比如Mysql> PURGE MASTER LOGS TO ‘MySQL-bin.010′;）
实例操作如下：
[root@huqniupc ~]# /usr/local/mysql/bin/mysql -u root -p
> PURGE MASTER LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY); //删除10天前的MySQL binlog日志,附录2有关于PURGE MASTER LOGS手动删除用法及示例
> show master logs;
也可以重置master，删除所有binlog文件：
# /usr/local/mysql/bin/mysql -u root -p
> reset master; //附录3有清除binlog时，对从mysql的影响说明
---------------------------------------------------------------
PURGE MASTER LOGS手动删除用法及示例,MASTER和BINARY是同义词
> PURGE {MASTER | BINARY} LOGS TO 'log_name'
> PURGE {MASTER | BINARY} LOGS BEFORE 'date'
删除指定的日志或日期之前的日志索引中的所有二进制日志。这些日志也会从记录在日志索引文件中的清单中被删除MySQL BIN-LOG 日志，这样被给定的日志成为第一个。
实例：
> PURGE MASTER LOGS TO 'MySQL-bin.010'; //清除MySQL-bin.010日志
> PURGE MASTER LOGS BEFORE '2008-06-22 13:00:00'; //清除2008-06-22 13:00:00前binlog日志
> PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY); //清除3天前binlog日志BEFORE，变量的date自变量可以为'YYYY-MM-DD hh:mm:ss'格式。
-----------------------------------------------------5) binlog 삭제 시 mysql에 미치는 영향
如果有一个活跃的slave从属服务器，该服务器当前正在读取您正在试图删除的日志之一，则本语句不会起作用，而是会失败，并伴随一个错误；不过如果slave从属服务器是关闭的（或master-slave主从关系关闭），并且碰巧清理了其想要读取的日志之一，则slave从属服务器启动后不能复制；当从属服务器正在复制时，本语句可以安全运行，不需要停止它们。
6）binglog的查看
通过mysqlbinlog命令可以查看binlog的内容
[root@localhost ~]# mysqlbinlog /home/mysql/binlog/binlog.000003 | more /*!40019 SET @@session.max_insert_delayed_threads=0*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 4 #120330 16:51:46 server id 1 end_log_pos 98 Start: binlog v 4, server v 5.0.45-log created 120330 1 6:51:46 # Warning: this binlog was not closed properly. Most probably mysqld crashed writing it. # at 196 #120330 17:54:15 server id 1 end_log_pos 294 Query thread_id=3 exec_time=2 error_code=0 SET TIMESTAMP=1333101255/*!*/; insert into tt7 select * from tt7/*!*/; # at 294 #120330 17:54:46 server id 1 end_log_pos 388 Query thread_id=3 exec_time=28 error_code=0 SET TIMESTAMP=1333101286/*!*/; alter table tt7 engine=innodb/*!*/;
解析binlog格式：
位置
位于文件中的位置，“at 196”说明“事件”的起点，是以第196字节开始；“end_log_pos 294”说明以第294字节结束
事件发生的时间戳：“120330 17:54:46”
事件执行时间
事件执行花费的时间:"exec_time=28"
错误码
错误码为：“error_code=0”
服务器的标识
服务器的标识id：“server id 1”
注意下面几点：
1.mysql的日志切不可想象是可以恢复到任何时间的状态，这个恢复是有前提的！
至少得有一个从日志记录开始后的数据库备份，通过日志恢复数据库实际上只是一个对以前操作的回放过程而已，不用想得太复杂。
既然是回放操作，那么就得注意了，如果是执行了两次恢复那就相当于是回放了两次，后果可想而知。
所以：
1）恢复前务必先备份数据.
2）由于二进制文件多,并且需要恢复的数据跨度大,可以考虑将日志文件合并在恢复.
2. 开启binlog日志功能
要想通过日志恢复数据库，必须首先在my.cnf文件里定义，log-bin=mysql-bin，这样产生的binlog日志名就是以mysql-bin命名的
3.什么时候会生成新的binlog文件
1）在备份的时候加入--flush-logs
2）重新启动mysql服务的时候
特别提示，mysql每次启动都会重新生成一个类似mysql-bin.00000n的文件，如果你的mysql每天都要重新启动一次的话，这时候你就要特别注意不要选错日志文件了。
二、binlog日志格式介绍
（1）Mysql binlog日志有三种格式，分别是Statement、MiXED、ROW
1）Statement：每一条会修改数据的sql都会记录在binlog中
优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。(相比row能节约多少性能与日志量，这个取决于应用的SQL情况，正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量，但是考虑到如果带条件的update操作，以及整表删除，alter表等操作，ROW格式会产生大量日志，因此在考虑是否使用ROW格式日志时应该跟据应用的实际情况，其所产生的日志量会增加多少，以及带来的IO性能问题。)
缺点：由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在slave得到和在master端执行时候相同 的结果。另外mysql 的复制,像一些特定函数功能，slave可与master上要保持一致会有很多相关问题(如sleep()函数， last_insert_id()，以及user-defined functions(udf)会出现问题).
使用以下函数的语句也无法被复制：
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非启动时启用了 --sysdate-is-now 选项)
同时在INSERT ...SELECT 会产生比 RBR 更多的行级锁
2）Row:不记录sql语句上下文相关信息，仅保存哪条记录被修改
优点： binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题
缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容,比如一条update语句，修改多条记录，则binlog中每一条修改都会有记录，这样造成binlog日志量会很大，特别是当执行alter table之类的语句的时候，由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中。
3）Mixedlevel: 是以上两种level的混合使用，一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种.新版本的MySQL中队row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录。至于update或者delete等修改数据的语句，还是会记录所有行的变更。
Mixed日志说明：
在slave日志同步过程中，对于使用now这样的时间函数，MIXED日志格式，会在日志中产生对应的unix_timestamp()*1000的时间字符串，slave在完成同步时，取用的是sqlEvent发生的时间来保证数据的准确性。另外对于一些功能性函数slave能完成相应的数据同步，而对于上面指定的一些类似于UDF函数，导致Slave无法知晓的情况，则会采用ROW格式存储这些Binlog，以保证产生的Binlog可以供Slave完成数据同步。
（2）binlog基本配制与格式设定
1）基本配制
binlog日志格式可以通过mysql的my.cnf文件的属性binlog_format指定。如以下：
binlog_format = MIXED //binlog日志格式 log_bin =目录/mysql-bin.log //binlog日志名 expire_logs_days = 7 //binlog过期清理时间 max_binlog_size 100m //binlog每个日志文件大小
binlog-do-db=需要备份的数据库名，如果备份多个数据库，重复设置这个选项即可
binlog-ignore-db=不需要备份的数据库苦命，如果备份多个数据库，重复设置这个选项即可
2）Binlog日志格式选择
Mysql默认是使用Statement日志格式，推荐使用MIXED.
由于一些特殊使用，可以考虑使用ROWED，如自己通过binlog日志来同步数据的修改，这样会节省很多相关操作。对于binlog数据处理会变得非常轻松,相对mixed，解析也会很轻松(当然前提是增加的日志量所带来的IO开销在容忍的范围内即可)。
3）mysqlbinlog格式选择
mysql对于日志格式的选定原则:如果是采用 INSERT，UPDATE，DELETE 等直接操作表的情况，则日志格式根据 binlog_format 的设定而记录,如果是采用 GRANT，REVOKE，SET PASSWORD 等管理语句来做的话，那么无论如何 都采用 SBR 模式记录
（3）Mysql Binlog日志分析
通过MysqlBinlog指令查看具体的mysql日志，如下:
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// SET TIMESTAMP=1350355892/*!*/; BEGIN /*!*/; # at 1643330 #121016 10:51:32 server id 1 end_log_pos 1643885 Query thread_id=272571 exec_time=0 error_code=0 SET TIMESTAMP=1350355892/*!*/; Insert into T_test….) /*!*/; # at 1643885 #121016 10:51:32 server id 1 end_log_pos 1643912 Xid = 0 COMMIT/*!*/; ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
1.开始事物的时间:
SET TIMESTAMP=1350355892/*!*/;
BEGIN
2.sqlevent起点
#at 1643330 :为事件的起点，是以1643330字节开始。
3.sqlevent 发生的时间点
#121016 10:51:32:是事件发生的时间，
4.serverId
server id 1 :为master 的serverId
5.sqlevent终点及花费时间，错误码
end_log_pos 1643885:为事件的终点，是以1643885 字节结束。
execTime 0: 花费的时间
error_code=0:错误码
Xid:事件指示提交的XA事务
三、mysql日志（重点binlog日志）的优化说明
MySQL系统的伸缩性很强，既可以在充足的硬件资源环境下高效运行，也可以在极少资源环境下很好的运行，
但不管怎样，尽可能充足的硬件资源对MySQL的性能提升总是有帮助的。
下面着重分析一下MySQL的日志（主要是Binlog）对系统性能的影响，并根据日志的相关特性得出相应的优化思路。
1）日志产生的性能影响
由于日志的记录带来的直接性能损耗就是数据库系统中最为昂贵的IO资源。
MySQL的日志主要包括错误日志（ErrorLog），更新日志（UpdateLog），二进制日志（Binlog），查询日志（QueryLog），慢查询日志（SlowQueryLog）等。
特别注意：更新日志是老版本的MySQL才有的，目前已经被二进制日志替代。
在默认情况下，系统仅仅打开错误日志，关闭了其他所有日志，以达到尽可能减少IO损耗提高系统性能的目的。
但是在一般稍微重要一点的实际应用场景中，都至少需要打开二进制日志，因为这是MySQL很多存储引擎进行增量备份的基础，也是MySQL实现复制的基本条件。
有时候为了进一步的mysql性能优化，定位执行较慢的SQL语句，很多系统也会打开慢查询日志来记录执行时间超过特定数值（由我们自行设置）的SQL语句。
一般情况下，在生产系统中很少有系统会打开查询日志。因为查询日志打开之后会将MySQL中执行的每一条Query都记录到日志中，会该系统带来比较大的IO负担，而带来的实际效益却并不是非常大。一般只有在开发测试环境中，为了定位某些功能具体使用了哪些SQL语句的时候，才会在短时间段内打开该日志来做相应的分析。
所以，在MySQL系统中，会对性能产生影响的MySQL日志（不包括各存储引擎自己的日志）主要就是Binlog了。
2）Binlog 相关参数及优化策略
我们首先看看Binlog的相关参数，通过执行如下命令可以获得关于Binlog的相关参数。
当然，其中也显示出了“innodb_locks_unsafe_for_binlog”这个Innodb存储引擎特有的与Binlog相关的参数：
mysql> show variables like '%binlog%'; +-----------------------------------------+----------------------+ | Variable_name | Value | +-----------------------------------------+----------------------+ | binlog_cache_size | 16777216 | | binlog_checksum | CRC32 | | binlog_direct_non_transactional_updates | OFF | | binlog_error_action | IGNORE_ERROR | | binlog_format | MIXED | | binlog_gtid_simple_recovery | OFF | | binlog_max_flush_queue_time | 0 | | binlog_order_commits | ON | | binlog_row_image | FULL | | binlog_rows_query_log_events | OFF | | binlog_stmt_cache_size | 32768 | | binlogging_impossible_mode | IGNORE_ERROR | | innodb_api_enable_binlog | OFF | | innodb_locks_unsafe_for_binlog | OFF | | max_binlog_cache_size | 18446744073709547520 | | max_binlog_size | 1073741824 | | max_binlog_stmt_cache_size | 18446744073709547520 | | simplified_binlog_gtid_recovery | OFF | | sync_binlog | 1 | +-----------------------------------------+----------------------+ 19 rows in set (0.00 sec)
“binlog_cache_size"：在事务过程中容纳二进制日志SQL语句的缓存大小。二进制日志缓存是服务器支持事务存储引擎并且服务器启用了二进制日志(—log-bin选项)的前提下为每个客户端分配的内存，注意，是每个Client都可以分配设置大小的binlogcache空间。如果读者朋友的系统中经常会出现多语句事务的华，可以尝试增加该值的大小，以获得更有的性能。当然，我们可以通过MySQL的以下两个状态变量来判断当前的binlog_cache_size的状况：Binlog_cache_use和Binlog_cache_disk_use。
“max_binlog_cache_size”：和"binlog_cache_size"相对应，但是所代表的是binlog能够使用的最大cache内存大小。当我们执行多语句事务的时候，max_binlog_cache_size如果不够大的话，系统可能会报出“Multi-statementtransactionrequiredmorethan'max_binlog_cache_size'bytesofstorage”的错误。
“max_binlog_size”：Binlog日志最大值，一般来说设置为512M或者1G，但不能超过1G。该大小并不能非常严格控制Binlog大小，尤其是当到达Binlog比较靠近尾部而又遇到一个较大事务的时候，系统为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有SQL都记录进入当前日志，直到该事务结束。这一点和Oracle的Redo日志有点不一样，因为Oracle的Redo日志所记录的是数据文件的物理位置的变化，而且里面同时记录了Redo和Undo相关的信息，所以同一个事务是否在一个日志中对Oracle来说并不关键。而MySQL在Binlog中所记录的是数据库逻辑变化信息，MySQL称之为Event，实际上就是带来数据库变化的DML之类的Query语句。
“sync_binlog”：这个参数是对于MySQL系统来说是至关重要的，他不仅影响到Binlog对MySQL所带来的性能损耗，而且还影响到MySQL中数据的完整性。对于“sync_binlog”参数的各种设置的说明如下：
sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。
sync_binlog=n, n개의 트랜잭션이 제출될 때마다 MySQL은 fsync와 같은 디스크 동기화 명령을 수행하여 binlog_cache의 데이터를 디스크에 강제로 기록합니다.
MySQL에서는 시스템 기본 설정이 sync_binlog=0으로, 이는 필수 디스크 새로 고침 명령이 수행되지 않음을 의미하며 이때 성능은 가장 좋지만 위험도 가장 큽니다. 시스템이 충돌하면 binlog_cache의 모든 binlog 정보가 손실되기 때문입니다. "1"로 설정하면 가장 안전한 설정이지만 성능 손실이 가장 큽니다. 1로 설정하면 시스템이 충돌하더라도 실제 데이터에 큰 영향을 주지 않고 binlog_cache에서 최대 하나의 완료되지 않은 트랜잭션이 손실되기 때문입니다. 과거의 경험과 관련 테스트로 볼 때 동시 트랜잭션이 많은 시스템의 경우 "sync_binlog"가 0으로 설정된 시스템과 1로 설정된 시스템 간의 쓰기 성능 격차가 최대 5배 이상 클 수 있습니다.
또 하나:
MySQL 복제(복제)는 실제로 IO 스레드를 통해 네트워크를 통해 마스터 측의 Binlog를 슬레이브 측으로 복사한 다음 SQL을 통해 복사하는 것입니다. 이는 스레드별로 Binlog의 로그를 구문 분석한 다음 이를 데이터베이스에 적용하여 수행됩니다. 따라서 Binlog의 크기는 IO 스레드와 Msater와 슬레이브 사이의 네트워크에 직접적인 영향을 미칩니다.
MySQL에서 생성되는 Binlog의 양은 변경할 수 없습니다. 쿼리가 데이터베이스의 데이터를 변경하는 한 쿼리에 해당하는 이벤트가 Binlog에 기록되어야 합니다. 그렇다면 복제를 최적화할 수 있는 방법은 없나요? 물론 그렇지 않습니다. MySQL 복제 환경에는 실제로 복사하지 않고 복사하거나 무시해야 하는 DB 또는 테이블을 제어할 수 있는 8개의 매개변수가 있습니다.
Binlog_Do_DB: Binlog를 기록해야 하는 데이터베이스(스키마)를 설정합니다.
Binlog_Ignore_DB: Binlog를 기록할 필요가 없는 데이터베이스(스키마)를 설정합니다.
Replicate_Do_DB: 복사해야 할 데이터베이스(스키마)를 설정합니다. 여러 DB는 쉼표(",")로 구분합니다.
Replicate_Ignore_DB: 무시할 수 있는 데이터베이스(스키마)를 설정합니다. ;
Replicate_Do_Table: 복사해야 하는 테이블을 설정합니다.
Replicate_Ignore_Table: 무시할 수 있는 테이블을 설정합니다. 🎜>
Replicate_Wild_Do_Table: 함수는 Replicate_Do_Table과 동일하지만 와일드카드 문자 로 설정할 수 있습니다.
Replicate_Wild_Ignore_Table: 함수는 다음과 같습니다. Replicate_Ignore_Table과 동일하지만 와일드카드 문자로 설정할 수 있습니다.
위의 8개 매개변수를 통해 실제 필요에 따라 마스터에서 슬레이브로의 Binlog 양을 최대한 적게 매우 편리하게 제어할 수 있습니다. , 이를 통해 마스터에서 슬레이브로의 네트워크 트래픽을 줄이고 IO 스레드 수를 줄입니다. 또한 IO 양은 SQL을 구문 분석하고 적용하는 SQL 스레드 수를 줄여 궁극적으로 슬레이브의 데이터 지연 문제를 개선할 수 있습니다.
실제로 위의 8개 매개변수 중 처음 2개는 Master 측에 설정되고 마지막 6개 매개변수는 Slave 측에 설정됩니다. 처음 2개 매개변수와 마지막 6개 매개변수는 기능상 직접적으로 관련되어 있지는 않지만 모두 MySQL 복제 최적화를 위한 유사한 기능을 활성화할 수 있습니다. 물론, 주요 차이점은 다음과 같습니다.
마스터 측에서 처음 두 매개변수를 설정하면 마스터 측의 Binlog 레코드로 인해 발생하는 IO 양이 줄어들 뿐만 아니라 하지만 마스터 측의 IO 스레드도 줄어듭니다. 이렇게 하면 Binlog를 읽는 양이 줄어들고 슬레이브 측의 IO 스레드에 전달되는 Binlog의 양도 자연스럽게 줄어듭니다. 이것의 장점은 네트워크 IO를 줄이고, 슬레이브 측 IO 스레드의 IO 볼륨을 줄이고, 슬레이브 측 SQL 스레드의 작업 부하를 줄여 복제 성능 최적화를 극대화할 수 있다는 것입니다. 물론 마스터 측에 설정하는 것에도 몇 가지 단점이 있습니다. 왜냐하면 MySQL은 이벤트를 생성한 쿼리에 의해
데이터가 변경되는 DB를 기반으로 하지 않고 이벤트를 복사해야 하는지 여부를 결정하기 때문입니다. , 그러나 실행에 따라 현재 Query가 위치하는 기본 Schema는 로그인 시 지정된 DB이거나 "USEDATABASE" 실행 시 지정된 DB입니다. 현재 기본 DB가 구성에 설정된 DB와 완전히 일치하는 경우에만 IO 스레드가 슬레이브의 IO 스레드에 대한 이벤트를 읽습니다. 따라서 시스템 내에서 기본 DB와 복사할 DB 세트가 다르고, 복사해야 할 DB의 특정 Table의 데이터가 변경된 경우에는 해당 Event가 Slave로 복사되지 않으므로 이로 인해 발생하는 문제는 다음과 같습니다. 슬레이브 측의 데이터가 마스터 측의 데이터와 일치하지 않게 됩니다. 마찬가지로 복사할 필요가 없는 Schema의 데이터가 기본 Schema 하에서 변경되면 Slave 측에 Schema가 없으면 오류가 발생하고 복제가 중지됩니다. .而如果是在Slave端设置后面的六个参数，在性能优化方面可能比在Master端要稍微逊色一点，因为不管是需要还是不需要复制的Event都被会被IO线程读取到Slave端，这样不仅仅增加了网络IO量，也给Slave端的IO线程增加了RelayLog的写入量。但是仍然可以减少Slave的SQL线程在Slave端的日志应用量。虽然性能方面稍有逊色，但是在Slave端设置复制过滤机制，可以保证不会出现因为默认Schema的问题而造成Slave和Master数据不一致或者复制出错的问题。
3）慢查询日志Query Log 相关参数及使用建议
再来看看SlowQueryLog的相关参数配置。有些时候，我们为了定位系统中效率比较地下的Query语句，则需要打开慢查询日志，也就是SlowQueryLog。我们可以如下查看系统慢查询日志的相关设置：
mysql> show variables like 'log_slow%'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | log_slow_queries | ON | +------------------+-------+ 1 row in set (0.00 sec) mysql> show variables like 'long_query%'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | long_query_time | 1 | +-----------------+-------+ 1 row in set (0.01 sec)
“log_slow_queries”参数显示了系统是否已经打开SlowQueryLog功能，而“long_query_time”参数则告诉我们当前系统设置的SlowQuery记录执行时间超过多长的Query。在MySQLAB发行的MySQL版本中SlowQueryLog可以设置的最短慢查询时间为1秒，这在有些时候可能没办法完全满足我们的要求，如果希望能够进一步缩短慢查询的时间限制，可以使用Percona提供的microslow-patch（件成为mslPatch）来突破该限制。mslpatch不仅仅能将慢查询时间减小到毫秒级别，同时还能通过一些特定的规则来过滤记录的SQL，如仅记录涉及到某个表的SlowQuery等等附加功能。
打开SlowQueryLog功能对系统性能的整体影响没有Binlog那么大，毕竟SlowQueryLog的数据量比较小，带来的IO损耗也就较小，但是，系统需要计算每一条Query的执行时间，所以消耗总是会有一些的，主要是CPU方面的消耗。如果大家的系统在CPU资源足够丰富的时候，可以不必在乎这一点点损耗，毕竟他可能会给我们带来更大性能优化的收获。但如果我们的CPU资源也比较紧张的时候，也完全可以在大部分时候关闭该功能，而只需要间断性的打开SlowQueryLog功能来定位可能存在的慢查询。
MySQL的其他日志由于使用很少（QueryLog）或者性能影响很少，在此就不做过多分析了。
위 내용은 Mysql 데이터베이스 Binlog 로그 사용 코드 요약에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
