binlog 로그를 자동으로 정리하는 MySQL 방법

지침:

MySQL 활성화 binlog 서버가 로그를 자동으로 정리하도록 설정되어 있지 않으면 기본적으로 binlog 로그가 유지됩니다. 시간이 지남에 따라 서버 디스크 공간이 binlog 로그로 가득 차서 MySQL 데이터베이스에 오류가 발생합니다.

binlog 로그를 안전하게 정리하려면 다음 방법을 사용하세요

1. 마스터-슬레이브 동기화 없이 로그를 정리합니다

mysql -uroot -p123456 -e 'PURGE MASTER LOGS BEFORE DATE_SUB(지금(),간격) 5 DAY)';

#mysql은 5일 전의 binlog를 정기적으로 정리합니다.

mysql -u root -p #mysql 콘솔로 진입

#reset binlog;

2. MySQL 마스터-슬레이브 동기화에서 binlog 로그를 안전하게 삭제

1. mysql -u root -p #슬레이브 서버에 진입 mysql console
showslave statusG; #슬레이브 서버에서 어떤 로그를 읽고 있는지 확인하세요. 슬레이브 서버가 여러 개 있습니다. 가장 빠른 것을 대상 로그로 선택하세요.
2. 마스터 서버 mysql 콘솔에 들어가세요

show master log; #마스터 서버에서 일련의 로그 가져오기
PURGE MASTER LOGS TO 'binlog.000058'; #binlog.000005 이전 항목 삭제, binlog.000058 제외
'2016-06-22 이전 마스터 로그 제거 13:00:00'; #2016-06-22 13:00:00 이전 binlog 로그 지우기
이전 마스터 로그 제거 DATE_SUB( NOW( ), INTERVAL 3 DAY); #3일 전 binlog 로그 지우기

3. MySQL binlog 로그 자동 정리 설정

vi /etc/my.cnf #구성 편집

expire_logs_days = 15 #自动删除15天前的日志。默认值为0，表示从不删除。
log-bin=mysql-bin #注释掉之后，会关闭binlog日志
binlog_format=mixed #注释掉之后，会关闭binlog日志

:wq! #저장하고 종료

자세한 내용 보기:

mysql> >이름: 'PURGE BINARY LOGS'

설명:

구문:

PURGE { BINARY | MASTER } LOGS

{ TO 'log_name' | datetime_expr }

바이너리 로그는

MySQL 서버에서 수정된 데이터에 대한 정보가 포함된 파일 집합입니다.

로그는 바이너리 로그 파일 집합으로 구성됩니다. , 인덱스 파일(

http://dev.mysql.com/doc/refman/5.5/en/binary-log.html 참조).

PURGE BINARY LOGS 문은 다음을 삭제합니다. 지정된 로그 파일 이름이나 날짜 이전에 로그 인덱스 파일에 나열된

모든 바이너리 로그 파일.

BINARY와 MASTER는 동의어입니다.

인덱스 파일에 기록된 목록으로, 해당 로그 파일은

목록의 첫 번째 파일이 됩니다.

서버가

바쁜 마스터 DB에서 서버에서 binlog 로그 파일은 매우 빠르게 증가합니다. 정기적으로 삭제하지 않으면 하드 디스크 공간이 빠르게 채워집니다.

expire_logs_days = 10

'%log%'와 같은 변수 표시; 🎜>글로벌 설정 만료_logs_days = 10;

삭제하기 전에 해당 백업 전략을 채택할 수 있습니다.

10일 전 MySQL binlog 로그를 수동으로 삭제합니다.

DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY) 이전에 마스터 로그를 제거합니다.

일반적으로 MIXED binlog 복사본을 사용하는 것이 좋습니다. http://dev.mysql.com/doc/refman/5.1/en/open-bugs-general.html의 지침: 복제 쿼리 수준 로깅 사용: 마스터는 실행된 쿼리를 바이너리에 기록합니다. log는 작동하는 매우 빠르고 컴팩트하며 효율적인 로깅 방법입니다. 대부분의 경우 완벽합니다.

첨부: 여러 MYSQL 복제 모드

– 기반 SQL 문 복제(문 기반 복제(SBR),

– MBR(혼합 기반 복제).
따라서 binlog에는 STATEMENT, ROW 및 MIXED의 세 가지 형식이 있습니다. MBR 모드에서는 SBR 모드가 기본값입니다.

다음 상황을 제외하고 binlog 형식은 런타임 중에 동적으로 변경될 수 있습니다.
저장 프로세스 또는 트리거 도중
NDB가 활성화되었습니다

binlog가 MIXED 모드를 채택하는 경우 다음과 같은 상황에서는 binlog 모드가 SBR 모드에서 RBR 모드로 자동 변경됩니다.
. DML 문이 NDB 테이블을 업데이트하는 경우
. 함수에 UUID()

. INSERT DELAYED 문
을 실행할 때 UDF
를 사용할 때 뷰를 생성할 때와 같이 뷰에서 RBR을 사용해야 하는 경우 UUID()가 사용됩니다. 기능

마스터-슬레이브 복제 모드 설정:
log-bin=mysql-bin
#binlog_format="STATEMENT"
#binlog_format="ROW"
binlog_format="MIXED"

런타임에 binlog 형식을 동적으로 수정할 수도 있습니다. 예를 들어
mysql> SET SESSION binlog_format = 'STATEMENT';
mysql> SET SESSION binlog_format = 'ROW';
mysql> 세션 binlog_format = '혼합';
mysql> SET GLOBAL binlog_format = 'STATEMENT';
mysql> SET GLOBAL binlog_format = 'ROW';
mysql> GLOBAL binlog_format = 'MIXED';

두 모드의 장점과 단점:

SBR 장점:
오랜 역사와 성숙한 기술
binlog 파일이 더 작습니다
binlog에는 모든 데이터베이스 수정 정보가 포함되어 있으며, 이는 데이터베이스 보안 및 기타 상황을 감사하는 데 사용할 수 있습니다.
binlog는 복제뿐만 아니라 실시간 복원에 사용됩니다
마스터와 슬레이브 버전이 다를 수 있으며, 슬레이브 서버 버전이 마스터 서버 버전보다 높을 수 있습니다
SBR 단점:
모든 UPDATE 문을 복사할 수 있는 것은 아니며, 특히 불확실한 작업이 포함된 경우에는 더욱 그렇습니다.
불확실한 상황에서 UDF 호출 복사 시 문제가 발생할 수 있습니다.
다음 함수를 사용하는 문은 복사할 수 없습니다:
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE()(시작 시 –sysdate-is-now 옵션이 활성화되지 않은 경우)
INSERT … SELECT RBR보다 더 많은 행 수준 잠금을 생성합니다.
전체 테이블 스캔을 수행해야 하는 UPDATE를 복사할 때(WHERE 문에 인덱스가 사용되지 않음) RBR보다 더 많은 행 수준 잠금이 필요합니다. 추가 행 수준 잠금 요청
AUTO_INCREMENT 필드가 있는 InnoDB 테이블의 경우 INSERT 문은 다른 INSERT를 차단합니다. 명령문
일부 복잡한 명령문의 경우 슬레이브 서버의 리소스 소비가 더 심각하며 RBR 모드에서는 변경된 레코드에만 영향을 미칩니다
저장 기능(저장 프로세스 아님) )은 호출될 때 NOW() 함수를 한 번 실행합니다. 이는 나쁜 것일 수도 있고 좋은 것일 수도 있습니다
UDF 결정 슬레이브 서버에서도 실행해야 합니다
데이터 테이블이 마스터 서버와 거의 일치해야 합니다. 그렇지 않으면 복제 오류가 발생할 수 있습니다
복잡한 명령문 실행 시 오류가 발생하면 더 많은 리소스가 소모됩니다

RBR 장점:
어떠한 상황이라도 복제가 가능하여 가장 안전하고 신뢰성 있는 복제
대부분의 다른 데이터베이스 시스템과 동일한 복제 기술
대부분의 경우 슬레이브 서버의 테이블에 기본 데이터베이스가 있는 경우 키를 사용하면 복제 속도가 훨씬 빨라집니다.
다음 명령문을 복제할 때 행 잠금이 줄어듭니다.
* INSERT … SELECT
* INSERT
* AUTO_INCREMENT 필드를 포함하는 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이 사용됩니다. 모드를 구현한 후에는 원래 발생했던 많은 기본 키 중복 문제를 해결할 수 있습니다. 예:
db_allot_ids에 삽입하려면 다음에서 *를 선택하세요. db_allot_ids 이 문은 다음과 같습니다. BINLOG_FORMAT=STATEMENT의
모드:
BINLOG 로그 정보:
——————————————–
BEGIN
/*!*/;
# at 173
#090612 16:05:42 서버 ID 1 end_log_pos 288 쿼리 thread_id=4 exec_time=0 error_code=0
SET TIMESTAMP=1244793942/*!*/;
db_allot_ids에 삽입 db_allot_ids에서 * 선택
/*!*/;

BINLOG_FORMAT=ROW 모드:
BINLOG 로그 정보는 :
——————————————–
빈로그 '
hA0yShMBAAAAMwAAAOAAAAAAA8AAAAAAAAAA1NOUwAMZGJfYWxsb3RfaWRzAAIBAwAA
hA0yShcBAAAANQAAAABUBAAAQAA8AAAAAAAEAAv/8AQEAAAD8AQEAAAD8AQEAAAD8AQEAAAD8AQEAAAA=
'/*!*/;

로그 삭제 단계
1. 로그 파일 찾기
mysql> 로그;
+---+----------+
| Log_name | |
+---+----------+
|ablelee.000001 |
| 에이블리.000002 |125 |
| |
+---+------------+
2. bin-log 삭제(ablelee.000003 이전 로그 삭제) 그리고ablelee.000003)
mysql>은 포함되지 않습니다. 바이너리 로그를 'ablelee.000003'으로 삭제;
쿼리 확인, 영향을 받은 행 0개(0.16 초)

3. 쿼리 결과(현재 레코드는 하나만 있습니다.)

mysql> show binlog eventsG
*************** *** *********** 1. 행 ***************************
Log_name:ablelee.000003
Pos: 4
Event_type: Format_desc
Server_id: 1
End_log_pos: 106
정보: 서버 버전: 5.1.26-rc-log, Binlog 버전: 4
1행(0.01) 초)
(ablelee.000001 및ablelee.000002가 삭제되었습니다.)
mysql> 로그;
+---+----------+
| Log_name | |
+---+----------+
|ablelee.000003 | |
+---+------------+
세트의 1행(0.00 초)

(다른 형식은 삭제되었습니다!)
{MASTER BINARY} 로그 삭제 | 'log_name'
　이전의 {MASTER BINARY} 로그 제거 | 'date'
지정된 로그나 날짜 이전에 로그 인덱스에 나열된 모든 바이너리 로그를 삭제하는 데 사용됩니다. 해당 로그는 로그 인덱스 파일에 기록된 목록에서도 제거되어 해당 로그가 첫 번째가 됩니다.
예:
퍼지 마스터 로그는 'mysql-bin.010';
　'2008-06-22 이전 마스터 로그 제거 13:00:00';
3일 전의 binlog 지우기
DATE_SUB( NOW( ), INTERVAL 3 DAY);
BEFORE 변수의 날짜 인수는 'YYYY-MM-DD일 수 있습니다. hh:mm:ss' 형식입니다. MASTER와 BINARY는 동의어입니다.
삭제하려는 로그 중 하나를 현재 읽고 있는 활성 슬레이브 서버가 있는 경우 이 명령문은 작동하지 않으며 오류와 함께 실패합니다. 그러나 슬레이브가 정지된 상태에서 읽으려는 로그 중 하나를 지우면 슬레이브는 시작된 후 복제할 수 없습니다. 이 명령문은 슬레이브 서버가 복제되는 동안 안전하게 실행될 수 있습니다. 그들을 막을 필요는 없습니다.
로그를 지우려면 다음 단계를 따르세요.
1. 각 슬레이브에서 SHOW SLAVE STATUS를 사용하여 읽고 있는 로그를 확인합니다.
　2. SHOW MASTER를 활용하세요 LOGS는 마스터 서버에서 일련의 로그를 가져옵니다.
　3. 모든 슬레이브 서버 중에서 가장 오래된 로그를 확인합니다. 대상 로그입니다. 모든 슬레이브 서버가 최신 상태라면 이것이 목록의 마지막 로그입니다.

　4. 삭제할 모든 로그는 백업해두세요. (이 단계는 선택사항이지만 권장됩니다.)

5. 모든 로그를 정리하고 대상 로그는 정리하지 않습니다

위 MySQL의 binlog 로그 자동 정리 방법에 대한 내용입니다. 더 많은 관련 글은 PHP 중국어 홈페이지(m.sbmmt.com)를 참고해주세요!