MySQL数据库binlog日志管理

Binlog是复制的基础和关键。 

 

相关参数

 

log-bin = mysql-bin 

#启用binlog，在参数“datadir”的路径下，以mysql-bin.000001开始，并生成mysql-bin.index日志索引文件

 

max_binlog_size = 256M

#指定binlog文件的大小，指定为256M，如果遇到大事务，则可能超过该大小。

#个人认为该文件不宜过大，256合适。

 

binlog_cache_size = 4M

#指定每个会话在事务操作期间缓存的binlog大小。

 

max_binlog_cache_size = 64M

#指定同一时间所有会话在事务操作期间缓存的binlog大小。

 

expire_logs_days = 7

#binlog文件保留天数。默认值为0，即永久保留。

#在如下情况会发生binlog的自动删除：logflush时。

#那什么时候发生log flush？

#1.重启/启动；

#2.binlog文件达到max_binlog_size，切换新的binlog时；

#3.手工执行”flush logs;”命令切换binlog文件时。

 

log_slave_updates = 1

#在这个参数仅仅在slave库上有用，表示该slave库重演的操作也写入到其binlog中         

 

日志维护

 

查看binlog文件

SHOW MASTER LOGS;

#SHOW BINARY LOGS; #两者等价

 

切换新的binlog

FLUSH LOGS;

#该语句执行不会影响slave复制，slave端会及时获取到新的binlog文件和pos位置

 

自动删除，expire_logs_days参数配置了binlog过期自动删除的天数。

 

手工删除，如下方法可以手工删除binlog文件：

PURGE BINARY LOGS TO 'mysql-bin.000010'; #删除mysql-bin.000010之前的所有binlog文件

PURGE BINARY LOGS BEFORE '2008-04-02 22:46:26'; #删除2008-04-02 22:46:26之前的文件

#PURGE BINARY LOGS与PURGE MASTER LOGS等价

#该语句是去扫描index文件确定要删除的对象，如果要删除的对象不存在（比如被rm删除），那么该语句

#执行时会报错。此时，我们必须手工编辑（使用vi或者ue）index文件，剔除那些已经被删除的文件行记录。

 

重置binlog

RESET MASTER;

#该语句删除所有index中的文件，并且重置binlog序号为000001

#在复制环境谨慎使用该语句，该语句会造成slave端无法获取000001文件及pos位置

#即，slave的IO线程会失败

#PS,另外有个RESET SLAVE;语句，该语句是在slave端清除IO线程的：

#     Master_Log_File:

#Read_Master_Log_Pos: 4

#      Relay_Log_File: pc-qiuht-relay-bin.000001

#       Relay_Log_Pos: 4

#但是master的地址和端口不被清除

#该语句会将gtid_purged及 gtid_executed置空