> 데이터 베이스 > MySQL 튜토리얼 > MySQL 운영 및 유지보수 바이너리 로그

MySQL 운영 및 유지보수 바이너리 로그

齐天大圣
풀어 주다: 2020-06-02 10:08:49
원래의
1767명이 탐색했습니다.

MySQL 바이너리 로그는 데이터 변경을 유발하거나 유발할 수 있는 SQL 문을 저장합니다. 실시간 원격 재해복구 백업, 읽기-쓰기 분리, 데이터 복구 등의 기능을 바이너리 로그를 통해 완료할 수 있습니다. 다음으로 MySQL 바이너리 로그를 살펴보겠습니다.

bin-log 로그 활성화

Mysql은 기본적으로 bin-log 로그를 활성화하지 않으므로 구성을 직접 추가해야 합니다.

log-bin=mysql-bin
binlog_format=mixed
server-id   = 1
expire_logs_days = 10
로그인 후 복사

log-bin 이 항목을 구성하면 바이너리 로그 기능이 활성화됩니다. mysql-bin은 bin-log 로그 파일 이름입니다.

expire_logs_days = 10은 지난 10일 동안의 bin-log 로그만 저장됨을 나타냅니다.

일반적으로 bin-log 로그는 mysql 설치 경로 /var/

에 저장됩니다. 운영 및 유지 관리 팁: 하드 드라이브에 저장하는 경우 바이너리 로그 파일과 데이터베이스 데이터 파일을 동일한 하드 드라이브에 넣지 않는 것이 가장 좋습니다. 데이터 파일이 손상되면 다른 하드 디스크의 바이너리 로그를 사용하여 데이터를 복구할 수 있습니다

몇 가지 유용한 명령

  • 로그 플러시: 새 바이너리 로그 로그 생성

  • 마스터 상태 표시 : 마지막 bin-log 로그 상태를 봅니다. StReset Master: 모든 Bin-Log 파일 지우기

  • Mysql & GT; Show Master Status


MySQL 운영 및 유지보수 바이너리 로그Mysql 로그 보기

로그는 바이너리 로그이므로 일반적으로 일반 로그를 사용하는 데 사용됩니다. cat이나 vim에게 그것을 보라고 명령하면 내용이 깨질 것입니다. MySQL은 mysqlbinlog라는 도구를 제공합니다. 그것을 보려면 그것을 사용하십시오.

./mysqlbinlog ../var/mysql-bin.000015
……
# at 123
#200601  8:35:19 server id 1  end_log_pos 154 CRC32 0xd25b404e  Previous-GTIDs
# [empty]
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
……
로그인 후 복사

at: SQL 시작 시 pos 노드

  • server_id: 데이터베이스 호스트의 서비스 번호

  • end_log_pos 154: sql 종료 시 pos 노드

  • mysqlbinlog의 일반적인 옵션은 다음과 같습니다.

--start-datetime: 바이너리 로그에서 타임스탬프와 같거나 로컬 컴퓨터보다 늦은 지정된 시간을 읽습니다.

  • --stop-datetime: 바이너리 로그에서 타임스탬프보다 짧은 지정된 시간을 읽습니다. 타임스탬프보다 크거나 로컬 컴퓨터와 같음 컴퓨터의 시간 값은 위와 같습니다.

  • --start-position: 바이너리 로그에서 지정된 위치 이벤트 위치를 시작으로 읽어옵니다.

  • --stop-position: 바이너리 로그에서 지정된 위치 이벤트 위치를

  • -d 기준 이벤트로 읽습니다. --database=name: 지정된 데이터베이스의 로그 작업만 보기

  • bin -log 로그를 사용하여 데이터 복구

SQL 파일 내보내기 명령: mysqldump 데이터베이스 이름 [데이터 테이블 이름 1 [데이터 테이블 이름 2...]] > 외부 파일 디렉터리(.sql 사용 권장)

  • sql 파일을 데이터베이스로 가져옵니다. mysql -u** -p** 데이터베이스 이름 < 백업 파일 디렉터리

  • 이제 시나리오를 시뮬레이션해 보겠습니다. 데이터베이스는 매일 밤 3시에 정기적으로 백업됩니다. , 다음 날 반나절 동안 웹 사이트가 정상적으로 실행되다가 갑자기 오후 5시에 프로그래머 A가 DELETE 중에 실수로 WHERE 조건을 추가하지 않아 테이블 중 하나의 데이터가 모두 손실되었습니다. 그런 다음 Xiao A는 기술 이사 Dasheng을 찾아 데이터 복구를 도와달라고 요청했습니다.

  • binlog_test 데이터베이스에는 사용자 테이블이 하나만 있습니다

오전 3시에 백업하기 전 데이터는 다음과 같습니다.

+---------+----------+---------------------+
| user_id | username | add_time            |
+---------+----------+---------------------+
|       1 | gwx      | 2018-07-05 13:00:31 |
|       2 | snn      | 2018-07-05 14:00:00 |
|       3 | zy       | 2018-07-05 15:00:00 |
+---------+----------+---------------------+
로그인 후 복사

새벽 3시에 백업된 데이터

mysqldump binlog_test -l -F > /root/sql_backup/20180706.sql
ll /root/sql_backup/
总用量 4
-rw-r--r-- 1 root root 2149 7月   6 13:42 20180706.sql
=======数据备份完成=========
로그인 후 복사

웹사이트가 실행되었습니다. 정상적으로 일정 기간 동안 많은 사용자가 등록했습니다

INSERT INTO `user` (username) values(&#39;user1&#39;),(&#39;user2&#39;),(&#39;user3&#39;);
Query OK, 3 rows affected (0.01 sec)
Records: 3  Duplicates: 0  Warnings: 0
select * from user;
+---------+----------+---------------------+
| user_id | username | add_time            |
+---------+----------+---------------------+
|       1 | gwx      | 2018-07-05 13:00:31 |
|       2 | snn      | 2018-07-05 14:00:00 |
|       3 | zy       | 2018-07-05 15:00:00 |
|       4 | user1    | 2018-07-06 15:01:18 |
|       5 | user2    | 2018-07-06 15:01:18 |
|       6 | user3    | 2018-07-06 15:01:18 |
+---------+----------+---------------------+
==============新增了3个用户user1 user2 及user3==============
로그인 후 복사

오후 5시가 되자 꼬마A는 멍청한 행동을 하기 시작했습니다

DELETE FROM user;
Query OK, 6 rows affected (0.00 sec)
=========没where条件,数据全没了===========
로그인 후 복사

꼬마A는 대현자를 찾아 데이터 복원을 도왔습니다. 어젯밤 새벽 3시의 데이터

service nginx stop;  # 大圣先关闭了nginx,使网站用户暂时访问不了数据库
Stoping nginx...  done 
MariaDB [binlog_test]> flush logs;  #生成新的binlog日志
MariaDB [binlog_test]> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 |     1536 |              |                  |
+------------------+----------+--------------+------------------+
mysql -v -f binlog_test < /root/sql_backup/20180706.sql
로그인 후 복사

이때 대현자는 이미 어젯밤 새벽 3시의 데이터를 복원했습니다. 복원

MariaDB [binlog_test]> select * from user;
+---------+----------+---------------------+
| user_id | username | add_time            |
+---------+----------+---------------------+
|       1 | gwx      | 2018-07-05 13:00:31 |
|       2 | snn      | 2018-07-05 14:00:00 |
|       3 | zy       | 2018-07-05 15:00:00 |
+---------+----------+---------------------+
=============昨晚凌晨三点数据恢复完成===============
로그인 후 복사

다음으로 오전 3시에서 3시 사이의 데이터를 복원합니다. DELETE

먼저 삭제되는 pos 지점을 찾으세요. 백업 후 로그는 000002입니다. 삭제 후에는 로그도 000003으로 플러시되므로 000002 삭제 전에 pos를 찾으세요.

# /usr/local/mariadb/bin/mysqlbinlog --stop-position=629  >
&#39;mysql-bin.000002&#39; >
| mysql binlog_test;

MariaDB [binlog_test]> select * from user;
+---------+----------+---------------------+
| user_id | username | add_time            |
+---------+----------+---------------------+
|       1 | gwx      | 2018-07-05 13:00:31 |
|       2 | snn      | 2018-07-05 14:00:00 |
|       3 | zy       | 2018-07-05 15:00:00 |
|       4 | user1    | 2018-07-06 15:01:18 |
|       5 | user2    | 2018-07-06 15:01:18 |
|       6 | user3    | 2018-07-06 15:01:18 |
+---------+----------+---------------------+
==============数据都回来了========================
로그인 후 복사
.

위 내용은 MySQL 운영 및 유지보수 바이너리 로그의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

관련 라벨:
원천:php.cn
본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
인기 튜토리얼
더>
최신 다운로드
더>
웹 효과
웹사이트 소스 코드
웹사이트 자료
프론트엔드 템플릿