MySQL 自动清理binlog日志的方法.docx_第1页
MySQL 自动清理binlog日志的方法.docx_第2页
MySQL 自动清理binlog日志的方法.docx_第3页
MySQL 自动清理binlog日志的方法.docx_第4页
MySQL 自动清理binlog日志的方法.docx_第5页
已阅读5页,还剩3页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

网站建设定制专家MySQL 自动清理binlog日志的方法说明:开启MySQL binlog日志的服务器,如果不设置自动清理日志,默认binlog日志一直保留着,时间一长,服务器磁盘空间被binlog日志占满,导致MySQL数据库出错。使用下面方法可以安全清理binlog日志一、没有主从同步的情况下清理日志mysql -uroot -p123456 -e PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ),INTERVAL 5 DAY);#mysql 定时清理5天前的binlogmysql -u root -p #进入mysql 控制台reset master; #重置binlog二、MySQL主从同步下安全清理binlog日志1、mysql -u root -p #进入从服务器mysql控制台show slave statusG; #检查从服务器正在读取哪个日志,有多个从服务器,选择时间最早的一个做为目标日志。2、进入主服务器mysql控制台show master log; #获得主服务器上的一系列日志PURGE MASTER LOGS TO binlog.000058; #删除binlog.000005之前的,不包括binlog.000058PURGE MASTER LOGS BEFORE 2016-06-22 13:00:00; #清除2016-06-22 13:00:00前binlog日志PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY); #清除3天前binlog日志3、 设置自动清理MySQL binlog日志vi /etc/f #编辑配置expire_logs_days = 15 #自动删除15天前的日志。默认值为0,表示从不删除。log-bin=mysql-bin #注释掉之后,会关闭binlog日志binlog_format=mixed #注释掉之后,会关闭binlog日志:wq! #保存退出扩展阅读:mysql help purge;Name: PURGE BINARY LOGSDescription:Syntax:PURGE BINARY | MASTER LOGS TO log_name | BEFORE datetime_expr The binary log is a set of files that contain information about datamodifications made by the MySQL server. The log consists of a set ofbinary log files, plus an index file (see/doc/refman/5.5/en/binary-log.html).The PURGE BINARY LOGS statement deletes all the binary log files listedin the log index file prior to the specified log file name or date.BINARY and MASTER are synonyms. Deleted log files also are removed fromthe list recorded in the index file, so that the given log file becomesthe first in the list.This statement has no effect if the server was not started with the-log-bin option to enable binary logging.URL: /doc/refman/5.5/en/purge-binary-logs.htmlExamples:PURGE BINARY LOGS TO mysql-bin.010;PURGE BINARY LOGS BEFORE 2008-04-02 22:46:26;下面是其它网友给出的方法,大家可以参考一下MYSQL主从复制(replication)采用 RBR 模式后,binlog的格式为ROW,能解决很多原先出现的主键重复问题。在一个繁忙的master db server上,binlog日志文件增长速度很快,如果不定时清除,硬盘空间很快就会被充满。设置自动清理mysql binlog日志,配置f:expire_logs_days = 10在运行时修改:show binary logs; show variables like %log%; set global expire_logs_days = 10;清除之前可以采用相应的备份策略。手动删除10天前的MySQL binlog日志:PURGE MASTER LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY);show master logs;MASTER和BINARY是同义词。一般情况下,推荐使用MIXED binlog的复制。/doc/refman/5.1/en/open-bugs-general.html中的说明:Replication uses query-level logging: The master writes the executed queries to the binary log. This is a very fast, compact, and efficient logging method that works perfectly in most cases.附:关于MYSQL复制的几种模式从 MySQL 5.1.12 开始,可以用以下三种模式来实现: 基于SQL语句的复制(statement-based replication, SBR), 基于行的复制(row-based replication, RBR), 混合模式复制(mixed-based replication, MBR)。相应地,binlog的格式也有三种:STATEMENT,ROW,MIXED。 MBR 模式中,SBR 模式是默认的。在运行时可以动态改动 binlog的格式,除了以下几种情况:. 存储流程或者触发器中间. 启用了NDB. 当前会话试用 RBR 模式,并且已打开了临时表如果binlog采用了 MIXED 模式,那么在以下几种情况下会自动将binlog的模式由 SBR 模式改成 RBR 模式。. 当DML语句更新一个NDB表时. 当函数中包含 UUID() 时. 2个及以上包含 AUTO_INCREMENT 字段的表被更新时. 行任何 INSERT DELAYED 语句时. 用 UDF 时. 视图中必须要求运用 RBR 时,例如建立视图是运用了 UUID() 函数设定主从复制模式:log-bin=mysql-bin#binlog_format=STATEMENT#binlog_format=ROWbinlog_format=MIXED也可以在运行时动态修改binlog的格式。例如mysql SET SESSION binlog_format = STATEMENT;mysql SET SESSION binlog_format = ROW;mysql SET SESSION binlog_format = MIXED;mysql SET GLOBAL binlog_format = STATEMENT;mysql SET GLOBAL binlog_format = ROW;mysql SET GLOBAL binlog_format = MIXED;两种模式各自的优缺点:SBR 的优点:历史悠久,技能成熟binlog文件较小binlog中包含了所有数据库修改信息,可以据此来审核数据库的安全等情况binlog可以用于实时的还原,而不仅仅用于复制主从版本可以不一样,从服务器版本可以比主服务器版本高SBR 的缺点:不是所有的UPDATE语句都能被复制,尤其是包含不确定操作的时候。调用具有不确定因素的 UDF 时复制也可能出疑问运用以下函数的语句也不能被复制:* LOAD_FILE()* UUID()* USER()* FOUND_ROWS()* SYSDATE() (除非启动时启用了 sysdate-is-now 选项)INSERT SELECT 会产生比 RBR 更多的行级锁复制须要执行 全表扫描(WHERE 语句中没有运用到索引)的 UPDATE 时,须要比 RBR 请求更多的行级锁对于有 AUTO_INCREMENT 字段的 InnoDB表而言,INSERT 语句会阻塞其他 INSERT 语句对于一些复杂的语句,在从服务器上的耗资源情况会更严重,而 RBR 模式下,只会对那个发生变化的记录产生影响存储函数(不是存储流程 )在被调用的同时也会执行一次 NOW() 函数,这个可以说是坏事也可能是好事确定了的 UDF 也须要在从服务器上执行数据表必须几乎和主服务器保持一致才行,否则可能会导致复制出错执行复杂语句如果出错的话,会消耗更多资源RBR 的优点:任何情况都可以被复制,这对复制来说是最安全可靠的和其他大多数数据库系统的复制技能一样多数情况下,从服务器上的表如果有主键的话,复制就会快了很多复制以下几种语句时的行锁更少:* INSERT SELECT* 包含 AUTO_INCREMENT 字段的 INSERT* 没有附带条件或者并没有修改很多记录的 UPDATE 或 DELETE 语句执行 INSERT,UPDATE,DELETE 语句时锁更少从服务器上采用多线程来执行复制成为可能RBR 的缺点:binlog 大了很多复杂的回滚时 binlog 中会包含大量的数据主服务器上执行 UPDATE 语句时,所有发生变化的记录都会写到 binlog 中,而 SBR 只会写一次,这会导致频繁发生 binlog 的并发写疑问UDF 产生的大 BLOB 值会导致复制变慢不能从 binlog 中看到都复制了写什么语句(加密过的)当在非事务表上执行一段堆积的SQL语句时,最好采用 SBR 模式,否则很容易导致主从服务器的数据不一致情况发生另外,针对系统库 mysql 里面的表发生变化时的处理准则如下:如果是采用 INSERT,UPDATE,DELETE 直接操作表的情况,则日志格式根据 binlog_format 的设定而记录如果是采用 GRANT,REVOKE,SET PASSWORD 等管理语句来做的话,那么无论如何 都采用 SBR 模式记录。注:采用 RBR 模式后,能处理很多原先出现的主键重复问题。实例:对于insert into db_allot_ids select * from db_allot_ids 这个语句:在BINLOG_FORMAT=STATEMENT 模式下:BINLOG日志信息为:BEGIN/*!*/;# at 173#090612 16:05:42 server id 1 end_log_pos 288 Query thread_id=4 exec_time=0 error_code=0SET TIMESTAMP=1244793942/*!*/;insert into db_allot_ids select * from db_allot_ids/*!*/;在BINLOG_FORMAT=ROW 模式下:BINLOG日志信息为:BINLOG hA0yShMBAAAAMwAAAOAAAAAAAA8AAAAAAAAAA1NOUwAMZGJfYWxsb3RfaWRzAAIBAwAAhA0yShcBAAAANQAAABUBAAAQAA8AAAAAAAEAAv/8AQEAAAD8AQEAAAD8AQEAAAD8AQEAAAA=/*!*/;清理日志步骤1.查找日志档案mysql show binary logs;+-+-+| Log_name | File_size |+-+-+| ablelee.000001 | 150462942 | ablelee.000002 | 125 | ablelee.000003 | 106 |+-+-+2.删除bin-log(删除ablelee.000003之前的而没有包含ablelee.000003)mysql purge binary logs to ablelee.000003;Query OK, 0 rows affected (0.16 sec)3. 查询结果(现在只有一条记录了.)mysql show binlog eventsG* 1. row * Log_name: ablelee.000003 Pos: 4Event_type: Format_desc Server_id: 1End_log_pos: 106 Info: Server ver: 5.1.26-rc-log, Binlog ver: 41 row in set (0.01 sec)(ablelee.000001和ablelee.000002已被删除)mysql show binary logs;+-+-+| Log_name | File_size |+-+-+| ablelee.000003 | 106 |+-+-+1 row in set (0.00 sec)(删除的其它格式运用!) PURGE MASTER | BINARY LOGS TO log_namePURGE MASTER | BINARY LOGS BEF

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论