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: 지정된 데이터베이스의 로그 작업만 보기
SQL 파일 내보내기 명령: mysqldump 데이터베이스 이름 [데이터 테이블 이름 1 [데이터 테이블 이름 2...]] > 외부 파일 디렉터리(.sql 사용 권장)
sql 파일을 데이터베이스로 가져옵니다. mysql -u** -p** 데이터베이스 이름
이제 시나리오를 시뮬레이션해 보겠습니다. 데이터베이스는 매일 밤 3시에 정기적으로 백업됩니다. , 다음 날 반나절 동안 웹 사이트가 정상적으로 실행되다가 갑자기 오후 5시에 프로그래머 A가 DELETE 중에 실수로 WHERE 조건을 추가하지 않아 테이블 중 하나의 데이터가 모두 손실되었습니다. 그런 다음 Xiao A는 기술 이사 Dasheng을 찾아 데이터 복구를 도와달라고 요청했습니다.
오전 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 중국어 웹사이트의 기타 관련 기사를 참조하세요!