以下的文章主要讲述的是对自动清理MySQL binlog日志与手动删除的实际解决方案的设置, 我们大家都知道MySQL数据库从复制(replication)采用了RBR 模式之后,binlog 的格式为ROW,其主要作用是解决很多原先出现的主键重复问题。 在一个繁忙的master db server
以下的文章主要讲述的是对自动清理MySQL binlog日志与手动删除的实际解决方案的设置, 我们大家都知道MySQL数据库从复制(replication)采用了RBR 模式之后,binlog 的格式为"ROW",其主要作用是解决很多原先出现的主键重复问题。
在一个繁忙的master db server上,MySQL binlog日志文件增长速度很快,如果不定时清除,硬盘空间很快就会被充满。
设置自动清理MySQL binlog日志,配置my.cnf:
expire_logs_days = 10
在运行时修改:
<ol class="dp-xml"> <li class="alt"><span><span>show binary logs; </span></span></li> <li><span>show variables like '%log%'; </span></li> <li class="alt"> <span>set global </span><span class="attribute">expire_logs_days</span><span> = </span><span class="attribute-value">10</span><span>; </span> </li> </ol>
清除之前可以采用相应的备份策略。
手动删除10天前的MySQL binlog日志:
<ol class="dp-xml"> <li class="alt"><span><span>PURGE MASTER LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY); </span></span></li> <li><span>show master logs; </span></li> </ol>
MASTER和BINARY是同义词。
一般情况下,推荐使用MIXED binlog的复制。http://dev.MySQL.com/doc/refman/5.1/en/open-bugs-general.html中的说明:Replication uses query-level logging: The master writes the executed queries to the binary logThis 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 模式,那么在以下几种情况下会自动将MySQL binlog的模式由 SBR 模式改成 RBR 模式。
当DML语句更新一个NDB表时
当函数中包含 UUID() 时
2个及以上包含 AUTO_INCREMENT 字段的表被更新时
行任何 INSERT DELAYED 语句时
用 UDF 时
视图中必须要求运用 RBR 时,例如建立视图是运用了 UUID() 函数
设定主从复制模式:
<ol class="dp-xml"> <li class="alt"> <span><span class="attribute">log-bin</span><span>=</span></span>MySQL<span><span>-bin </span></span> </li> <li> <span>#</span><span class="attribute">binlog_format</span><span>=</span><span class="attribute-value">"STATEMENT"</span><span> </span> </li> <li class="alt"> <span>#</span><span class="attribute">binlog_format</span><span>=</span><span class="attribute-value">"ROW"</span><span> </span> </li> <li> <span class="attribute">binlog_format</span><span>=</span><span class="attribute-value">"MIXED"</span><span> </span> </li> </ol>
也可以在运行时动态修改binlog的格式。例如
<ol class="dp-xml"> <li class="alt">MySQL<span><span class="tag">></span><span> SET SESSION </span><span class="attribute">binlog_format</span><span> = </span><span class="attribute-value">'STATEMENT'</span><span>; </span></span> </li> <li>MySQL<span class="tag">></span><span> SET SESSION </span><span class="attribute">binlog_format</span><span> = </span><span class="attribute-value">'ROW'</span><span>; </span> </li> <li class="alt">MySQL<span class="tag">></span><span> SET SESSION </span><span class="attribute">binlog_format</span><span> = </span><span class="attribute-value">'MIXED'</span><span>; </span> </li> <li>MySQL<span class="tag">></span><span> SET GLOBAL </span><span class="attribute">binlog_format</span><span> = </span><span class="attribute-value">'STATEMENT'</span><span>; </span> </li> <li class="alt">MySQL<span class="tag">></span><span> SET GLOBAL </span><span class="attribute">binlog_format</span><span> = </span><span class="attribute-value">'ROW'</span><span>; </span> </li> <li>MySQL<span class="tag">></span><span> SET GLOBAL </span><span class="attribute">binlog_format</span><span> = </span><span class="attribute-value">'MIXED'</span><span>; </span> </li> </ol>
两种模式各自的优缺点:
SBR 的优点:
历史悠久,技能成熟
binlog文件较小
binlog中包含了所有数据库修改信息,可以据此来审核数据库的安全等情况
MySQL 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 直接操作表的情况,则日志格式根据 MySQL binlog_format 的设定而记录
如果是采用 GRANT,REVOKE,SET PASSWORD 等管理语句来做的话,那么无论如何 都采用 SBR 模式记录。
注:采用 RBR 模式后,能处理很多原先出现的主键重复问题。实例:
对于insert into db_allot_ids select from db_allot_ids 这个语句:
在BINLOG_FORMAT=STATEMENT 模式下:
BINLOG日志信息为:
<ol class="dp-xml"> <li class="alt"><span><span>BEGIN </span></span></li> <li><span>/*!*/; </span></li> <li class="alt"><span># at 173 </span></li> <li> <span>#090612 16:05:42 server id 1 end_log_pos 288 Query </span><span class="attribute">thread_id</span><span>=</span><span class="attribute-value">4</span><span> </span><span class="attribute">exec_time</span><span>=</span><span class="attribute-value">0</span><span> </span><span class="attribute">error_code</span><span>=</span><span class="attribute-value">0</span><span> </span> </li> <li class="alt"> <span>SET </span><span class="attribute">TIMESTAMP</span><span>=</span><span class="attribute-value">1244793942</span><span>/*!*/; </span> </li> <li><span>insert into db_allot_ids select * from db_allot_ids </span></li> <li class="alt"><span>/*!*/; </span></li> </ol>
在BINLOG_FORMAT=ROW 模式下:
BINLOG日志信息为:
<ol class="dp-xml"> <li class="alt"><span><span>BINLOG ' </span></span></li> <li><span>hA0yShMBAAAAMwAAAOAAAAAAAA8AAAAAAAAAA1NOUwAMZGJfYWxsb3RfaWRzAAIBAwAA </span></li> <li class="alt"> <span>hA0yShcBAAAANQAAABUBAAAQAA8AAAAAAAEAAv/</span><span class="attribute">8AQEAAAD8AQEAAAD8AQEAAAD8AQEAAAA</span><span>= </span> </li> <li><span>'/*!*/; </span></li> </ol>
以上的相关内容就是对设置自动清理MySQL binlog日志和手动删除的方法的介绍,望你能有所收获。

MySQL和SQLite的主要区别在于设计理念和使用场景:1.MySQL适用于大型应用和企业级解决方案,支持高性能和高并发;2.SQLite适合移动应用和桌面软件,轻量级且易于嵌入。

MySQL中的索引是数据库表中一列或多列的有序结构,用于加速数据检索。1)索引通过减少扫描数据量提升查询速度。2)B-Tree索引利用平衡树结构,适合范围查询和排序。3)创建索引使用CREATEINDEX语句,如CREATEINDEXidx_customer_idONorders(customer_id)。4)复合索引可优化多列查询,如CREATEINDEXidx_customer_orderONorders(customer_id,order_date)。5)使用EXPLAIN分析查询计划,避

在MySQL中使用事务可以确保数据一致性。1)通过STARTTRANSACTION开始事务,执行SQL操作后用COMMIT提交或ROLLBACK回滚。2)使用SAVEPOINT可以设置保存点,允许部分回滚。3)性能优化建议包括缩短事务时间、避免大规模查询和合理使用隔离级别。

选择PostgreSQL而非MySQL的场景包括:1)需要复杂查询和高级SQL功能,2)要求严格的数据完整性和ACID遵从性,3)需要高级空间功能,4)处理大数据集时需要高性能。PostgreSQL在这些方面表现出色,适合需要复杂数据处理和高数据完整性的项目。

MySQL数据库的安全可以通过以下措施实现:1.用户权限管理:通过CREATEUSER和GRANT命令严格控制访问权限。2.加密传输:配置SSL/TLS确保数据传输安全。3.数据库备份和恢复:使用mysqldump或mysqlpump定期备份数据。4.高级安全策略:使用防火墙限制访问,并启用审计日志记录操作。5.性能优化与最佳实践:通过索引和查询优化以及定期维护兼顾安全和性能。

如何有效监控MySQL性能?使用mysqladmin、SHOWGLOBALSTATUS、PerconaMonitoringandManagement(PMM)和MySQLEnterpriseMonitor等工具。1.使用mysqladmin查看连接数。2.用SHOWGLOBALSTATUS查看查询数。3.PMM提供详细性能数据和图形化界面。4.MySQLEnterpriseMonitor提供丰富的监控功能和报警机制。

MySQL和SQLServer的区别在于:1)MySQL是开源的,适用于Web和嵌入式系统,2)SQLServer是微软的商业产品,适用于企业级应用。两者在存储引擎、性能优化和应用场景上有显着差异,选择时需考虑项目规模和未来扩展性。

在需要高可用性、高级安全性和良好集成性的企业级应用场景下,应选择SQLServer而不是MySQL。1)SQLServer提供企业级功能,如高可用性和高级安全性。2)它与微软生态系统如VisualStudio和PowerBI紧密集成。3)SQLServer在性能优化方面表现出色,支持内存优化表和列存储索引。


热AI工具

Undresser.AI Undress
人工智能驱动的应用程序,用于创建逼真的裸体照片

AI Clothes Remover
用于从照片中去除衣服的在线人工智能工具。

Undress AI Tool
免费脱衣服图片

Clothoff.io
AI脱衣机

Video Face Swap
使用我们完全免费的人工智能换脸工具轻松在任何视频中换脸!

热门文章

热工具

VSCode Windows 64位 下载
微软推出的免费、功能强大的一款IDE编辑器

ZendStudio 13.5.1 Mac
功能强大的PHP集成开发环境

螳螂BT
Mantis是一个易于部署的基于Web的缺陷跟踪工具,用于帮助产品缺陷跟踪。它需要PHP、MySQL和一个Web服务器。请查看我们的演示和托管服务。

记事本++7.3.1
好用且免费的代码编辑器

mPDF
mPDF是一个PHP库,可以从UTF-8编码的HTML生成PDF文件。原作者Ian Back编写mPDF以从他的网站上“即时”输出PDF文件,并处理不同的语言。与原始脚本如HTML2FPDF相比,它的速度较慢,并且在使用Unicode字体时生成的文件较大,但支持CSS样式等,并进行了大量增强。支持几乎所有语言,包括RTL(阿拉伯语和希伯来语)和CJK(中日韩)。支持嵌套的块级元素(如P、DIV),