mysql 정시 백업 작업 분석

간단 한 소개
생산 환경 에서 데이터 의 분실 을 피하 기 위해 통상 적 인 상황 에서 정기 적 으로 데이터 베 이 스 를 백업 한다.리 눅 스 의 crontab 명령 은 데이터 베 이 스 를 정기 적 으로 백업 하 는 데 도움 을 줄 수 있다.우선 crontab 명령 을 간단하게 알 아 보 겠 습 니 다.할 수 있다 면 다음 내용 인 my sql 백업 으로 이동 하 십시오.
이 글 의 my sql 데이터 베 이 스 는 docker 용기 에 설치 되 어 있 으 며,이 를 예 로 들 어 설명 합 니 다.docker 용기 에 설치 되 어 있 지 않 아 도 참조 할 수 있 습 니 다.
contab 정시 작업
crontab-e 를 사용 하여 우리 의 정시 작업 을 작성 합 니 다.

0 5 * * 1 [command]

앞의 5 개의 숫자 는 각각 분,시,일,월,주 를 대표 하고 뒤의command은 당신 의 명령 을 집행 합 니 다.
만약 당신 이 매일 저녁 8 시 정각에 정시 임 무 를 수행 해 야 한다 면 이렇게 쓸 수 있 습 니 다.

0 8 * * * [command]

확장:

crontab-l 자신의 정시 퀘 스 트 를 확인 할 수 있 습 니 다

crontab-r 현재 사용자 의 모든 정시 작업 삭제

mysql 백업
빠 른 속도 로 착수 하 다.
여기 제 my sql 데이터 베 이 스 는 docker 용기 입 니 다.매일 저녁 8 시 정각에 정시 임 무 를 수행 해 야 한다 면 이렇게 쓸 수 있다.
우선 명령 을 실행 합 니 다.crontab-e.

0 8 * * * docker exec mysql_container mysqldump -uroot -proot_password database_name > /var/backups/mysql/$(date +%Y%m%d_%H%M%S).sql

mysql_container 데이터베이스 용기 이름
my sqldump 는 my sql 데이터베이스 에서 데 이 터 를 내 보 내 는 명령 입 니 다.
-u 루트 계 정 작성
-p 루트 비밀번호 입력
database_백업 할 데이터베이스 이름
/var/backups/mysql/$(date +%Y%m%d_%H%M%S).sql 백업 파일,뒤에 파일 이름 형식
만약 당신 이 아무런 요구 가 없다 면,단순히 백업 만 하고 싶다 면,위의 명령 은 당신 을 도와 정시 백업 을 할 수 있 습 니 다.
작은 구덩이:my sql 백업 할 때 저 는docker exec -it mysqldump ...이런 명령 으로bash스 크 립 트 를 했 습 니 다.-i 매개 변 수 는 상호작용 이 있다 는 뜻 이기 때문에crontab에서 정시 작업 을 수행 할 때sql파일 에 데 이 터 를 출력 하지 않 았 습 니 다.따라서crontab정기 적 으로 docker 용기 에 백업 명령 을 할 때-i인 자 를 추가 하지 마 십시오.
crontab 최적화
나 는crontab -e에 실행 할 명령 을 직접 쓰 는 것 을 건의 하지 않 는 다.임무 가 많 으 면 이 서 류 를 난잡 하 게 쓴다.
데이터베이스 백업 명령 을 스 크 립 트bash로 쓰 는 것 을 권장 합 니 다.crontab여기 서 호출 하면 돼 요.
예 를 들 어/var/backups/mysql/mysqldump.sh파일 을 만 들 면 내용 은 다음 과 같다.

docker exec mysql_container mysqldump -uroot -pmypassword database_name > /var/backups/mysql/$(date +%Y%m%d_%H%M%S).sql

그리고 파일 을 현재 사용자 가 실행 할 수 있 는 것 으로 바 꿉 니 다.

chmod 711 /var/backups/mysql/mysqldump.sh

crontab-e 명령 을 다음 과 같이 수정 합 니 다.

0 20 * * * /var/backups/mysql/mysqldump.sh

그럼 이렇게 하면 비교적 규범 적 이다.
mysql 백업 최적화
sql 파일 이 크기 때문에 일반적으로 sql 파일 을 압축 합 니 다.그렇지 않 으 면 디스크 사용량 이 너무 큽 니 다.
만약 당신 이 위의 crontab 최 적 화 를 했다 면,우 리 는 my sqldump.sh 스 크 립 트 를 아래 와 같이 바 꿀 수 있 습 니 다.

export mysqldump_date=$(date +%Y%m%d_%H%M%S) && \
docker exec mysql_container mysqldump -uroot -pmypassword database_name> /var/backups/mysql/$mysqldump_date.sql && \
gzip /var/backups/mysql/$mysqldump_date.sql
find /var/backups/mysql/ -name "*.sql" -mtime +15 -exec rm -f {} \;

export시스템 에서 변 수 를 정의 합 니 다 my sqldumpdate,백업 및 압축 명령 사용gzip 압축 명령 입 니 다.기본적으로 압축 된 후에 원본 파일 을 삭제 하고'gz 파일'로 압축 합 니 다.find ... 이 명령 은 검색/var/backups/mysql/디 렉 터 리 에서 생 성 시간 15 일 전(-mtime +15,파일 이름 접미사.sql의 모든 파일 이 삭제 명령 을 수행 합 니 다-exec rm-f{}\;.전체 뜻 은 my sql 의 백업 파일 은 15 일 이내 에 만 보관 한 다 는 것 이다.15 일 전에 다 지 워.
데이터 복구
조심 하지 않 으 면 집행drop database,진정 해,침착 해.우 리 는 우선 데이터베이스 가 삭 제 된 데이터 베 이 스 를 만들어 야 한다.

>mysql create database database_name;

그리고 최근 백업 한 데 이 터 를 복원 합 니 다.백업 복구 명령:

docker exec -i mysql_container mysql -uroot -proot_password database_name < /var/backups/mysql/20200619_120012.sql

백업 파일 의 데 이 터 를 복 구 했 지만 백업 시간 이후 의 데 이 터 는 복구 되 지 않 았 습 니 다.
예 를 들 어 저녁 8 시 에 정시 백업 을 하지만 저녁 9 시 drop database 는 저녁 8 시 부터 저녁 9 시 까지 한 시간 동안 데 이 터 를 백업 하지 못 했 습 니 다.이 럴 때 binlog 로 그 를 사용 해 야 합 니 다.
binlog 로그
binlog 는 my sql 의 압축 파일 로그 로 기 록 된 데이터 수정 논리 입 니 다.예 를 들 어 ID=3 줄 의 Money 필드+1.
먼저 mysql 에 로그 인 한 후 현재 몇 개의 binlog 파일 이 있 는 지 확인 합 니 다.

> mysql show binary logs;
+---------------+-----------+-----------+
| Log_name   | File_size | Encrypted |
+---------------+-----------+-----------+
| binlog.000001 |    729 | No    |
| binlog.000002 |   1749 | No    |
| binlog.000003 |   1087 | No    |
+---------------+-----------+-----------+

현재 쓰 고 있 는 binlog 보기

mysql> show master status\G;

새로운 binlog 파일 을 만 듭 니 다.my sql 의 후속 작업 은 새로운 binlog 파일 에 기록 되 며,일반적으로 데 이 터 를 복구 할 때 이 명령 을 먼저 실행 합 니 다.

mysql> flush logs

binlog 로그 보기

mysql> show binlog events in 'binlog.000003';

작은 지식 점:my sql 용 기 를 초기 화 할 때 인자-binlog-rows-query-log-events=ON 을 추가 합 니 다.또는 용기 에/etc/mysql/my.cnf 파일 을 수정 하고 인자 binlog 를 추가 합 니 다.rows_query_log_이벤트=ON,그리고 mysql 용 기 를 다시 시작 합 니 다.이렇게 하면 원본 SQL 을 binlog 파일 에 추가 할 수 있 습 니 다.
복구 데이터
상례 의 이 단락 을 되 찾 아 라.
저녁 8 시 에 정시 백업 을 했 지만 저녁 9 시 drop database 에 서 는 저녁 8 시 부터 저녁 9 시 까지 한 시간 동안 데 이 터 를 백업 하지 못 했다.
먼저 my sql 용기 에 들 어간 후/var/lib/my sql 디 렉 터 리 로 전환 하여 binlog 파일 의 생 성 날 짜 를 봅 니 다.

cd /var/lib/mysql
ls -l
...
-rw-r----- 1 mysql mysql   729 Jun 19 15:54 binlog.000001
-rw-r----- 1 mysql mysql   1749 Jun 19 18:45 binlog.000002
-rw-r----- 1 mysql mysql   1087 Jun 19 20:58 binlog.000003
...

파일 날 짜 를 통 해 알 수 있 듯 이 당일 시간 은 2020-06-21 이 고 binlog.00002 파일 의 마지막 업데이트 시간 은 18:45 분 입 니 다.그러면 저녁 8 시 백업 에는 binlog.00002 의 데이터 가 포함 되 어 있 을 것 입 니 다.
binlog.00003 의 마지막 업데이트 날 짜 는 20:58 분 입 니 다.그러면 복구 해 야 할 데이터=저녁 8 시의 전체 백업+binlog.00003 의 20:00-drop database 명령 을 실행 하기 전의 데이터 입 니 다.
복구 명령 형식:

mysqlbinlog [options] file | mysql -uroot -proot_password database_name

mysqlbinlog 상용 매개 변수:
--start-datetime 시작 시간,포맷 2020-06-19 18:00:00
--stop-datetime 종료 시간,형식 은 동일
--start-positon 시작 위치,(binlog 파일 을 봐 야 함)
--stop-position 종료 위치,동상
...
백업 데이터 와 binlog 데 이 터 를 복구 하기 전에 my sql 에 로그 인 한 후 실행flush logs을 통 해 새로운binlog로 그 를 만 드 는 것 을 권장 합 니 다.그러면 데이터 복구 가 필요 한binlog파일 에 집중 할 수 있 습 니 다.
우선 binlog 로 그 를 확인 해 야 합 니 다.어느 위치 에서drop database작업 을 했 는 지 확인 해 야 합 니 다.

mysql> show binlog events in 'binlog.000003';
+---------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------------------------------------------------------------------------------+
| Log_name   | Pos | Event_type   | Server_id | End_log_pos | Info                                                                    |
+---------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------------------------------------------------------------------------------+
| binlog.000003 |  4 | Format_desc  |     1 |     125 | Server ver: 8.0.20, Binlog ver: 4                                                      |
| binlog.000003 | 125 | Previous_gtids |     1 |     156 |                                                                       |
| binlog.000003 | 156 | Anonymous_Gtid |     1 |     235 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                                                    |
| binlog.000003 | 235 | Query     |     1 |     318 | BEGIN                                                                    |
| binlog.000003 | 318 | Rows_query   |     1 |     479 | # INSERT INTO `product_category` SET `name` = '    ' , `create_time` = 1592707634 , `update_time` = 1592707634 , `lock_version` = 0   |
| binlog.000003 | 479 | Table_map   |     1 |     559 | table_id: 139 (hotel_server.product_category)                                                |
| binlog.000003 | 559 | Write_rows   |     1 |     629 | table_id: 139 flags: STMT_END_F                                                       |
| binlog.000003 | 629 | Xid      |     1 |     660 | COMMIT /* xid=2021 */                                                            |
| binlog.000004 | 660 | Anonymous_Gtid |     1 |     739 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                                                    |
| binlog.000004 | 739 | Query     |     1 |     822 | drop database hotel_server /* xid=26 */                                                   |
+---------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------------------------------------------------------------------------------

위의 로그 에 따 르 면End_log_pos= 822 의 위치 에서drop database작업 을 실 행 했 으 면binlog을 사용 하여 회복 하 는 범 위 는2020-06-19 20:00:00 - 660의 위치 에 있 습 니 다.왜 660 이 야?drop database의 이전 업무 제출 은 660 의 위치 이기 때문에 명령 은 다음 과 같 습 니 다.

mysqlbinlog --start-datetime=2020-06-19 20:00:00 --stop-position=660 /var/lib/mysql/binlog.000003 | mysql -uroot -proot_password datbase_name

만약 당신 의 범위 가 822 의 위 치 를 포함한다 면,당신 을 도와drop database명령 을 집행 할 것 입 니 다.못 믿 겠 으 면 해 볼 래?
위의 명령 을 실행 하면 당신 의 데 이 터 는drop database전 으로 회 복 됩 니 다!기분 이 좋 지 않 으 면 흥분 하지 않 는 다!
총결산
my sql 정시 백업 은 생산 환경 에서 필수 적 인 작업 이기 때 문 입 니 다.자주 쓰 는 거 예요.그래서 나 는 잠시 도 지체 하지 않 고 블 로 그 를 썼 다.물론 제 동료 들 의 도움 에 도 감 사 드 립 니 다.이 글 은 이미 3 일 을 썼 다.왜냐하면 나 도 끊임없이 잘못 을 시험 하고 끊임없이 문장 을 갱신 하고 있 기 때문이다.잘못된 지식 점 을 쓰 는 것 을 피하 다.도움 이 된다 면 나 를 지 켜 봐 줘!감사합니다.
이상 은 my sql 정시 백업 작업 의 상세 한 내용 을 분석 하 는 것 입 니 다.my sql 정시 백업 작업 에 관 한 자 료 는 다른 관련 글 을 주목 하 십시오!