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置空