찾다
데이터 베이스MySQL 튜토리얼自动清理MySQL binlog日志与手动删除的设置

自动清理MySQL binlog日志与手动删除的设置

Jun 07, 2016 pm 04:11 PM
binlogmysql삭제통나무청소하다오토매틱설정

以下的文章主要讲述的是对自动清理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日志和手动删除的方法的介绍,望你能有所收获。


성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
MySQL에서 데이터베이스 업그레이드를 어떻게 처리합니까?MySQL에서 데이터베이스 업그레이드를 어떻게 처리합니까?Apr 30, 2025 am 12:28 AM

MySQL 데이터베이스를 업그레이드하는 단계에는 다음이 포함됩니다. 1. 데이터베이스 백업, 2. 현재 MySQL 서비스 중지, 3. 새 버전의 MySQL 설치, 4. 새 버전의 MySQL 서비스 시작, 5. 데이터베이스 복구. 업그레이드 프로세스 중에 호환성 문제가 필요하며 Perconatoolkit과 같은 고급 도구를 테스트 및 최적화에 사용할 수 있습니다.

MySQL에 사용할 수있는 다른 백업 전략은 무엇입니까?MySQL에 사용할 수있는 다른 백업 전략은 무엇입니까?Apr 30, 2025 am 12:28 AM

MySQL 백업 정책에는 논리 백업, 물리적 백업, 증분 백업, 복제 기반 백업 및 클라우드 백업이 포함됩니다. 1. 논리 백업은 MySQLDump를 사용하여 데이터베이스 구조 및 데이터를 내보내며 소규모 데이터베이스 및 버전 마이그레이션에 적합합니다. 2. 물리적 백업은 데이터 파일을 복사하여 빠르고 포괄적이지만 데이터베이스 일관성이 필요합니다. 3. 증분 백업은 이진 로깅을 사용하여 변경 사항을 기록합니다. 이는 큰 데이터베이스에 적합합니다. 4. 복제 기반 백업은 서버에서 백업하여 생산 시스템에 미치는 영향을 줄입니다. 5. AmazonRDS와 같은 클라우드 백업은 자동화 솔루션을 제공하지만 비용과 제어를 고려해야합니다. 정책을 선택할 때 데이터베이스 크기, 가동 중지 시간 허용 오차, 복구 시간 및 복구 지점 목표를 고려해야합니다.

MySQL 클러스터링이란 무엇입니까?MySQL 클러스터링이란 무엇입니까?Apr 30, 2025 am 12:28 AM

mysqlclusteringenhancesdatabaserobustness andscalabilitydaturedingdataacrossmultiplenodes.itusesthendbenginefordatareplicationandfaulttolerance, highavailability를 보장합니다

MySQL의 성능을 위해 데이터베이스 스키마 설계를 어떻게 최적화합니까?MySQL의 성능을 위해 데이터베이스 스키마 설계를 어떻게 최적화합니까?Apr 30, 2025 am 12:27 AM

MySQL에서 데이터베이스 스키마 설계 최적화는 다음 단계를 통해 성능을 향상시킬 수 있습니다. 1. 인덱스 최적화 : 공통 쿼리 열에서 인덱스 생성, 쿼리의 오버 헤드 균형 및 업데이트 삽입. 2. 표 구조 최적화 : 정규화 또는 정상화를 통한 데이터 중복성을 줄이고 액세스 효율을 향상시킵니다. 3. 데이터 유형 선택 : 스토리지 공간을 줄이기 위해 Varchar 대신 Int와 같은 적절한 데이터 유형을 사용하십시오. 4. 분할 및 하위 테이블 : 대량 데이터 볼륨의 경우 파티션 및 하위 테이블을 사용하여 데이터를 분산시켜 쿼리 및 유지 보수 효율성을 향상시킵니다.

MySQL 성능을 어떻게 최적화 할 수 있습니까?MySQL 성능을 어떻게 최적화 할 수 있습니까?Apr 30, 2025 am 12:26 AM

tooptimizemysqlperformance, followthesesteps : 1) 구현 properIndexingToSpeedUpqueries, 2) useExplaintoAnalyzeanDoptimizeQueryPerformance, 3) AdvertServerConfigUrationSettingstingslikeInnodb_buffer_pool_sizeandmax_connections, 4) uspartOflEtOflEtOflestoI

데이터 처리 및 계산에 MySQL 기능을 사용하는 방법데이터 처리 및 계산에 MySQL 기능을 사용하는 방법Apr 29, 2025 pm 04:21 PM

MySQL 기능은 데이터 처리 및 계산에 사용될 수 있습니다. 1. 기본 사용에는 문자열 처리, 날짜 계산 및 수학 연산이 포함됩니다. 2. 고급 사용에는 복잡한 작업을 구현하기 위해 여러 기능을 결합하는 것이 포함됩니다. 3. 성능 최적화를 위해서는 WHERE 절에서 기능 사용 및 GroupBy 및 임시 테이블 사용을 피해야합니다.

MySQL에 데이터를 일괄 삽입하는 효율적인 방법MySQL에 데이터를 일괄 삽입하는 효율적인 방법Apr 29, 2025 pm 04:18 PM

MySQL에 데이터 삽입을위한 효율적인 방법은 다음과 같습니다. 1. InsertInto 사용 ... 값 구문 사용 ... 값 구문, 2. 트랜잭션 처리 사용, 3. 트랜잭션 처리 사용, 4. 배치 크기 조정, 5. 인덱스 비활성화, 6. Insertignore 또는 Insert ... ondupliceKeyUpdate를 사용하여 데이터베이스 작동 효율성을 크게 향상시킬 수 있습니다.

MySQL 테이블에 필드를 추가 및 삭제하는 단계MySQL 테이블에 필드를 추가 및 삭제하는 단계Apr 29, 2025 pm 04:15 PM

MySQL에서는 altertabletable_nameaddcolumnnew_columnvarchar (255) 이후에 필드를 추가하여 altertabletable_namedropcolumncolumn_to_drop을 사용하여 필드를 삭제합니다. 필드를 추가 할 때는 쿼리 성능 및 데이터 구조를 최적화하기위한 위치를 지정해야합니다. 필드를 삭제하기 전에 작업이 돌이킬 수 없는지 확인해야합니다. 온라인 DDL, 백업 데이터, 테스트 환경 및 저하 기간을 사용하여 테이블 구조 수정은 성능 최적화 및 모범 사례입니다.

See all articles

핫 AI 도구

Undresser.AI Undress

Undresser.AI Undress

사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover

AI Clothes Remover

사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool

Undress AI Tool

무료로 이미지를 벗다

Clothoff.io

Clothoff.io

AI 옷 제거제

Video Face Swap

Video Face Swap

완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!

뜨거운 도구

Atom Editor Mac 버전 다운로드

Atom Editor Mac 버전 다운로드

가장 인기 있는 오픈 소스 편집기

에디트플러스 중국어 크랙 버전

에디트플러스 중국어 크랙 버전

작은 크기, 구문 강조, 코드 프롬프트 기능을 지원하지 않음

SublimeText3 Mac 버전

SublimeText3 Mac 버전

신 수준의 코드 편집 소프트웨어(SublimeText3)

안전한 시험 브라우저

안전한 시험 브라우저

안전한 시험 브라우저는 온라인 시험을 안전하게 치르기 위한 보안 브라우저 환경입니다. 이 소프트웨어는 모든 컴퓨터를 안전한 워크스테이션으로 바꿔줍니다. 이는 모든 유틸리티에 대한 액세스를 제어하고 학생들이 승인되지 않은 리소스를 사용하는 것을 방지합니다.

Eclipse용 SAP NetWeaver 서버 어댑터

Eclipse용 SAP NetWeaver 서버 어댑터

Eclipse를 SAP NetWeaver 애플리케이션 서버와 통합합니다.