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

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 로그 보기

로그는 바이너리 로그이므로 일반적으로 일반 로그를 사용하는 데 사용됩니다. 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('user1'),('user2'),('user3');
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  >
'mysql-bin.000002' >
| 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 중국어 웹사이트의 기타 관련 기사를 참조하세요!