mysql 정시 백업 작업 분석
생산 환경 에서 데이터 의 분실 을 피하 기 위해 통상 적 인 상황 에서 정기 적 으로 데이터 베 이 스 를 백업 한다.리 눅 스 의 crontab 명령 은 데이터 베 이 스 를 정기 적 으로 백업 하 는 데 도움 을 줄 수 있다.우선 crontab 명령 을 간단하게 알 아 보 겠 습 니 다.할 수 있다 면 다음 내용 인 my sql 백업 으로 이동 하 십시오.
이 글 의 my sql 데이터 베 이 스 는 docker 용기 에 설치 되 어 있 으 며,이 를 예 로 들 어 설명 합 니 다.docker 용기 에 설치 되 어 있 지 않 아 도 참조 할 수 있 습 니 다.
contab 정시 작업
crontab-e 를 사용 하여 우리 의 정시 작업 을 작성 합 니 다.
0 5 * * 1 [command]
앞의 5 개의 숫자 는 각각 분,시,일,월,주 를 대표 하고 뒤의command
은 당신 의 명령 을 집행 합 니 다.만약 당신 이 매일 저녁 8 시 정각에 정시 임 무 를 수행 해 야 한다 면 이렇게 쓸 수 있 습 니 다.
0 8 * * * [command]
확장:빠 른 속도 로 착수 하 다.
여기 제 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 정시 백업 작업 에 관 한 자 료 는 다른 관련 글 을 주목 하 십시오!
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
MySQL에서 JSON 인덱싱 - aarondfrancis사람들은 종종 MySQL로 JSON을 인덱싱할 수 없다고 말하지만 완전히 정확하지는 않습니다. MySQL로 JSON 열을 인덱싱하는 것은 완전히 가능합니다! 사람들은 종종 MySQL로 JSON을 인덱싱할 수 없다고 ...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.